Handover: leaving a system a customer's team can run
A pilot that only works while its builder is on site is not finished. Handover is the part of the job that decides whether the system is still running, and still trusted, three months later.
Name the owners
Every part needs a person on the customer's side: the application, the prompts, the model provider account and budget, the evaluation set, and the decision about what the AI may do on its own. An unowned prompt gets edited by whoever is annoyed that day.
The runbook
| Section | What it answers |
|---|---|
| What it does and does not do | The scope agreed at discovery, and the requests it should refuse or hand to a person |
| How it is deployed | Where it runs, how to restart it, how to roll back a change |
| Models and keys | Which providers, which gateway, where keys live, how to rotate them |
| Health | The dashboards to look at, normal cost and latency, and the alert thresholds |
| When it goes wrong | Provider outage, a spike in refusals, a bad answer reported by a user: what to check and who to call |
| Changing it | How to change a prompt or model safely: run the evaluation gate first |
Leave the evaluation gate running
The golden set and the check that blocks a worse release are the most valuable things to hand over, because they let someone who did not build the system change it safely. A team without them stops changing the system, or changes it and hopes.
Known limits, written down
List what the system gets wrong today, with examples: the ticket types it misfiles, the documents it cannot read, the questions it refuses. A limit the customer was told about is a known issue; one they discover is a broken promise.
Teach, then watch them do it
- Walk through the runbook with the people who will use it
- Have them change a prompt, run the gate and deploy, while you watch
- Agree a check-in a few weeks later with the before and after numbers from discovery
- Every part has a named owner
- The evaluation gate is handed over running
- Limits are written down with examples
- The team has changed and deployed the system once before you leave
- Write the 'When it goes wrong' section for a system you built, for a provider outage
- List three known limits of that system, each with a real example
Every expert started right here.