Key takeaways
- Centralize a process only when its definition, evidence and service boundary are stable across participating companies.
- Local variance is not automatically waste. Customer promises, licenses, safety conditions and accountable judgment may require local control.
- Use more than two destinations: shared execution, shared platform with local execution, shared standard, coordinated exception service, or fully local work.
- Pilot with a service contract, exit criteria and a fallback path. A new shared queue without authority and exception ownership only moves the bottleneck.
Decide at process level, not department level
“Centralize finance” or “keep operations local” bundles unlike work. A weekly KPI pack, a disputed customer promise and a physical safety decision may sit in one department but need three different operating models.
The GSA shared-services model emphasizes common business and data standards, accountable governance and an escalation path for unresolved inconsistencies. The useful lesson for a small portfolio is structural: a provider needs a defined service and a customer needs a retained owner.
| Question | Shared signal | Local signal |
|---|---|---|
| Definition | Same finish and field meaning | Materially different promise or obligation |
| Evidence | Accessible, structured sources | Context lives in people or physical inspection |
| Variance | Known, bounded exception classes | Novel cases dominate |
| Consequence | Reversible preparation or routine effect | Safety, legal, financial or relationship commitment |
| Authority | Shared role has explicit permission | Accountability remains with named local role |
Use five operating routes instead of a binary answer
| Route | What is shared | What stays local |
|---|---|---|
| Shared execution | Complete routine path and exception service | Demand signal and accountable service owner |
| Shared platform | Data structure, queue and evidence | Execution and decision authority |
| Shared standard | Definitions, minimum controls and output contract | Tool and operating path |
| Shared preparation | Collection, validation and proposal | Approval and consequential effect |
| Local execution | Portfolio visibility and escalation only | Process, authority, relationships and recovery |
Write the service contract before moving the queue
- 01Name the service eventTriggerDefine what enters, who may submit it and when the service clock starts.
- 02Fix the evidence contractCodeList required sources, freshness, identifiers, validation and how missing evidence is returned.
- 03Bound shared authorityHuman approvalState what the provider may decide, propose, reject or never perform.
- 04Design exception ownershipHuman approvalEvery refusal, conflict and timeout needs a named local or shared owner plus an escalation clock.
- 05Test exit and fallbackCodeDefine acceptance, stop conditions, local fallback and how in-flight cases are reconciled if the pilot ends.
One weekly report moves; one customer commitment does not
Three Northline branches prepare the same weekly service pack. Definitions differ for callbacks and completed work, but every metric can be tied to a source record. The portfolio first agrees the definitions, preserves branch-level source fields and pilots shared preparation with local controller sign-off.
A disputed customer credit remains local. The shared team can assemble the job record and policy, but the branch service lead owns the relationship context and approval. The portfolio gets a visible exception and response clock rather than a centralized decision.
The example makes no staffing, savings, system or product claim.
Review the pilot as a service, not an organizational victory
- Was the right case accepted, rejected or returned with a reason?
- Did local and shared owners agree on the final state?
- Which exceptions lacked authority or evidence?
- Could a branch use the fallback without losing in-flight work?
- Did standardization erase a local requirement that should remain explicit?
Use the shared-services readiness calculator to keep portability separate from local-dependence pressure. Neither score approves a move.
Limitations and when not to use this
- This is a process-routing framework, not organizational, staffing, legal, financial, employment, tax, cybersecurity or regulatory advice.
- Federal shared-services sources illustrate governance and standards; they are not a ready-made model for a small-business portfolio.
- A common platform does not create common authority. Retain named accountable owners and specialist review for consequential work.
- Northline is simulated. No savings, service level, connector or customer outcome is claimed.
Sources
- Federal Shared Services: Adoption Challenges Underscore the Need for Consistent Leadership — U.S. Government Accountability Office Accessed 9 August 2026
- Enterprise Shared Services Governance Ecosystem — U.S. General Services Administration Accessed 9 August 2026
- Contingency Planning Guide for Federal Information Systems — NIST Accessed 9 August 2026
Assess shared-services readiness
Compare portability with the need for local knowledge and accountable control.
Assess shared-services readinessUli Prantz
Builds and operates all-agents
Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.