Service
Enablement & handover
Our success condition is that you do not need us. Everything here exists to make that testable rather than aspirational.
A handover is complete when your team can do four things without us: deploy a change, diagnose a failure, evaluate whether a change made things better, and explain the system to somebody who was not there.
We test that by inverting the working arrangement at the end of an engagement. Your team drives (a real deployment, an injected failure, an addition to the evaluation set) and we watch and take notes. Wherever they hesitate becomes the last documentation we write.
What you get
Named artefacts, not a slide pack. Each one is a thing your team can open, run, or hand to an auditor.
| Artefact | What it contains |
|---|---|
| Exit criteria | Agreed in writing during Frame: which capabilities transfer, to whom, by when, and what evidence demonstrates each. |
| Runbook | Assembled from the incident log of the engagement, failures that actually happened, with what fixed them. |
| Architecture decision records | Including rejected options and what would justify revisiting them, so future engineers do not re-litigate settled choices blindly. |
| Enablement sessions | Working sessions on the parts your team will change most, run against the real system rather than slides. |
| Handover rehearsal | Your engineers deploy, diagnose an injected failure, and extend the evaluation set while we observe. |
| Support arrangement | Optional, explicit and time-bound. Structured so that not using it is the expected outcome. |
How it runs
01 · During Frame
Agree
Exit criteria written before code exists, when nobody is invested in a particular answer.
02 · Throughout
Embed
Pairing in your repositories, your review process, your pipeline, from Prove onwards, not retrofitted.
03 · 1–2 weeks
Rehearse
Your team drives; we watch and document the hesitations.
04 · 2 weeks
Step back
We stay reachable and stop being in the path.
What we use
Chosen per engagement against your constraints. We have no reseller relationships and no incentive to recommend one of these over another.
Practice
What we do not do
Knowing where our usefulness stops saves everyone a procurement cycle.
- We do not hold credentials, keys or repositories after handover.
- We do not structure support agreements to make leaving expensive.
- We do not claim a handover is complete because documentation exists. It is complete when your team has demonstrated the four capabilities.
Questions we are asked
Does this not reduce your revenue?
It reduces follow-on revenue from clients who cannot leave, and increases it from clients who choose to come back. That is a deliberate commercial decision and we would rather state it plainly than present it as a philosophy.
What if our team lacks the skills to take it on?
Then that is a finding for Frame, not a surprise at the end. Sometimes the honest answer is a smaller system your team can actually own, and we would rather build that.
What does support look like if we want it?
Time-bound, scoped to defined system areas, with a review date. We report usage against it, and a support agreement nobody uses is a successful one.
Start with the constraint.
Most of these projects are shaped by what you cannot do rather than what you want. Data that cannot leave the estate, a model you cannot host with a third party, a decision somebody has to justify to a regulator. Tell us yours and we will say honestly whether we can work inside it.