Managed Services Operating Models

Managed services contracts come in shapes that look interchangeable on a procurement deck and operate completely differently in practice. The deck talks about SLAs, response times, and named accounts; the operational reality is who actually owns the platform when something goes wrong at 3am, how change requests are handled when the business needs them done quickly, and whether the managed services partner is a contributor to the platform's evolution or just a keep-the-lights-on operator.

This piece is the framework we use to evaluate managed services models for enterprise platforms — what each model is actually doing, where it fits, and the signs that the model has stopped working for the workload.

The four common models

Strip away the vendor-specific positioning and managed services contracts in enterprise IT cluster into four operating models:

Model A — Internal operations team. The organisation operates the platform itself. Staff engineers, on-call rotation, ops tooling owned internally. No external dependency.

Model B — Partner-staffed operations. External staff working as if internal — embedded in the team, using internal tooling, on the internal on-call rotation. Often billed as time-and-materials or as a fixed FTE allocation. The partner provides people; the operating model is internal.

Model C — Partner-managed with internal oversight. The partner operates the platform with their tooling and processes; the internal team provides oversight, demand management, and strategic direction. The partner is accountable for SLAs; the internal team is accountable for outcomes.

Model D — Fully outsourced. The partner operates everything end-to-end. Internal team is small, focused on vendor management. The partner makes day-to-day operating decisions independently.

Each works for different workloads, organisations, and risk appetites. None is universally right.

Where each model fits

Model A — internal operations works when:

• The platform is genuinely core to the business
• The organisation has the engineering capacity to staff operations
• The operational learning is valuable institutional knowledge
• The cost is justified by the criticality

Most large enterprises have at least one platform on Model A — typically the platform that runs core revenue, regulatory commitments, or competitive differentiation.

Model B — partner-staffed works when:

• The organisation needs capacity quickly without long-term hiring commitment
• The required skills are scarce and the partner can attract them
• The institutional knowledge transfer is structured (the partner staff are genuinely working as the team, not as a temporary supplement)

Model B is common during ramps — a new platform is being stood up, the partner staff fill in while internal hiring catches up, and the model migrates to A over 18 months.

Model C — partner-managed works when:

• The platform is important but not differentiating
• The partner has operational excellence the organisation doesn't have and doesn't want to build
• The operational SLAs are well-defined and contractable
• The internal team retains strategic direction and demand management

Model C is the most common shape for managed services in regulated enterprises — webMethods estates, integration platforms, BPM platforms, observability stacks, cloud infrastructure operations. The platform matters; the organisation doesn't need to be world-class at operating it.

Model D — fully outsourced works when:

• The platform is commodity, not strategic
• The vendor relationship is mature and trusted
• The organisation has bigger problems to solve than this platform
• Day-to-day decisions don't materially affect business outcomes

Model D is appropriate for less than people think. Most "fully outsourced" arrangements have hidden internal dependencies that surface during incidents.

What good managed services contracts include

Beyond the headline SLAs, the contracts that work in practice specify:

Response, restore, and resolve times for each priority tier. Response time is acknowledgement; restore time is service available again; resolve time is root-cause fix delivered. Confusing these is the most common contract failure.

Defined scope of operational work. What the managed services partner does. Equally important: what they don't do. Out-of-scope work needs an explicit process for getting it done.

Change management process. How the customer requests changes. How urgent changes are handled. Whether the partner can deploy changes autonomously or only with customer approval. Whether change failure rates are tracked.

Capacity and cost transparency. How the partner sizes the platform. How cost is calculated. How capacity changes are agreed.

Knowledge transfer and exit planning. If the customer wants to bring operations internal or transition to a different partner, what the partner is contractually obligated to provide. Without this, the customer is captive.

Continuous improvement commitments. What the partner does proactively to improve the platform, not just keep it running. Without continuous improvement clauses, partner-managed estates ossify.

The contracts that produce the most operational pain are the ones written by procurement without engineering input. The engineering reality of what good operations looks like is documented in the contract details, not in the SLA headlines.

The signals that a model is failing

Each model has characteristic failure modes:

Model A failing: Operations engineers leave faster than the team can replace them. Incident response degrades as institutional knowledge departs. The platform increasingly relies on heroics from a small number of remaining senior engineers.

Model B failing: The partner staff become a parallel team rather than an integrated one. Knowledge stays with the partner staff rather than transferring. When the partner staff leave (rotate, contract ends), institutional knowledge leaves with them.

Model C failing: The partner operates the platform mechanically — incidents are resolved, change requests fulfilled, but the platform doesn't improve. The partner is doing the work in the contract and nothing more. Improvement work that isn't contractually mandated doesn't happen.

Model D failing: The customer has no operational visibility. When incidents happen, the customer learns about them from users or from quarterly reports. The platform's behaviour is opaque; the partner is the only party with insight.

The signals appear gradually. The estates that adapt usually do so by changing the model — sometimes consolidating Model B back to A, sometimes shifting Model C boundaries, occasionally moving Model D platforms to C for visibility.

Hybrid models, in practice

Most enterprise organisations end up running multiple managed services models simultaneously, with different platforms on different models. The estate-level operating model is a portfolio of decisions, not a single choice.

A typical pattern:

• Customer-facing platforms on Model A (internal ops) for strategic control
• Integration platforms on Model C (partner-managed) with internal architectural oversight
• Specialised platforms (DBA, security operations, networking) on Model B or C
• Commodity platforms (email, productivity) on Model D
• New platforms launched on Model B and migrated to A or C once operational maturity is reached

The portfolio approach lets each platform be matched to the right model. The mistake we see most often is forcing one model across the whole estate because it's administratively simpler.

What we recommend

For an organisation evaluating managed services for a specific platform:

1. Be honest about strategic importance. Is this platform a differentiator or a commodity? The answer determines which models are appropriate.
2. Assess internal capability honestly. Can the organisation actually staff this operationally? Can it attract the talent?
3. Define the contract details, not just the SLAs. Response/restore/resolve, change management, knowledge transfer, exit planning, continuous improvement.
4. Plan for the model to evolve. What changes would trigger a reconsideration? Build the trigger conditions into the contract review cadence.
5. Avoid Model D for platforms with operational visibility requirements. The opacity tradeoff is rarely worth it for non-commodity workloads.

For an existing managed services arrangement showing strain:

1. Identify the failure mode. Which signal is appearing?
2. Examine whether the model is wrong for the workload, or the contract is wrong for the model, or the operating discipline is failing within the model.
3. Adjust the smallest thing that fixes the symptom. Changing models is expensive; changing contract clauses or operating practices is often sufficient.

Managed services are the operating substrate of most enterprise platforms. The arrangements that work compound value through reliable operations, predictable cost, and gradual improvement. The arrangements that don't produce platforms that limp along, operations that need constant attention, and vendor relationships that consume more management capacity than the operations they're meant to replace.

The model is not the operating reality. The operating reality is what the contract specifies, what the parties actually do, and how the model adapts when conditions change. Getting the model right is necessary but not sufficient.