Assess, design, transition, govern, and continuously improve shared services with a clear catalogue, retained-organisation model, service agreements, control ownership, workforce plan, technology and data architecture, chargeback logic, and continuity evidence.
Assess, design, transition, govern, and continuously improve shared services with a clear catalogue, retained-organisation model, service agreements, control ownership, workforce plan, technology and data architecture, chargeback logic, and continuity evidence.
By Rusaka Research · Published 2026-07-27 · Updated 2026-10-04 · 6272 words
A shared services model consolidates repeatable capabilities so multiple business units, legal entities, geographies, or agencies can consume them through a governed service rather than each maintaining a separate full-stack function. Common candidates include finance operations, procurement, human resources, payroll administration, technology support, data operations, legal operations, facilities, customer administration, and other high-volume mission-support work. The model can be internal, outsourced, co-sourced, captive, federated, regional, global, or a deliberate combination.
The objective is not centralisation for its own sake. A viable model should improve service quality, user experience, control, resilience, transparency, capability, and cost-to-serve while preserving the local judgement and accountability that truly need to remain close to the business. Consolidating unstable processes or unclear policy can amplify their failure. Standardise what should be common, document justified variation, and keep decision authority where consequence and context require it.
This playbook begins with the service and customer, not the organisation chart or enterprise platform. Define the users, outcomes, transaction families, demand, service boundaries, current performance, risks, controls, skills, data, systems, dependencies, costs, and exceptions. Separate transactional execution from policy, business partnering, specialist judgement, statutory accountability, and local change. Then compare shared-services options with process improvement in place, automation, managed services, centres of expertise, or no structural change.
A shared service is an operating product. It needs a service catalogue, entry and exit rules, ownership, service agreements, request channels, capacity model, case and exception handling, knowledge, escalation, performance evidence, pricing or allocation logic, customer governance, workforce development, continuity, security, privacy, and a continuous-improvement backlog. A new centre and common system without these mechanisms is consolidation, not a mature service model.
Transition risk is often greater than steady-state design risk. Knowledge can leave before it is captured, controls can become ambiguous between organisations, backlogs can rise during cutover, master data can be inconsistent, and the new team can inherit unmeasured exceptions. Use waves, readiness gates, parallel evidence where warranted, reconciliations, hypercare, rollback criteria, and explicit acceptance. Do not move work simply because a programme milestone arrived.
The sources in this playbook provide reference points, not a universal compliance recipe. Government shared-services strategies illustrate accountable leadership, common operating models, standardisation, customer feedback, and performance governance. ISO management-system standards inform quality, risk, and continuity disciplines. NIST supply-chain guidance informs third-party and technology dependencies. Procurement and data-protection requirements vary by jurisdiction, sector, entity, data, employment model, and contract; obtain current qualified review.
Shared-services programmes frequently start with an assumed answer: consolidate headcount, select a location, procure an ERP, or transfer work to a provider. The business case is then constructed around a target savings number while service quality, retained roles, transition effort, exceptions, technology debt, control redesign, and demand growth remain weakly evidenced. Savings can appear in one budget while cost and risk move to customer teams, contractors, rework, or delayed decisions.
Scope is another failure point. Process names such as procure to pay or hire to retire conceal different activities, policies, approval rights, legal duties, data classes, languages, systems, transaction patterns, and consequences. Teams may move a process at level one while discovering hundreds of variants during migration. Conversely, every local preference can be defended as unique, blocking useful standardisation. A service taxonomy and evidence-led variation process are essential.
The retained organisation is often designed late. Business units may assume the centre owns policy, risk, data, supplier decisions, controls, and strategic support, while the centre assumes it only processes transactions. Duplicate shadow teams then persist or gaps appear. The target model must distinguish enterprise policy, process ownership, service delivery, customer ownership, specialist centres, local accountability, technology ownership, and independent assurance.
Service management may be reduced to a small set of average SLAs. Average turnaround can hide aged cases, priority failures, vulnerable users, control breaches, repeat contacts, or poor first-pass resolution. Cost per transaction can improve while demand rises because self-service is confusing or upstream data is poor. Metrics need denominators, segmentation, service-level objectives, user outcomes, quality, control, resilience, workforce, financial, and improvement views.
Technology can become the programme rather than an enabler. A common platform may help standardise data and process, but customisation, poor master data, fragmented identity, weak integrations, uncontrolled spreadsheets, accessibility gaps, and vendor dependency can preserve complexity. The operating model should define decisions, controls, data ownership, service interfaces, and exceptions before configuration freezes them into code.
Finally, transition and continuity are underestimated. Staff uncertainty can accelerate attrition, knowledge capture can lag, and old and new providers can dispute responsibility. A cutover without volume-based capacity, control evidence, reconciled data, tested access, service-desk readiness, and fallback can disrupt payroll, supplier payment, employee support, reporting, or regulatory activity. The playbook makes those dependencies and gates visible.
Shared services can create a single place to build specialist capability, manage demand, standardise controls, automate repeatable work, and make service performance comparable. They can also provide better career paths and knowledge reuse than small fragmented teams. Those benefits depend on scale that is actually addressable and on governance that keeps the centre accountable to users and enterprise outcomes.
A disciplined design protects mission and commercial outcomes. It keeps statutory and risk ownership explicit, isolates non-standard work, prevents uncontrolled scope migration, and makes the trade between efficiency and responsiveness inspectable. It also exposes where the real constraint is policy, source data, approval behaviour, or fragmented technology rather than the location of processing staff.
The UK Government design principles emphasise accountable leadership, taking people through change, service excellence, continuous improvement, standardisation, and interoperability. The US QSMO model adds a service marketplace, customer engagement, performance management, standards, and long-term sustainability. These public operating examples do not prove a private organisation should copy their structures, but they support the need for governed services rather than simple consolidation.
For prospective buyers, the playbook should create an honest path from assessment to implementation: map processes, quantify baselines, design the target operating model, evaluate sourcing and technology, plan transition, establish performance and control evidence, and request scoped business-consulting support when internal capacity is insufficient. Search traffic is valuable only when the resource helps a real decision and clarifies the next responsible action.
Define why a shared-services model is being considered, whose outcomes it should improve, which problems it will not solve, and which decisions are in scope. Compare consolidation with process improvement in place, automation, a centre of expertise, managed services, outsourcing, or no structural change. State the minimum evidence and benefits needed to justify transition risk and long-term dependency.
Break broad functions into services, transactions, cases, expertise, policy, and business-partnering activities. For each service define customers, users, triggers, inputs, outputs, channels, eligibility, volume, complexity, standard path, exceptions, controls, dependencies, exclusions, owner, and exit. The catalogue is the contractable boundary for design, costing, staffing, technology, measurement, and change.
Assess candidate work by repeatability, scale, variation, judgement, customer proximity, language, regulation, data sensitivity, hand-offs, seasonality, control, technology, and transition feasibility. High-volume standard work may fit a shared model; policy, statutory accountability, confidential judgement, or relationship-intensive activity may remain retained. Segment rather than move an entire named process blindly.
Specify enterprise policy, global process ownership, service delivery, customer ownership, local accountability, centres of expertise, technology and data ownership, risk, assurance, and provider roles. Define decision rights for standards, exceptions, access, controls, demand, priority, pricing, release, incident, change, and exit. Both the centre and customers need capacity to perform their retained responsibilities.
Map current variants and distinguish legal, regulatory, contractual, customer, geographic, language, risk, and value reasons from history or preference. Design a standard path, permitted configurations, and controlled exceptions with owner, evidence, expiry, cost, and review. Standardisation should remove unnecessary variation without erasing legitimate context or accessibility needs.
Create agreements that define scope, responsibilities, hours, channels, priorities, service levels, quality, controls, data, security, continuity, demand assumptions, pricing, reporting, escalation, change, dispute, and exit. Use customer councils, service reviews, user research, complaints, and transactional feedback. An SLA is not a substitute for a healthy relationship or usable service.
Forecast transactions, cases, complexity, seasonality, events, projects, language, and channel mix. Define queues, skills, priority, ageing, hand-offs, scheduling, flex capacity, overtime, backlog, and surge rules. Connect workforce and automation capacity to demand scenarios. A centre that only meets average demand by accumulating hidden backlog is not meeting service need.
Map each material financial, operational, legal, privacy, security, supplier, employment, and reporting risk to preventive and detective controls, evidence, frequency, owner, performer, reviewer, escalation, and remediation. Reperform control design across hand-offs; do not assume controls transfer automatically with people or technology. Preserve independent challenge and statutory accountability.
Design the service architecture across channels, workflow, case management, ERP or systems of record, identity, integration, master data, documents, analytics, knowledge, automation, monitoring, and support. Prefer standards and configuration where they meet the need, but test accessibility, security, resilience, and actual user journeys. Assign data definitions, quality, access, retention, deletion, and lineage.
Compare captive, outsourced, co-sourced, regional, global, and marketplace options against service, control, capability, resilience, culture, transition, security, data, concentration, cost, portability, and exit requirements. Conduct due diligence on providers and their subcontractors. Contracts should support evidence, change, incident response, audit, continuity, knowledge transfer, and termination - not only price and volume.
Build a transparent baseline and target model for people, technology, licences, facilities, suppliers, retained teams, transition, dual running, severance, recruitment, training, change, contingency, stranded cost, and improvement. Define fixed and variable cost drivers, allocation or pricing, demand assumptions, service credits if used, and benefit ownership. Savings are realised only when actions remove or repurpose the baseline cost.
Move services through evidence-based waves with knowledge transfer, workforce readiness, data and access migration, controls, testing, reconciliation, parallel operation where warranted, cutover, hypercare, and acceptance. Protect critical services with recovery objectives and tested fallback. After stabilisation, operate a prioritised improvement portfolio tied to user, quality, control, resilience, workforce, and financial outcomes.
Define the users, business and mission outcomes, current pain, accountable sponsor, programme owner, time horizon, geographies, entities, functions, constraints, non-goals, and decision deadline. Compare shared services with improvement in place, automation, centres of expertise, managed service, outsourcing, and no change. State the conditions under which centralisation would be rejected or reversed. Establish governance that includes customer, service, workforce, finance, risk, technology, data, security, privacy, legal, procurement, and change representation as appropriate.
Required output: outcome charter, decision statement, alternatives, stakeholder map, governance, evidence plan, scope hypotheses, non-goals, assumptions, and stop conditions.
Create a service taxonomy and catalogue from observed work rather than organisation charts. Measure transaction and case volumes, complexity, seasonality, channels, cycle time, backlog, ageing, first-pass quality, rework, errors, complaints, control results, incidents, staffing, systems, suppliers, cost, and user experience. Map processes, variations, data, hand-offs, approvals, knowledge, and statutory responsibilities. Reconcile finance and workforce baselines so savings are not double counted.
Required output: service catalogue, process and variation maps, customer and user research, demand profile, performance and control baseline, workforce inventory, technology and data map, cost baseline, and evidence limitations.
Score activities against repeatability, scale, judgement, proximity, regulation, language, sensitivity, technology, hand-offs, capability, resilience, and transition feasibility. Segment standard work from exceptions and retained judgement. Compare captive, outsourced, co-sourced, regional, global, federated, and marketplace models. Evaluate location and provider choices with service, workforce, legal, data, security, continuity, concentration, culture, cost, portability, and exit evidence. Confirm which services should not move.
Required output: scope matrix, retained-versus-shared boundary, sourcing and location options, due-diligence plan, decision criteria, selected delivery model, rejected options, conditions, and approvals.
Define policy, process, service, customer, local, specialist, technology, data, risk, assurance, supplier, and improvement roles with decision rights. Design the standard processes and exception framework, service catalogue, request and case channels, agreements, capacity model, escalation, customer governance, controls, data and technology architecture, workforce and career model, supplier management, continuity, and change process. Build base, downside, upside, delay, and failure economics including transition and stranded cost.
Required output: target operating model, RACI or decision-rights matrix, standard process and exception design, service agreements, architecture, control matrix, workforce plan, sourcing model, continuity design, business case, funding and allocation method.
Recruit or assign leadership and service teams, agree employment and supplier arrangements, build knowledge and training, clean and govern data, configure platforms and integrations, establish identities, document procedures, and stand up service management. Test end-to-end user journeys, accessibility, capacity, security, privacy, controls, reconciliation, reporting, incidents, recovery, provider escalation, and customer support. Set wave-specific entry and exit criteria; unresolved critical gaps block transition.
Required output: mobilisation plan, staffed organisation, knowledge inventory, training evidence, configured technology, migrated test data, tested controls, capacity evidence, support model, continuity exercise, cutover rehearsal, and readiness decision.
Sequence waves by dependency, learning value, customer readiness, volume, risk, system availability, workforce timing, and rollback feasibility. Complete knowledge transfer, access, data migration, opening balances or case inventories, control evidence, communications, capacity, and support before cutover. Use parallel processing or reconciliations where consequence justifies it. Monitor backlog, errors, user impact, controls, cost, and staff welfare daily during hypercare. Accept each wave explicitly rather than assuming silence means success.
Required output: wave plan, transition runbook, data and work reconciliation, knowledge sign-off, communications, rollback criteria, hypercare dashboard, issue and risk log, control evidence, customer acceptance, and benefits update.
Prioritise critical service, control, data, technology, workforce, and user issues before declaring transformation complete. Compare real demand, capacity, service, quality, incidents, cost, and customer experience with assumptions. Resolve shadow work and ownership gaps. Retire old queues, suppliers, licences, access, spreadsheets, data copies, facilities, and roles only after dependencies and retention duties are verified. Update agreements and baselines to the accepted live model.
Required output: stabilisation report, accepted service baseline, closed critical defects, shadow-work review, realised-cost evidence, decommissioning record, updated catalogue and agreements, operational ownership, and programme-to-service handover.
Run tiered service, customer, supplier, risk, workforce, and executive reviews with a single evidence model. Manage demand, capacity, backlog, quality, controls, experience, cost, resilience, and improvements. Use root-cause analysis to reduce avoidable contacts and exceptions rather than only accelerate handling. Revalidate sourcing, technology, data, location, pricing, continuity, and retained roles after material change. Maintain provider and platform exit plans, and retire or redesign services that no longer create sufficient value.
Required output: operating dashboard, service-review cadence, customer and user feedback, control assurance, financial reconciliation, supplier scorecard, improvement portfolio, continuity tests, change register, renewal decision, and tested exit plan.
A hypothetical regional group has four legal entities using two finance systems. Each entity receives invoices through email, local portals, and paper. Approval rules, tax handling, supplier-master ownership, payment calendars, and exception practices differ. The stated goal is to create an accounts-payable shared service, but the baseline shows that many delays begin with missing purchase orders, duplicate supplier records, and late approval rather than invoice processing speed.
The team decomposes the process into supplier onboarding, invoice intake, validation, matching, exception resolution, approval support, payment proposal, query handling, reconciliation, reporting, policy, tax judgement, treasury release, and local statutory accountability. Standard intake, validation, matching, case management, and routine queries are selected for the centre. Policy, bank release, material tax judgement, high-risk supplier approval, and statutory sign-off remain with named retained owners.
The target model uses one service catalogue and portal, entity-specific configuration only where evidence supports it, common data definitions, segmented queues, and role-based access. Service agreements define receipt confirmation, matching, exception ageing, payment-cut-off support, first-contact resolution, quality, control evidence, escalation, continuity, and customer responsibilities. A chargeback model separates a fixed platform and control layer from volume and complexity drivers, with no incentive to suppress legitimate support.
The first wave moves one entity and a bounded supplier cohort. Readiness requires clean supplier keys, migrated open items, reconciled balances, trained staff, tested interfaces, approved identities, successful duplicate and segregation-of-duties controls, capacity for the seasonal peak, and a manual fallback for critical payments. For two cycles, the team reconciles invoice status and payment proposals against the previous process. Hypercare monitors backlog age, unmatched invoices, duplicate attempts, blocked payments, user contacts, control exceptions, and team load.
The example is illustrative, not a Rusaka client result. A real organisation must replace all volumes, controls, roles, legal duties, locations, systems, costs, service targets, workforce assumptions, and transition gates with current evidence and qualified employment, tax, legal, privacy, security, procurement, finance, and risk review. The lesson is the decision chain: diagnose demand and failure, segment work, design retained accountability, prove readiness, reconcile transition, and operate the service as a product.
Use a catalogue that starts with user outcomes and end-to-end services, not departments or system modules. Observe users, cases, hand-offs, and exceptions. A clean organisation chart can still create a fragmented journey if each team optimises only its step.
Name who owns policy, risk acceptance, statutory decisions, business partnership, local workforce action, data, technology, and supplier relationships. Give retained teams capacity, skills, and measures. Do not treat everything outside the centre as an informal customer obligation.
Set a common process and data model, then record permitted variation with reason, owner, cost, risk, expiry, and review. Remove preference-driven customisation while protecting legal, accessibility, language, customer, and material-risk needs.
Combine timeliness with first-pass quality, aged backlog, repeat contact, task completion, user effort, complaints, exceptions, control, resilience, and outcome evidence. Segment severe and priority cases so favourable averages do not conceal harmful tails.
Track arrival, complexity, seasonality, channel, source, avoidable demand, backlog age, and forecast events. Connect capacity to scenarios. Work with customers to remove upstream causes rather than merely add staff to absorb preventable errors.
Inventory policy, procedure, decision, exception, contact, calendar, and tacit knowledge. Assign owners and review dates. Test whether a trained person can complete representative cases without the incumbent present before accepting transfer.
Use service-specific entry and exit criteria for people, process, technology, data, controls, capacity, support, continuity, and customer readiness. A programme date is a constraint, not proof that a service is safe to move.
Define the population, control totals, cases, balances, records, access, and reports that must agree between old and new paths. Investigate differences and obtain named acceptance. Do not rely on aggregate counts when material items have different risk.
Communicate what is known and unknown, engage affected employees and representatives, plan fair selection and transfer processes, support wellbeing, retain critical knowledge, and build credible roles and careers in the new model. Obtain current employment advice.
Remove unnecessary steps, approvals, variants, and failure demand before automation. Automate bounded work with monitoring, exception handling, access control, change management, and accountable human routes. Do not use automation to hide unresolved policy.
Maintain service, risk, security, privacy, financial, continuity, subcontractor, change, innovation, audit, and exit governance. Validate provider evidence and exercise escalation. Contract language is not proof that an operational control works.
Choose chargeback or allocation rules that are understandable, reconcilable, and aligned with desired behaviour. Avoid measures that reward the centre for rejecting valid demand, encourage customers to build shadow teams, or make transparent exception reporting financially punitive.
Track each benefit to an owner, baseline, action, timing, dependency, and finance validation. Capacity released but retained elsewhere is not cash saving; it may be a valuable productivity benefit, but it should be labelled accurately.
Test critical-service fallback, recovery time, data restore, provider outage, cyber incident, staff unavailability, and customer communication. Maintain data, knowledge, licence, access, and transition provisions that make provider or platform exit executable.
A target can force scope before service demand, controls, transition, and retained work are understood. Build the service baseline and target model first, then distinguish cash, capacity, avoidance, quality, and risk benefits.
Broad labels hide policy, judgement, statutory duties, cases, and variants. Decompose the service and move only work that fits the model, with retained ownership and explicit interfaces for the rest.
Consolidation can scale rework, bad data, unclear approvals, and user frustration. Diagnose root causes, standardise policy and data where possible, and redesign the journey before or alongside transition.
The centre cannot own every enterprise decision. Late retained design creates gaps, shadow teams, duplicate cost, and conflict. Define reciprocal responsibilities and capability in the target model and service agreements.
A platform can encode workflow but cannot decide accountability, service boundaries, exceptions, customer governance, or control ownership. Resolve these decisions before customisation and test them through real user journeys.
Average response time can coexist with aged cases, low quality, repeat contact, control failure, or poor priority service. Use distributions and segmented outcome, experience, quality, control, resilience, workforce, and financial measures.
A portal can shift effort to users, increase repeat contact, or exclude people if content, workflow, accessibility, language, and exception routes are weak. Measure task completion and user effort, not portal adoption alone.
Knowledge transfer, data cleanup, testing, backfill, parallel processing, hypercare, severance, recruitment, and backlogs consume real capacity. Excluding them creates an optimistic business case and a fragile cutover.
A control owned by a local manager may fail when work moves. Redesign performer, reviewer, evidence, timing, segregation, escalation, remediation, and assurance across the new hand-offs before transition.
Uncontrolled variation removes scale and makes technology brittle. Require evidence, ownership, cost, risk, expiry, and review for exceptions; provide configuration only where it is materially justified.
Late approvals, poor master data, bypassed channels, and incomplete requests can damage service performance. Define customer responsibilities and measures, then collaborate on root causes rather than using them only to reject SLA accountability.
The centre may appear efficient while business units perform rework, chase cases, or maintain shadow teams. Measure end-to-end cost and effort, including customers and retained functions, with user outcomes and control quality.
Go-live begins operational proof. Stabilisation must demonstrate service, controls, reconciliations, user experience, cost, workforce health, continuity, and closure of the old model before transformation benefits are accepted.
Without current data export, knowledge, licence rights, transition assistance, capacity, and tested fallback, exit can be prohibitively risky. Maintain the plan and evidence throughout the relationship.
Take one broad process and list its transactions, cases, policy decisions, expert judgements, controls, customer interactions, data stewardship, supplier decisions, and statutory accountabilities. Add volume, complexity, consequence, and required proximity. This usually reveals several service patterns inside one process name.
Only then evaluate whether each activity belongs in a common centre, retained organisation, centre of expertise, local team, provider, or automated path. Location and sourcing are downstream decisions. Premature location selection encourages teams to force unsuitable work into a predetermined answer.
Define not only what the centre owes customers, but what customers and retained teams owe the service: complete requests, timely approvals, accurate master data, designated contacts, forecast events, use of approved channels, and participation in controls. Connect failures on either side to root-cause work rather than automatic blame.
Include scope, priority, clocks, pauses, quality, controls, data, security, continuity, pricing, reporting, escalation, dispute, change, and exit. Test the language on real cases. If operators and users cannot determine who acts next from the agreement, it is not operationally complete.
For each service, define entry evidence across people, process, technology, data, access, controls, capacity, provider, support, continuity, communications, and customer readiness. Name the authority that can delay the wave and the conditions that allow a documented exception. Avoid gates that can only report red while the date remains fixed.
Exit evidence should cover reconciliation, backlog, priority cases, controls, user impact, incidents, team capacity, and fallback. During hypercare, publish the true state and trends. A transition is accepted when evidence meets the agreed threshold and owners sign the residual risk, not when the project calendar moves on.
Measure what customer teams still do after transition: chasing cases, correcting data, answering local questions, maintaining trackers, performing informal approvals, or duplicating controls. Compare end-to-end effort with the baseline. Shadow work can explain why centre unit cost appears low while the organisation experiences no benefit.
Assign each benefit to an action that changes real cost, capacity, quality, risk, or experience. If released time is reinvested, record the new output rather than call it cash saving. If roles or systems cannot be removed because a dependency remains, update the forecast instead of carrying an unrealised benefit indefinitely.
Keep current service inventories, critical dependencies, data exports, schemas, knowledge, procedures, roles, supplier and subcontractor contacts, licences, credentials, recovery objectives, manual workarounds, and transition assistance. Define who can invoke fallback or exit and how customers will be informed.
Exercise realistic disruptions and at least one recovery path for critical services. An annual document review does not prove that data can be restored, capacity can be mobilised, or a provider hand-off can occur. Track actions to closure and retest material gaps.
A shared-services decision begins with services, users, demand, controls, and evidence - not a location, provider, platform, or headcount target. Decompose work, distinguish shared execution from retained accountability, compare alternatives, and state what would invalidate the model.
Design the centre and its ecosystem together: catalogue, standards, exceptions, retained organisation, service agreements, capacity, controls, technology, data, suppliers, economics, workforce, customer governance, continuity, and exit. Benefits should be end-to-end and traceable to real actions rather than moved budgets.
Transition is an operational risk event. Move in evidence-based waves, reconcile work and data, protect critical outcomes, support people and users, and require explicit acceptance. Then operate shared services as a product with transparent performance, root-cause improvement, tested resilience, renewal, and the ability to change or exit safely.
Shared services consolidate repeatable capabilities so multiple business units, entities, or agencies consume them through a governed service. The model normally includes a catalogue, standard processes, retained responsibilities, service agreements, performance evidence, customer governance, common technology or data, and continuous improvement. It can be internal, outsourced, co-sourced, federated, regional, or global.
Common candidates include high-volume finance, procurement, HR administration, payroll support, technology service, data operations, legal operations, and customer administration. Suitability depends on repeatability, scale, variation, judgement, customer proximity, regulation, data sensitivity, controls, technology, resilience, and transition feasibility. Segment activities rather than assume an entire function should move.
Retain enterprise policy, statutory and risk accountability, strategic business partnership, material judgement, local employment or regulatory decisions, customer ownership, and other responsibilities that cannot be delegated safely. The exact boundary varies. Define roles, decision rights, capacity, skills, funding, and interfaces rather than leaving retained work implicit.
Shared services is an operating model; outsourcing is one sourcing choice. A shared service may be captive, externally delivered, or co-sourced. Even with an external provider, the organisation retains accountability for strategy, policy, risk, customer outcomes, data, supplier governance, controls, and exit according to the context.
Build a service catalogue, baseline actual demand and performance, decompose each process, and score activities against repeatability, scale, judgement, proximity, regulation, language, sensitivity, technology, controls, resilience, economics, and transition readiness. Compare structural change with improving the process where it sits. Record exclusions and reversal triggers.
For each service record customers, users, outcome, triggers, inputs, outputs, channels, eligibility, standard path, complexity, volume, hours, priorities, exclusions, exceptions, dependencies, controls, data, owner, service levels, price or allocation, escalation, change, and exit. Keep it aligned with the live operating model.
Use end-to-end measures for demand, freshness or backlog age, timeliness, first-pass quality, accuracy, rework, repeat contact, task completion, user effort, complaints, controls, incidents, recovery, workforce, supplier, cost, and benefits. Show distributions and priority segments. Average SLA and unit cost alone can hide poor outcomes.
An SLA defines agreed service conditions and measurable commitments. User experience captures whether people can understand, access, complete, correct, and obtain help through the service with reasonable effort. A service can meet response-time SLA while creating repeat contacts or inaccessible journeys. Measure and govern both.
There is no universal method. Separate fixed platform, governance, and control costs from volume, complexity, project, or optional-service drivers where practical. Use understandable data and reconcile allocations. Test whether pricing encourages the desired behaviour or drives bypass, shadow teams, under-reporting, or avoidance of valid support.
Link each benefit to a baseline, calculation, owner, action, timing, dependency, evidence, and finance approval. Distinguish cash saving, released capacity, cost avoidance, quality, experience, control, resilience, and strategic value. A transferred budget, vacant role, or optimistic productivity assumption is not automatically realised benefit.
Require evidence for staffed roles, knowledge, standard process, exceptions, technology, migrated and reconciled data, identities, controls, capacity, supplier readiness, service desk, user communications, continuity, cutover, rollback, and customer readiness. Set service-specific entry and exit criteria and block transition when critical gaps remain.
Inventory written and tacit knowledge, assign owners, train receiving staff, and require them to complete representative standard, exception, priority, control, and incident cases without undocumented help. Track questions and gaps. Sign-off should reflect demonstrated capability, not the number of workshops held.
Classify each variation by legal, regulatory, contractual, risk, customer, language, accessibility, system, or historical cause. Remove unnecessary variation, configure justified differences, and govern exceptions with owner, evidence, cost, risk, expiry, and review. Do not erase legitimate context or accept preference as permanent uniqueness.
Needs vary, but the architecture often includes request channels, workflow and case management, systems of record, identity, integrations, master data, document management, knowledge, analytics, automation, observability, security, and support. Select technology after operating decisions, and test real journeys, controls, accessibility, capacity, recovery, and exit.
Identify critical services and dependencies, agree recovery time and data objectives, define degraded and manual modes, protect data and access, maintain alternative capacity and contacts, and exercise provider, platform, cyber, facility, utility, and workforce disruptions with customers. Record remediation and retest.
No. It is educational operating-model guidance. Shared-services obligations depend on jurisdictions, entities, services, people, contracts, data, sectors, sourcing, and transactions. Obtain current qualified review and formal organisational approvals before decisions that affect rights, employment, statutory duties, regulated work, personal data, controls, or suppliers.
Submit an email to download the Shared Services Playbook implementation workbook