AI in Shared Services

The Finding:

The single most important design choice in any shared-services AI deployment is whether to intervene upstream or downstream in the process. AI applied early in a process compounds its value across every transaction that follows. AI applied late only audits costs that have already been incurred.

Key Examples: Upstream vs Downstream

• Invoice processing: Applying AI at the moment a reason code is first added - the upstream act of classification - prevents miscoding altogether. Applying the same AI as a downstream quality check only catches errors that have already entered the workflow. Same model, very different economics: one removes cost, the other only inspects it. ‍
• Customer service: AI at intent classification beats AI at post-call summarisation. Classification shapes what enters the workflow; summarisation processes what already happened. ‍
• Procurement: AI during supplier onboarding beats AI in invoice exception handling. Onboarding shapes the data quality of every downstream transaction; exception handling processes the consequences of poor upstream data. ‍
• HR: AI at job description generation beats AI at résumé re-ranking. The quality of intake determines the quality of the pool; re-ranking only sorts the debris of a poor intake.

What It Means:
The further upstream the intervention, the more leverage it carries. This is not an argument for deploying AI at the start of every process regardless of readiness. It is an argument for mapping process sequences before selecting intervention points, and consistently choosing the earliest viable point over the most visible one.

Strategic Implications:

The Finding:

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

Key Data Point:

A disciplined tech-stack audit almost always reveals that 30 to 40% of proposed AI use cases are already partially solved by existing automation. The audit is unglamorous and almost always the highest-return activity before any AI initiative launches.

What It Means:

The audit is not a gate. It is a filter. Its purpose is to identify what is genuinely broken or unmet - the cases where AI is the right tool for a gap that existing automation cannot fill. Without it, AI budgets fund duplication rather than net-new capability, and the integration surface area grows without clarity on what each layer owns.

Strategic Implications:

The Findings:

AI is fashionable, but much of the shared-services pain is still RPA pain. Automation projects from the 2018 to 2022 wave often stalled, drifted out of compliance with upstream system changes, or were never fully adopted by the operating teams. Reviving and completing those projects routinely delivers more value, faster, than building a new GenAI pilot on top of the same broken foundation.

Key Design Rules:

• The 80% rule: Do not green-light an AI initiative for a process unless its prior automation is at least 80% functional and adopted. Below that threshold, the AI initiative will inherit the dysfunction of the layer beneath it.

• The honest diagnostic test: If the AP/AR cycle time is high because three RPA bots silently fail every Tuesday, no AI model will fix that. Fix the bots. Reconnect the pipelines. Get the foundation right. AI then has something solid to sit on.

What It Means:

The pressure to show AI progress can produce a perverse outcome: GenAI pilots built on broken RPA foundations, which produce impressive demos and no durable value. The sequencing discipline required here is organizational, not technical. It requires leaders to say no to AI green-lights when the foundation is not ready, which is rarely the politically easy call.

Strategic Implications:

The Findings:

When teams are told to use AI without a clear set of priority workflows, they gravitate to the AI workloads they personally find interesting - items from a wishlist rather than items on the critical path. The output is often impressive in demos. The business impact is invisible at quarter-end.

The Three-Part Requirement:

Every AI initiative needs three things on day one. Without all three, the initiative will drift.

A specific workflow it must move. Not a function, not a department. A named workflow with a defined start and end point.

A named metric it must shift. Not "improve efficiency." A number with a baseline and a target that someone checks at quarter-end.

A sponsor who owns that metric. Not a champion who is enthusiastic about AI. A sponsor whose performance review includes the metric the AI initiative is meant to move.

What It Means:

Without that triangle, AI work drifts toward the curious and away from the critical, leaving the function with a portfolio of pilots no one will defend when budget pressure arrives. The fix sits upstream of the technology. This is a governance problem, not an engineering one.

Strategic Implications:

The Findings:

The most common framing of AI in shared services - "we will reduce headcount" - is wrong. It produces defensive teams that hide work, slow change, and treat every AI 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.

The Framing Contrast:

• Reduction framing: Teams protect the workflows they have. Every AI rollout is experienced as a threat. Adoption slows. Information is withheld. The technology compounds against resistance.

• Expansion framing: Teams actively look for the next workflow to absorb. AI rollouts are experienced as career leverage. Adoption accelerates. The technology compounds with cooperation.

What It Means:

Both framings can be financially true. A function that doubles its output capacity without adding headcount achieves the same cost ratio whether it frames that as a cut or as an expansion. Only one of them produces a learning organization. The choice of frame is, in practice, the choice of pace. Organizations that frame AI as capacity tend to move faster because their teams are pulling in the same direction.

Strategic Implications:

The Findings:

Three very different things get bundled under the word AI, and treating them as interchangeable is one of the most expensive mistakes shared-services leaders make. Picking the wrong tier is the difference between months of value and years of platform engineering.

The Three Tiers:

• Foundation models (GPT, Claude, Gemini, Llama) are powerful but raw. They need orchestration, guardrails, evaluation, and integration before they are useful in a shared-services workflow. This work belongs to a small specialist team, not the operating function. ‍
• Hyperscaler AI services (AWS Bedrock, Azure AI Foundry, Google Vertex) wrap models with infrastructure and security primitives, but still require meaningful engineering to translate into production-grade business processes. Appropriate for the 20 to 30% of use cases that require custom builds. ‍
• Enterprise-quality products (Microsoft Copilot, Workday AI, ServiceNow Now Assist, Salesforce Einstein, SAP Joule, vendor copilots) ship with workflow integration, role-based access, audit trails, and change-management materials built in. These should cover 70 to 80% of shared-services use cases.

What It Means:

For most shared-services functions, the fastest path to value is enterprise-quality products for the majority of use cases, with selective custom builds on hyperscaler services for the minority that genuinely require them. The temptation to go directly to foundation models - because they feel more powerful or more innovative - typically extends timelines by a year or more and produces capability that an enterprise product would have delivered in weeks.

Strategic Implications: