Handover documents are written at the end of a project, often in a hurry, by people who know the work so well that they forget what a newcomer does not know. They are then read weeks later, by someone who cannot ask a follow-up question.
What a usable handover contains
- What was delivered — a plain list, with where each item lives (links, systems, folders).
- How to use or run it — the everyday tasks, step by step, written for the person who will do them.
- What is not finished or not included — stated clearly, so nobody assumes it was done.
- Known issues and workarounds — with how serious each one is.
- Access and ownership — which accounts, licences and credentials exist, and who now owns them (never the passwords themselves in the document).
- Who to contact for what, and until when.
Write for the second reader, not the first
The client contact who receives the handover may understand it. The person who inherits the system six months later probably will not. Define internal names and abbreviations once, avoid “as discussed”, and point to the source of every number.
All items delivered as discussed. Minor issues pending. Reach out for any queries.
Delivered: 14 help-centre articles (link), the ticket routing rules (configured in the support tool, Settings → Routing) and this guide. Not included: the Hindi translations agreed for phase 2. Known issue: refund tickets are routed to the general queue; workaround on page 4. Questions until 30 November: Neha, project lead.
Test it before you send it
Ask one person who did not work on the project to complete one everyday task using only the handover. Every question they ask is a gap in the document.
Facts in a handover — dates, versions, owners, limits — should be confirmed by the person responsible for them. A clean, well-structured handover that is factually wrong does more damage than a messy correct one.
Examples in this guide are fictional and written for teaching — not client material or measured results.
