Shared services centres and BPO providers were the first large adopters of RPA, and the first to discover that the headcount business case has a ceiling. Hours released are real, but if the centre is paid per FTE, automation that removes FTEs removes revenue. If it is a captive centre, the released hours are often absorbed rather than banked. The programmes that keep growing are the ones that moved the business case from headcount to unit economics.
Where the value actually sits.
| Lever | What automation changes | How it shows up |
|---|---|---|
| Cost per transaction | Straight-through processing on the standard cases | Lower unit cost at the same or higher volume |
| Cycle time | Work runs continuously, not in shifts | Faster close, faster onboarding, faster claims; a service-level advantage |
| Quality | No keying errors, consistent rule application | Fewer reworks, fewer penalties, fewer audit findings |
| Scalability | Volume peaks handled by machines | No surge hiring at quarter-end or campaign time |
| Capacity for higher-value work | People move from keying to review, analysis and client contact | Scope expansion and better retention |
| Control and evidence | Every transaction logged with its decision | Compliance costs fall, client audits get easier |
Headcount is one lever among six. A business case built on all six survives the conversation with the client or the CFO. A business case built on the first alone is renegotiated the moment volumes change.
Structuring the case.
Build the case per process, with the current unit cost, the expected straight-through rate, the new unit cost and the volume assumption, plus the non-cost outcomes above. Keep the assumptions visible and revisit them quarterly against actuals. Then roll up to a programme view. The roll-up is what the board sees. The per-process view is what keeps it honest.
The processes that pay first.
In most centres the early wins cluster in the same places: invoice processing and payment runs in procure-to-pay, cash application and dunning in order-to-cash, journal posting and reconciliations in record-to-report, onboarding and payroll inputs in HR operations, and ticket triage and access requests in IT service management. They share the characteristics of good automation candidates: high volume, defined rules, structured inputs, and a cost per transaction the client already measures.
The second wave is where document AI and agents matter: unstructured inbound mail, customer and vendor queries, exceptions that currently need a person to read something. These are the processes that kept the headcount high after the first wave, and they are where margin improves most in the second.
The operating model that sustains it.
- A centre-level automation CoE, with intake from every tower and a shared component library, so the same ERP login is not built eleven times.
- Process owners who own their exception queues and their straight-through rate, reported monthly alongside the service levels.
- A managed operations function, in-house or outsourced, that keeps the bots healthy and the monitoring real.
- Role redesign for the people whose keying work moved to bots: reviewer, analyst, client contact, with training to match.
- A quarterly value review where actuals replace assumptions in the business case.
Reporting that the client believes.
Report what the client already measures: unit cost, cycle time, error rate, service-level attainment, audit findings. Show the trend from before automation to now. Avoid programme-level claims that cannot be traced to a process. The credibility of the automation programme rests on numbers the client can check against their own invoice.
Done this way, automation in a shared services environment stops being a cost-cutting project with an awkward revenue side-effect and becomes the thing that lets the centre take on more scope at a better margin. That is a much easier conversation to have, in the boardroom and with the client.
Automation does not shrink a shared services centre. It changes what the centre is paid for.