What a shared services function is
A shared services function is a team that performs a defined set of support activities for several parts of an organization, instead of each part doing that work itself. Typical candidates are IT support, payroll, accounts payable, procurement administration, facilities and HR administration. The receiving parts of the business, often called business units, are treated as internal customers.
The key idea is that the team is run as a service. It has a defined scope, agreed ways of requesting work, and some way of showing what it delivers. That separates it from a simple department that happens to be located in the head office, which may set rules but does not necessarily serve anyone.
Shared services are one form of centralization, but not the same as centralizing decisions. A shared team can carry out work while the business units still decide what they need and how much of it to buy.
Why organizations set them up
The usual motivations are fairly consistent, though results vary by organization:
- Consistency. One team following one method tends to produce more uniform outputs than several teams improvising.
- Scale. Repetitive, high-volume work can sometimes be done with fewer total people when it is pooled, since peaks and troughs in different units partly offset each other.
- Specialist skills. A single team can justify deeper expertise than a small local team could.
- Visibility. When activity is in one place, it is easier to see volumes, delays and costs.
- Freeing local focus. Business units can concentrate on their core work rather than administration.
None of these is guaranteed. They depend on the quality of design and on whether the work is genuinely suited to pooling.
Which work suits a shared model
Work tends to fit well when it is:
- Repeatable and rule-based, so it can be captured in standard operating procedures and followed the same way each time.
- High in volume, so that pooling creates real efficiencies.
- Similar across units, so one process can serve many customers without heavy adaptation.
- Not dependent on close local knowledge or relationships.
- Measurable, so that quality and timeliness can be tracked.
Work tends to fit poorly when it is highly variable, depends on in-depth knowledge of a local customer or market, needs very fast local judgment, or differs greatly from one unit to the next. Forcing that type of work into a central team often produces queues and frustration. Many organizations settle on a split: routine transactions go to the shared team, while judgment-heavy work stays close to the business.
Common structures
There is no single standard design. The main variations are:
- Single central center. One location or team serves everyone. This is the simplest to govern, but it concentrates risk and may sit far from some customers.
- Several regional or functional centers. Each covers a geography or a type of work. This keeps some proximity but duplicates management.
- Hub and spoke structure. A central hub sets standards and handles core work, while local contacts handle the parts that need a local presence.
- Virtual or networked teams. People remain in their original units but follow common processes and report into a shared structure.
The right choice depends on the size of the organization, how similar the units are, and how much local variation matters. The wider question of how this fits among operating model choices, from fully central to fully local, is a separate decision that shared services sits inside.
How the service is run
Several elements usually distinguish a well-run shared service:
- A defined scope, ideally written down, so that people know what is and is not included.
- Agreed expectations, such as internal service levels covering turnaround times and quality.
- A visible description of services, commonly an internal service catalog.
- A funding approach, from simple allocation of costs to charging for usage.
- Governance, meaning a forum where customers and the service meet to review performance and priorities.
- Measurement, so that the team can show what it delivers and what it costs.
Each of these has its own detail, and they work best as a connected set rather than separately.
What it costs in flexibility
The trade-offs are real and should be weighed honestly.
Slower local response. When a request goes into a queue, a manager who used to ask a colleague down the corridor now waits for a ticket to be handled. For urgent or unusual needs, this can feel like a step backward.
Less tailoring. Standard processes treat everyone alike. Units with legitimate special needs may find the standard fit poorly.
Loss of local knowledge. People who once understood a particular unit’s quirks may be replaced by staff who handle many units and know none of them well.
Concentrated risk. Placing everything in one team creates single points of failure. A staffing gap, system outage or process error can affect every unit at once.
Transition effort. Moving work takes time, and service often dips during the change before it improves, if it improves at all.
Weaker ownership. Business units may stop caring about the cost or quality of work they no longer control, or they may blame the central team for problems with other causes.
Because of these costs, centralizing is not always the right answer. A small organization with limited volume may gain little. A business with widely differing units may do better with a hybrid or federated approach, where only the most uniform work is shared.
Deciding what to move and when
A sensible approach is incremental. Many organizations begin with work that is clearly transactional and uniform, then review results before moving anything more complex. The question of centralization sequencing, meaning which functions to move first, is worth thought, since early successes build trust while early failures can damage it.
Before moving anything, it helps to understand the current cost and quality of the work, because without a baseline there is no way to judge later whether the change helped. Thinking about internal function value, meaning what the work contributes as well as what it costs, also guards against judging a service on price alone.
Points to keep in mind
A shared services function is a tool, not a goal. It works when the work suits pooling, when customers are heard, and when the team is held to clear expectations. It struggles when it is treated as a cost-cutting exercise with little attention to the people who depend on it. Outcomes are uncertain and depend heavily on execution, so a modest scope, honest measurement and willingness to adjust or even reverse parts of the design are usually wiser than a large one-step transformation.