The team that was meant to be building the next release is instead answering questions about the last one, and the capacity assumed in the business case never materialises.
How an engagement runs
Taking over happens once and handing back happens once. What repeats is the pair in the middle, and one half of that pair exists to reduce what we bill.
Transition
These two run as a loop
Operate
Improve
Exit
What we run, and what does not transfer
Every provider lists what it takes over. The half that matters is what stays yours, because that is the half a client discovers late.
We operate
Stays with you
Infrastructure
We operate
Monitoring, patching, capacity, backups, and restore tests that are actually performed.
Stays with you
What the environment has to survive. Recovery targets state acceptable business loss, and an operator should never set them.
Application lifecycle
We operate
Releases, environment consistency, and regression coverage over the paths you name.
Stays with you
Which paths matter, and the go or no-go. We can say what the tests said, not what your risk appetite is.
Data
We operate
Pipelines, quality checks, and execution of the retention schedule.
Stays with you
The data, and the schedule itself. We run the retention rule; your legal function decides what your obligations are.
Integration
We operate
The integration layer, its interfaces, and the monitoring that says when one has gone quiet.
Stays with you
The systems on either side and their suppliers’ roadmaps. When an interface changes, we adapt; we do not control when.
Service desk
We operate
Intake, triage, escalation, and the evidence trail behind all three.
Stays with you
Entitlement. Who may ask for what is your decision; a supplier quietly making it is how shadow policy starts.
What you walk away with
Four pieces of work, one per stage of the cycle above. Each is what that stage actually produces, rather than what it is called.
The system running without the people who built it
Knowledge captured while the people who hold it are still there, written as procedures somebody else can follow, and then run in parallel by us with your team watching before responsibility actually moves. The handover is finished when we have run it, not when the documentation is delivered.
The shadow period is the part that gets cut when a start date slips, and transitions that skip it fail in the third month with reliable consistency. By then the people who knew the answers have moved on to something else and the knowledge that was supposed to have been captured is gone.
What this buys back is the capacity the original business case assumed: the team that was meant to be building the next release stops answering questions about the last one.
Cover you can name, staffed by people you can name
A defined coverage window, defined response commitments, a named escalation path, and a written line between what we run and what you keep. Everything inside that line is ours; everything outside it is explicitly yours, and both lists exist before anybody signs.
The reason to write the boundary rather than describe the service is that unwritten scope always resolves in the same direction. "Look after it" becomes a list before signing, and the list is shorter than everything, which is what makes the commitment worth anything.
Personal data stays inside the processing locations named in the contract, under access control we can evidence, and the delivery locations are named. If they change, you hear it before it happens rather than after.
A ticket queue that gets shorter
Recurring incidents treated as defects rather than as workload. Where the same ticket arrives every month, the objective is to remove the cause, which means the volume we are paid to handle goes down over the life of the contract.
It is worth being blunt about the incentive, because it runs against us and that is the point. A provider paid by volume has no reason to reduce volume, which is how a managed service quietly becomes a subscription to a problem nobody is fixing.
The measure of whether it is working is not the response time. It is whether the same incident is still arriving in month eighteen.
The ability to leave, kept current from day one
Handover documentation maintained throughout the engagement rather than written at termination, reciprocal handover obligations in the contract, and no exit clause we would not accept ourselves if the position were reversed.
Documentation written at the end is written by people who are leaving, about a system they are no longer responsible for, under time pressure. It is the worst possible moment to produce the one artefact that determines whether you are actually free to go.
A provider that has made leaving straightforward has to keep earning the work, which is the only version of this relationship worth being on either side of.
We run it under a scope, a coverage window and an exit that are all written down before we start, so handing it back is a planned step rather than a negotiation.
Managed operations, asked plainly
What does managed operations cover?
Running what has been built: the platforms, the integrations and the governed content, with a defined scope, defined coverage window, defined escalation path and a defined exit.
Is this outsourcing?
It is narrower than that word usually means. We run a defined set of systems against a defined standard rather than absorbing a function, and the boundary is written down precisely so that nobody discovers it during an incident.
What happens if we want to bring it back in house?
The exit is part of the agreement rather than a negotiation at the end of it. Handing back is a planned step with a date, a scope and the documentation to support it, which is the difference between a contract and a dependency.
How is performance measured?
Against the agreed standard, reported from the systems rather than compiled by hand, so the report is a query and the same evidence answers an auditor as answers you.