This is where most transitions either build momentum or stall. The question isn’t whether to move to GBS—you’ve already answered that in Stage 1—but which processes move first, in what order, and on what timeline.” Get this wrong and you’ll spend the next two years either overwhelmed by too much change at once or stuck in a permanent ‘pilot phase’ that never expands because nobody wants to own the decision to move the next tower.
Processes with high transaction volume, low judgment or exception rates, and minimal regional variation are the easiest to move into a shared model and the fastest to demonstrate value, which matters enormously for building internal credibility for the stages that follow. In finance, that’s typically procure-to-pay (invoice processing, payment execution) and parts of record-to-report (journal entries, account reconciliations, intercompany accounting). In HR, it’s core transactional HR—payroll administration, benefits enrollment, employee data management, onboarding logistics—before you touch anything judgment-heavy like performance management, compensation design, or employee relations. In IT, it’s tier-one service desk and standard access provisioning before anything involving architecture decisions or vendor negotiation.
The pattern across all three functions is the same: start where the work is high-volume and low-ambiguity, because that’s where centralization creates the clearest efficiency gain and the lowest risk of visible service failures during
the transition.
Trying to migrate finance, HR, and IT into the shared model at the same time multiplies the change-management burden across three functional leadership teams simultaneously, and it usually means none of them get the executive attention and dedicated resourcing they need to actually succeed. A staggered wave approach, one tower fully stabilized (meaning it’s hit its target SLAs consistently for at least one full quarter) before the next major tower begins its transition, is slower on paper but faster in practice, because you’re not troubleshooting three transitions’ worth of problems, three sets of new governance relationships, and three change-resistant functional cultures all at once.
A typical sequencing pattern looks something like: Wave 1 covers the highest-volume, most-standardized processes across one function (often finance, since procure-to-pay and record-to-report tend to be the most mature processes in most organizations). Wave 2 either deepens that function’s scope (moving more judgment-heavy finance processes) or brings in the second function’s most standardized work (HR transactional processes), depending on what Stage 1’s assessment showed about relative readiness. Later waves progressively bring in
more complex, more judgment-heavy, and more regionally variable work as the GBS organization builds credibility
and capability.
Rather than debating process by process, which moves first, it’s worth building a simple scoring framework across a small number of criteria—transaction volume, process standardization level, regional variation, technology readiness, and business criticality (how much risk there is if something goes wrong during the transition)—and scoring each candidate process against it. This does two things: it takes some of the political heat out of the sequencing decision (it’s the framework’s output, not one person’s judgment call), and it gives you a defensible answer when a functional leader asks why their process is in Wave 3 instead of Wave 1.
Processes that require significant local regulatory knowledge, high judgment, or close day-to-day business-partner relationships (think: tax planning, complex compensation design, strategic sourcing negotiations, employee relations casework) belong in later stages of scope expansion at the earliest, once your GBS has established credibility on the higher-volume, lower-complexity work. For some of these processes, the honest answer might be that they never move into the shared model at all, and that’s a legitimate outcome, not a failure of the transition. A well-scoped GBS knows its boundaries as clearly as it knows its core mandate.
A good scoping exercise ends with a wave plan, which processes towers in which order with rough timing for each wave—not a single “big bang” migration date, and not an open-ended “we’ll figure out sequencing as we go” plan either. The wave plan is what you’ll use to set expectations with functional leaders, plan governance rollout (Stage 3), and prioritize automation investment (Stage 4), so it’s worth the time to get it right and get it in writing.
Governance is the stage organizations most often try to skip or compress, and it’s the one that determines whether everything built in Stage 2 actually holds together once the initial enthusiasm fades. A GBS without real governance is just several SSCs sharing a name and a leadership slide, the moment the first cross-functional dispute happens (and it will), there’s no structure to resolve it, and the whole model starts reverting toward its functional-silo defaults.
At minimum, this stage needs to establish four things in real, documented, agreed-upon form, not aspirational statements in a charter document that nobody references again after the kickoff.
This defines, in specific and measurable terms, what the GBS delivers, to whom, and at what quality and speed, the same way an external provider would define a contract, because that’s functionally what this is: an internal contract. A real service catalog goes process by process (not function by function) and specifies volume assumptions, turnaround time commitments, quality/accuracy targets, and escalation paths. Vague SLAs (“we’ll process invoices promptly”) are worse than no SLAs at all, because they create the illusion of accountability without the substance, when something goes wrong, there’s no clear standard to measure against, and disputes become subjective arguments instead of factual ones.
This makes clear who owns decisions across the GBS/business-unit boundary, especially for exceptions and escalations, which is where most disputes actually happen in practice, not in the routine, high-volume transaction processing, but in the edge cases: the invoice that doesn’t match policy, the employee data discrepancy that needs a judgment call, the IT access request that falls outside standard provisioning rules. A clear RACI here, who’s responsible for handling the exception, who’s accountable for the outcome, who needs to be consulted, and who just needs to be informed—is what prevents every edge case from becoming an ad hoc negotiation between whoever happens to be available that day.
This ensures business units understand what they’re paying for and the GBS can demonstrate value in financial terms leadership actually cares about, rather than operational metrics that only make sense to the GBS team itself. Chargeback models range from simple (allocate cost based on headcount or transaction volume) to sophisticated (activity-based costing tied to the service catalog), and the right level of sophistication depends on your organization’s finance culture and how much scrutiny the model will face. What matters more than the specific methodology is that it exists, it’s transparent, and business units had input into its design, a chargeback model imposed without consultation tends to generate resentment that outlasts whatever efficiency gains it was meant
to demonstrate.
This needs representation from the GBS and the functions it serves, meeting on a real cadence (monthly is typical, quarterly is usually too infrequent to catch problems early), with actual decision-making authority, not a quarterly update meeting where the GBS presents metrics and everyone nods. The steering body should be the place where scope expansion decisions get made, where SLA disputes that couldn’t be resolved at the working level get escalated, and where the GBS leader and functional executives jointly own the model’s success rather than the GBS being solely accountable for outcomes it doesn’t have full control over.
A few patterns show up repeatedly in transitions that struggle at this stage, and it’s worth naming them directly so you can watch for them. The first is governance-by-committee-that-never-meets: the structure exists on paper, but the steering body’s meetings get deprioritized within two quarters, and decisions default back to informal relationships. The second is SLAs without teeth: targets are set, missed consistently, and nothing happens as a result, which quietly signals to the whole organization that the SLAs aren’t real. The third is chargeback resentment: a cost allocation model gets imposed top-down, business units feel like they’re being billed for a service they didn’t ask for and don’t fully control, and that resentment surfaces as passive resistance to every subsequent GBS initiative, including the automation work in Stage 4.
Automation belongs in Stage 4, not Stage 1, for a reason worth restating clearly: automating a process before it’s scoped correctly and governed properly just embeds the current mess more efficiently, and it does so with less human oversight to catch the problems that governance was supposed to prevent. We’ve seen organizations invest heavily in automation early, only to discover that they’ve built sophisticated technology on top of an unclear service catalog and an undefined escalation path, which means when the automation encounters an exception, there’s no clear process for handling it, and the whole initiative loses credibility.
Once governance is in place, though, automation is where the GBS model starts to pay for itself in a way that goes well beyond the original cost-consolidation case, and it’s where the ceiling on what’s possible moves dramatically compared to what an SSC could achieve on its own.
Traditional shared services automation was largely built around robotic process automation (RPA) , scripted bots that execute a defined sequence of steps in existing systems, essentially mimicking what a human would do by clicking through the same screens. RPA is valuable, but it’s brittle: it breaks when the underlying system changes, it can’t handle exceptions outside its script, and it doesn’t reason about the process; it just executes it.
Agentic AI is a materially different architecture. Rather than scripting a fixed sequence of steps, agentic systems can reason across a process, interpret unstructured inputs, handle exceptions within defined guardrails, and critically for a GBS context—operate across the functional boundaries your new governance model has defined. An agent working on procure-to-pay exceptions might need to reference finance policy, procurement contract terms, and vendor master data simultaneously, reasoning about how they interact rather than following one linear script. That’s a fundamentally different technical and organizational undertaking than deploying RPA, and it’s the reason the automation conversation for GBS organizations has shifted so significantly in the last few years.
The reason agentic AI belongs at Stage 4 specifically, and not earlier, is that everything it needs to operate safely and effectively is exactly what Stages 1 through 3 were building. It needs standardized, well-understood processes (Stage 2’s scoping work) rather than ad hoc tribal-knowledge processes that no documentation captures. It needs clear accountability for what happens when it encounters an exception (Stage 3’s RACI model) rather than an ambiguous escalation path. And it needs a shared data architecture across the functions it touches (part of Stage 1’s technology readiness assessment) rather than five disconnected systems it would have to bridge on its own.
Organizations that try to deploy agentic AI on top of an ungoverned SSC structure tend to run into the same
barrier: the technology works in a controlled pilot, then struggles to scale because the organizational structure underneath it can’t support cross-functional decision-making, exception handling, or accountability at the speed the technology operates.
A mature Stage 4 deployment isn’t measured just by how many processes have some automation applied to them—it’s measured by end-to-end outcomes: cycle time reduction on the processes the GBS now owns end-to-end (per Stage 1’s delivery model shift), a meaningful reduction in manual exception handling (not elimination—human-in-the-loop design for genuinely ambiguous cases remains important), and demonstrable audit trails that satisfy both internal controls and, where relevant, external regulatory requirements. The technology proof isn’t “we deployed AI”; it’s “we can show the governance body, quarter over quarter, that automated processes are meeting or beating the SLAs defined in Stage 3, with clear accountability when they don’t.”
The final stage is where a GBS moves from “working well for the functions and entities we started with” to being the default operating model across the enterprise, including entities and geographies it wasn’t originally designed for. This is also the stage where a well-executed transition compounds its value the most and where a poorly-governed one tends to reveal its cracks most visibly, because scale amplifies whatever foundation is underneath it.
Two scenarios dominate this stage, and they have meaningfully different playbooks.
This is extending the GBS model to additional business units, subsidiaries, or regions that weren’t part of the initial scope, typically because the original transition deliberately started with one or two business units to prove the model before rolling it out further, which is generally the right approach (see Stage 2’s emphasis on sequencing over big-bang migration). At this point, the technology, process design, and governance structure are already built and proven; the challenge is primarily change management and local stakeholder buy-in rather than rebuilding the model from scratch.
That said, “primarily change management” undersells the effort involved. Each new entity or region typically brings some degree of local regulatory or process variation that needs to be reconciled with the standardized model, statutory reporting requirements, local labor law implications for HR processes, and regional data residency requirements for the shared technology architecture. A realistic multi-entity scaling plan budgets meaningful time for this reconciliation work rather than assuming the existing model will drop in cleanly everywhere.
Integrating an acquired company’s back-office functions into an existing GBS is a different and generally harder problem than organic multi-entity scaling. You’re not just extending a working model to a new but cooperative internal audience; you’re absorbing another organization’s processes, systems, people, and often a completely different level of process maturity, on a timeline usually dictated by deal synergy targets and integration commitments made to the board rather than by operational readiness.
Organizations with an existing, mature GBS model have a significant structural advantage here: Rather than negotiating a bespoke integration approach for every deal, they can slot the acquired entity’s back-office functions into an existing service catalog, governance structure, and technology architecture, dramatically compressing the integration timeline compared to organizations still running fragmented SSCs. This is one of the strongest arguments for building GBS proactively rather than reactively, as discussed in the “5 Signs” section, organizations that wait until mid-integration to start building a shared services model are effectively trying to design an operating model and execute an acquisition integration simultaneously under deal-driven time pressure, which is a considerably harder version of the same problem.
A mature Stage 4 deployment isn’t measured just by how many processes have some automation applied to them—it’s measured by end-to-end outcomes: cycle time reduction on the processes the GBS now owns end-to-end (per Stage 1’s delivery model shift), a meaningful reduction in manual exception handling (not elimination—human-in-the-loop design for genuinely ambiguous cases remains important), and demonstrable audit trails that satisfy both internal controls and, where relevant, external regulatory requirements. The technology proof isn’t “we deployed AI”; it’s “we can show the governance body, quarter over quarter, that automated processes are meeting or beating the SLAs defined in Stage 3, with clear accountability when they don’t.”
