A shared services centre should reduce the cost of processing each invoice, purchase request, employee change or customer case as group volume grows. If every entity still applies its own approval chain, local inboxes and informal escalation rules, that cost does not come down. The work has merely moved into a central team that must learn, remember and manually administer every local variation.
For a UAE operating group scaling across subsidiaries, sites, brands or GCC markets, this becomes a direct operating-cost problem. A central accounts payable team cannot build useful capacity when it must ask which managing director approves a particular supplier, whether a procurement threshold applies before or after VAT, or who can unblock an urgent exception for one entity. Each query adds handling time. Each manual follow-up creates a queue. Each “just this once” approval leaves behind an uncontrolled precedent.
The problem is not that the shared services team needs a more sophisticated workflow tool. It is that the group has not yet made the decisions required to operate as a group.
Centralising work is not the same as centralising control
A group can centralise accounts payable, procurement administration, HR operations or customer service while retaining fully local decision-making. That can be appropriate in a genuinely decentralised business. But it should not be described as a scale model.
The hidden cost sits in variation. A shared services team can process routine work efficiently when a request arrives with a clear policy, complete data and an unambiguous approval route. It becomes expensive when the same request requires interpretation: which entity rule applies, whether a local approver is available, whether the budget owner can delegate authority, and whether an exception needs finance, procurement, operations or an owner-family representative to decide.
The labour involved is rarely visible as a separate line item. It appears as follow-up emails, Teams messages, calls to executive assistants, re-submitted forms, ageing invoices, frustrated suppliers and senior managers approving low-value routine requests between meetings. The group sees service delays and believes it has a capacity issue. In reality, it often has a decision-design issue.
This is why adding people to the centre rarely fixes the underlying economics. More coordinators may keep the work moving for a period, but they also become the human routing engine for a process that should have a defined operating rule.
Approval bands are a group decision, not an entity preference
The first question for a Group COO or Shared Services Director is not, “How can we digitise approvals?” It is, “Which decisions genuinely need to differ by entity?”
There are valid reasons for variation. A regulated activity, a joint venture arrangement, a site with a distinct risk profile, or a legal entity with separately governed finances may require different controls. But inherited practice is not a control rationale. Neither is the preference of a local manager who has always been copied into every purchase request.
Standardisation does not mean removing accountability. It means expressing accountability in a small number of reusable rules. A group approval framework should establish who owns budget approval, who confirms commercial and procurement compliance, who verifies receipt of goods or services, and who can authorise a defined exception. It should also make clear where authority is delegated, when a delegate is valid, and when an escalation is required.
That distinction matters because approval routing and approval authority are often confused. Routing determines where a request goes. Authority determines who is permitted to make the decision. A workflow can route a request perfectly to the wrong person if the group has not defined authority consistently. Equally, an executive may hold authority but should not be included in routine routing merely because the process was designed around visibility rather than action.
The objective is not one universal approval chain for every transaction. It is a controlled set of approval patterns that covers the overwhelming majority of normal work, with explicit paths for the minority of cases that require judgement.
Exception ownership is where shared services models usually fail
Most approval processes work on paper for a standard request. They fail in the situations that create management attention: an urgent supplier payment, a missing purchase order, a disputed invoice, an out-of-policy purchase, an absent budget holder or a cross-entity charge that does not fit neatly into one cost centre.
When nobody owns these exceptions, shared services staff become the default owners. They chase people, interpret policy, decide what can wait and carry the operational risk of moving a request without a clear decision. This is neither efficient nor fair to the team.
Every exception needs a named business owner and a time-bound decision route. That does not mean creating another committee. It means deciding, before volume makes the issue acute, whether a missing purchase order is owned by the requisitioning department, procurement, finance control or the entity manager; whether an urgent payment can bypass a routine step; and who accepts the risk when supporting evidence is incomplete.
A useful test is simple: when an item falls outside the normal route, can a shared services analyst identify the accountable decision-maker without opening an email thread? If not, the group does not yet have an executable control model.
This is particularly important across GCC operations, where approval expectations, commercial practices and lead times can vary between markets. The point is not to pretend those differences do not exist. It is to define which differences are material enough to justify a separate rule, rather than allowing every local relationship and historic preference to become a permanent workflow branch. The Drum notes that approval dynamics can differ materially across GCC markets; group leaders need to distinguish those genuine operating differences from avoidable internal complexity. Source
Automate the stable path, not the organisational ambiguity
AI can be useful in a mature shared services operation. It can classify incoming documents, extract fields, identify missing information, draft supplier responses, suggest coding, summarise an exception history and route a case according to defined rules. These capabilities can reduce handling effort around repeatable work.
They cannot safely settle a dispute over who is entitled to approve a non-standard commitment. If the authority model is inconsistent, an AI-enabled workflow will either reproduce inconsistency at greater speed or push more cases into manual review. Both outcomes weaken the expected saving.
Automation should be the consequence of standardisation. First establish the policy hierarchy, approval bands, delegation rules, evidence requirements and exception owners. Then measure the volume moving through each path. Only after that should the group decide which hand-offs warrant workflow automation, document intelligence or AI assistance.
The same discipline applies to ERP and systems integration. Technology can reduce fragmented information and manual hand-offs, but it does not replace business ownership or process redesign. Crowe UAE has similarly argued that successful ERP programmes establish measurable KPIs, redesign processes where necessary and assign clear business ownership, treating transformation as a business change enabled by technology rather than an IT exercise. Source
For a mid-market operating group, the first target is not an autonomous back office. It is a dependable routine path: fewer touches per request, fewer avoidable escalations, clearer control evidence and less senior time spent resolving low-value ambiguity.
Measure the unit cost of the process you actually run
Shared services reporting often begins with service levels: invoices processed, tickets closed, requests completed and backlog ageing. These are useful, but they can conceal an expensive operating model. A team may meet its service level only by applying disproportionate manual effort to exceptions.
The COO needs to see the process at the level where economics change. How many requests arrive complete? How many follow the intended approval route without intervention? Where do they pause? How often does an analyst manually redirect an item? Which entities create the highest exception load? Which approvers consistently become bottlenecks? And how much management time is being consumed by decisions that should be governed by policy?
This baseline changes the conversation. Rather than debating whether a new tool has attractive features, the group can identify the workflow where standardisation will release the most capacity and lower the most avoidable handling cost.
A shared services centre earns its name when service teams can operate common processes with controlled local exceptions. Until then, it is a central location for decentralised work.
A Diagnostic identifies where entity-specific approval variation is increasing shared-services handling cost, then defines the first workflow and control model worth standardising before automation makes the complexity permanent.
References: https://www.thedrum.com/industry-insight/the-gcc-same-region-different-playbooks; https://asianbusinessreview.com/co-written-partner/event-news/crowe-uaes-binit-shah-delaying-foundational-technology-decisions-creates-significant-complexity-organisations