Where to Apply AI in Shared Services: Seven Design Rules

The most encouraging thing I have seen in our shared-services work this year has very little to do with the technology. It is how the people inside these functions react to it. When an employee understands that the company is investing in their reskilling — that the point of the exercise is to make them ready for the operating model that is coming, rather than redundant in the one that exists — they tend to embrace the change instead of resisting it. That reaction is more common than the commentary would have you believe, and it is powerful enough to build a transformation plan around.

What follows is a set of collective observations from watching shared-services organizations in finance, HR, customer service, procurement, IT and corporate services actually attempt AI transformation rather than discuss it. Seven findings came out of that work. They are design principles, not a maturity model. They are deliberately practical, and they are sequenced, because the earliest decisions — where AI is applied, and what it is asked to sit on top of — constrain everything that follows.

Upstream AI removes cost. Downstream AI only inspects it.

The single most important design choice is whether to apply AI early in a process or late in it. AI applied early compounds. AI applied late audits costs that have already been incurred.

Invoice processing is the cleanest illustration. Apply AI at the moment a reason code is first added — the upstream act of classification — and miscoding does not happen at all. Apply the same model as a downstream quality check and it catches errors that are already inside the workflow, after the rework has been paid for. Same model, very different economics.

The pattern generalizes across the function. In customer service, AI at intent classification beats AI at post-call summarization. In procurement, AI during supplier onboarding beats AI in invoice exception handling. In HR, AI at job-description generation beats AI at resume re-ranking. The further upstream the intervention sits, the more leverage it carries. When a team brings me a use case now, my first question is not whether the model will work. It is where in the process the model has been asked to stand.

Audit the automation you already own before you add more

Most shared-services functions already carry years of automation investment: RPA bots, ETL pipelines, rule engines, OCR layers, workflow tools. Layering AI on top without an inventory of what already exists creates redundancy at best and conflict at worst — a new model that duplicates a rule already running, or that contradicts a bot which executes every Tuesday.

A disciplined tech-stack audit is unglamorous and pays for itself many times over. List every automation in production. Document what each one does, where it touches data, and what it depends on. Identify what is genuinely broken or genuinely unmet. Only then ask which of those gaps AI is the right tool for. In our observations, the audit almost always reveals that 30 to 40 percent of proposed AI use cases are already partially solved by something the function forgot it owned.

The audit frequently produces an unfashionable conclusion: the answer is not AI, it is making last-era automation work. Much of the pain in shared services is still RPA pain. Projects from the 2018 to 2022 wave often stalled, drifted out of compliance as upstream systems changed, or were never fully adopted by the operating teams. Reviving and completing those projects routinely delivers more value, faster, than building a new generative AI pilot on the same broken foundation.

The honest diagnostic test is uncomfortable. If the AP or AR cycle time is high because three RPA bots silently fail every Tuesday, no model will fix that. Fix the bots. Reconnect the pipelines. A useful rule: do not green-light an AI initiative for a process unless its prior automation is at least 80 percent functional and adopted.

Three different things are being called AI

Three very different categories get bundled under one word, and treating them as interchangeable is one of the most expensive mistakes a shared-services leader can make.

• Foundation models — GPT, Claude, Gemini, Llama — are powerful but raw. They need orchestration, guardrails, evaluation and integration before they do anything useful inside a shared-services workflow.
• Hyperscaler AI services — AWS Bedrock, Azure AI Foundry, Google Vertex — wrap those models with infrastructure and security primitives, but still require meaningful engineering to become production-grade business processes.
• Enterprise-quality products — Microsoft Copilot, Workday AI, ServiceNow Now Assist, Salesforce Einstein, SAP Joule and the vendor copilots — ship with workflow integration, role-based access, audit trails and change-management material already built in.

For most shared-services functions, the best results come from enterprise-quality products for 70 to 80 percent of use cases, with selective custom builds on hyperscaler services for the remaining 20 to 30 percent. Pure foundation-model work belongs to a small specialist team, not to the operating function. Picking the wrong tier is the difference between months of value and years of platform engineering.

Without a sponsored metric, AI work drifts

When teams are told to use AI without a clear set of priority workflows, they gravitate towards the AI workloads they personally find interesting. The output is often impressive in a demo. The business impact is invisible at quarter-end. This is wishlist work, not critical-path work, and the fix sits upstream of the technology.

Every AI initiative needs three things on day one: a specific workflow it must move, a named metric it must shift, and a sponsor who owns that metric. Without that triangle, the portfolio fills up with pilots that nobody will defend when the budget conversation comes.

Capacity is a better frame than reduction

The most common framing of AI in shared services — we will reduce headcount — is wrong, or at least self-defeating. It produces defensive teams that hide work, slow change, and treat every rollout as a threat to be neutralized. The more useful framing is capacity for expansion: the same team now supports twice the business volume, absorbs a new geography, or carries an M&A integration that would previously have required a hiring cycle.

Both framings can be financially true at the same time. Only one of them produces a learning organization. Teams told the story of capacity actively look for the next workflow to absorb. Teams told the story of cuts protect the workflows they already have. The choice of frame is, in practice, the choice of pace.

That frame only holds if it is backed by something concrete, which brings me back to where I started. The biggest predictor of whether a team adopts AI is whether its people can see how it makes them more valuable to the company. That requires explicit, named skill paths — prompt design, workflow orchestration, AI governance, output auditing, process intelligence — that a person can put on a CV and that the organization formally recognizes in performance reviews and pay bands. Without that visible view of value, AI is experienced as a threat. With it, AI becomes a career accelerator. The companies getting adoption right publish skill ladders, certify their people against them, and tie them to compensation. Adoption follows incentives.

Reskill faster than you restructure

The seven findings cluster into three lessons. Where you apply AI — upstream rather than downstream, on the right product tier, on top of automation that actually runs — matters more than how much of it you apply. Direction matters more than enthusiasm, and direction means a sponsored metric. And the organizational frame you choose, capacity over reduction with visible skill paths underneath it, determines whether the technology compounds or stalls.

If you are planning the next two quarters, sequence it in that order: run the tech-stack audit before approving new use cases, repair or retire the automation that is failing, pick the product tier deliberately, and attach every initiative to a metric with a name against it. Then publish the skill ladder before the first rollout, not after it. The shared-services workforce of 2028 is being built, or lost, in the choices made this year.