Sourcing decisions / Capacity or service
Decide which responsibility you want to buy.
Adding an engineer and assigning a service to a provider solve different problems. Augmentation supplies a contribution inside your delivery system. A managed service gives the provider agreed operating responsibilities within a defined boundary. Compare the work and decisions each proposal includes before comparing its fee.
The responsibility difference
Buy a contribution, or agree a service obligation.
Staff augmentation adds external capability to work that the client directs and integrates. A managed service assigns the provider specified operating responsibilities, with an agreed scope and a way to assess performance. The provider owns those commitments, not every dependency or business outcome. The client still needs an owner who can make decisions, inspect performance and resolve work outside the agreement.
- Direction
- In augmentation, your lead assigns and reviews the contribution. In a managed service, the provider organizes covered work within the agreed authority and escalation rules.
- Evidence
- An augmented contribution enters your acceptance process. A managed service must also show whether its agreed service obligations were met. Hours supplied and tickets closed are incomplete evidence on their own.
- Commercial terms
- A monthly invoice does not establish a managed service. Read the responsibilities, exclusions and change terms. Neither model automatically establishes a price format or an unconditional result.
Three buying situations
Match the proposal to the missing responsibility.
These are illustrative arrangements, not fixed packages. A provider must demonstrate the capability and authority needed for the work it proposes to own.
Your team can lead but lacks a skill
01Consider: Augmentation may address a defined contribution inside an established delivery system.
- Fit condition
- Your team has usable work, available leadership and a reviewer who can integrate the result.
- Client supplies
- Context, permitted access, priorities and an acceptance path.
- Example
- An external engineer implements an import validation change assigned and reviewed by your lead.
- Retained decision
- Your product and technical owners decide the intended behavior and approve integration.
- Inspect
- The contribution works with the surrounding application and enters the existing release process.
- Watch for
- More capacity creates a review queue because the missing role was leadership.
- Before agreeing
- Confirm the contribution, supervision and continuity arrangements.
A defined service needs ongoing operation
02Consider: A managed service may fit work with a describable operating boundary and agreed performance evidence.
- Fit condition
- Covered systems, responsibilities and client dependencies can be made explicit.
- Client supplies
- A service owner, business decisions and access appropriate to the agreed work.
- Example
- A provider monitors and handles failures in a named import service, within agreed coverage and escalation terms.
- Retained decision
- The client decides acceptable business disruption and approves consequential data or workflow changes.
- Inspect
- A service record connects the event, provider action, dependency and confirmed result.
- Watch for
- The proposal promises an outcome while excluding the components required to produce it.
- Before agreeing
- Test an ordinary event and an exception against the proposed boundary.
One team changes what another operates
03Consider: Use both models only with an explicit build-to-operation interface.
- Fit condition
- Client-led development and provider-managed operation have distinct, useful responsibilities.
- Client supplies
- A shared service definition, receiving owner and change acceptance criteria.
- Example
- An augmented engineer changes the importer; the operating provider accepts the revised runbook and monitoring before taking responsibility.
- Retained decision
- The client resolves product decisions and any gap between the two agreements.
- Inspect
- The receiving operator can diagnose a representative failure using the accepted change record.
- Watch for
- Development calls the change complete while operations treats it as unsupported.
- Before agreeing
- Name who owns the service during transition and who handles rejected changes.
Compare the agreements
Put the responsibility beside the price.
Use the same underlying work when reading both proposals. Different obligations may justify different costs; record the difference rather than treating the offers as interchangeable.
| Decision area | Augmentation | Managed service | Client still supplies | Unresolved gap |
|---|---|---|---|---|
| Direction | Client leads assigned contribution | Provider organizes covered service work | Business priorities and decision access | Both expect the other to manage |
| Boundary | Role, contribution and working arrangement | Included service, coverage and dependencies | Work outside the agreed scope | An essential component is excluded |
| Evidence | Reviewed and integrated contribution | Agreed service measures and result records | Acceptance and performance oversight | Activity is treated as a result |
| Authority | Permitted actions within client workflow | Authorized operating and escalation actions | Policy, data and consequential decisions | Access exceeds the assigned duties |
| Change | Client reprioritizes within agreement | Service changes assessed and accepted | Approval of material scope changes | New work assumed to be covered |
| Continuity and cost | Include direction, review and handover | Include transition, exclusions and oversight | A capable receiving owner | Fee omits retained work |
Walk through an exception
A failed import makes the boundary visible.
Illustrative exercise: a scheduled import rejects a changed source format. Under augmentation, trace how your lead assigns investigation and accepts the repair. Under a managed service, trace whether detection, diagnosis and repair are covered, and who handles a source-system change outside scope. Do not assume either proposal includes this work.
- 01
Describe the service impact
State what stopped, which users or processes depend on it and who can determine the business priority. Avoid assigning urgency from a technical error alone.
- 02
Follow the first action
Identify who notices, records, directs and investigates the event. For augmentation, identify the available client lead. For a service, identify the applicable obligation.
- 03
Find the excluded dependency
Ask what happens when repair requires a change to the source system. Name the receiving party and keep the unresolved event visible while that decision is pending.
- 04
Define completion evidence
Decide who checks the accepted data and downstream behavior. Record what constitutes restoration, a temporary workaround and a lasting repair for this service.
- 05
Reconcile the whole arrangement
Compare provider charges with client direction, oversight, coordination and transition effort. Resolve unowned steps before selecting the commercial model.
Keep the agreement operable
Delegated work still needs a client owner.
The client should be able to understand what is happening, make its required decisions and continue the service if the arrangement changes.
- Make service measures meaningful
- Agree coverage, severity, clock rules and the distinction between response and resolution. Review dependencies and exceptions alongside performance figures.
- Bound operational access
- For cloud operation, map client, MSP and cloud-provider duties separately. Grant privileges for the assigned work and retain visibility of provider actions.
- Keep change visible
- A new integration or source format may alter the work. Decide who assesses it and accepts the revised responsibility before relying on the old service description.
- Plan a usable exit
- Specify the records, access and receiving support needed to continue the agreed work. Test that a permitted receiver can use the handover, rather than counting transferred files.
Questions before selection
Read the commitments behind the label.
An attractive roster or service name is a starting point. The agreement must explain how the work will actually be directed and accepted.
- Does managed mean the provider owns everything?
- No. The provider owns agreed service responsibilities within a boundary. Client decisions, excluded systems and third-party dependencies need explicit owners. A service commitment does not guarantee a broader business outcome.
- Are managed services always fixed-price and available 24/7?
- No. Confirm fees, included work, service hours, response arrangements and exclusions. Neither the name nor a recurring invoice establishes those terms.
- Is an SLA enough to define the service?
- It needs a usable service description, responsibilities, measures, dependencies and an agreed response to missed commitments. A headline target alone leaves too much undefined.
- Can augmented staff work alongside a managed provider?
- Yes, where responsibilities connect. Agree how development changes become supported service work, who accepts the handoff and who owns an exception between the two arrangements.
- Which model requires less client management?
- A managed service can delegate specified operational management, but it still needs decisions and oversight. Compare the actual retained workload. If nobody can own priorities or accept the service, resolve that gap before buying either model.
Source basis
Guidance for defining the operating agreement.
- 01
GOV.UK Service Manual
Working with contractors or third partiesOctober 2024 guidance reviewed for skills, integration, permitted access and knowledge transfer. Government procurement preferences are not generalized.
- 02
NCSC
Choosing a managed service providerNovember 2025 guidance reviewed for included services, responsibilities, reporting, response and exit questions. Its example timings are not adopted as service commitments.
- 03
IBM
What is a service-level agreement?May 2024 explainer reviewed for service descriptions, responsibilities, metrics, exclusions and review. Numerical examples and legal provisions are not imposed on engagements.
- 04
NCSC
Cloud security shared responsibility modelReviewed June 2023; main responsibility and MSP sections inspected. Informs the client, MSP and cloud-provider split, appropriate privileges and audit visibility. Cloud-platform preferences are outside this comparison.
Start with one real workflow
A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.
Show Us the WorkflowStart with the free automation readiness checklistOBSERVEQUANTIFYDECIDEBUILD