Handover packages customers actually use
Updated
The six-line handover: what it does, how it fails, how to tell, what to do, who owns it, where the recording is.
A handover nobody opens is a second project wearing a finished label. This package gets opened because it answers the 3am questions first.
The short answer
Six lines per component: what it does, how it fails, how to tell, what to do, who owns it, where the recording is. Everything else is appendix.
The package
- Runbook. Top 3 symptoms with checks and actions. Tested by someone who did not write the code.
- Architecture diagram. One page: boxes, arrows, data stores. Dated.
- Data-flow map. What moves where, PII flagged, retention noted.
- Ownership table. Every component has a name and a backup. Signed.
- Training recording. 30-60 minutes, chapters, stored where the team looks.
- Metrics and review date. Success numbers plus the 90-day review on a calendar.
Worked example: the silent-watch test
Before sign-off, a fictional customer engineer (fictional) gets paged with a staged symptom and only the package. The FDE watches without speaking. First run: 25 minutes, two missing steps found. Runbook fixed, second run: 9 minutes. That gap is the value of the test.
Checklist: handover that holds
- No empty rows in the ownership table.
- Runbook tested by a non-author.
- Recording watched at 1x by at least one owner.
- Review date on a real calendar with invites sent.
Related reading
Straight answers
Frequently asked questions
What is in a handover package?
Runbook, architecture diagram, data-flow map, ownership table, training recording, and the success metrics with their review date.
When does handover start?
Week one. Owners are named before building; the runbook grows with the system instead of being written in panic at the end.
How do you know it worked?
The customer's engineer debugs a real symptom using only your package while you watch silently.