Handover Document

A sales manager leaves while several client renewals are in progress, and the successor needs more than a list of customer names: the status of each renewal, next action, contact and deadline, with an appropriate link to the actual record. A handover document organises that information so work does not depend on memory, and it can be used during leave, an internal move, a supplier transition or the transfer of a project into operations.

The Association for Project Management emphasises defining the handover, clearly communicating dates, priorities and responsibilities, and transferring knowledge to users; a project handover is not the same as employee offboarding, but those lessons apply to both. Begin early enough to test the contents, because a document prepared in the final hour may miss an unresolved issue or assume the recipient knows a system.

Ask the receiving person what would let them act independently. Name the owner of each task, not simply a department, and state whether the departing person is still doing it, the recipient has accepted it or a manager must assign it.

Record the current status and next step for live items, for example: invoice disputed; finance reviewing supporting timesheets; reply to client by Thursday. List recurring cycles as well as one-off tasks, since a month-end close may require several steps in order, with cutoffs and reviewers, and the successor should know where the procedure and last approved example can be found.

Link to authoritative systems rather than copying sensitive data into an uncontrolled file, referring to the CRM record, secure drive folder or approved ticket, subject to permissions, and do not paste passwords, private keys or customer personal data into the handover. Access is its own workstream: a manager or IT team should arrange role-based permissions and remove access that the departing person no longer needs.

Include key contacts and explain their role, since a supplier name without context may not tell the successor who handles emergency orders or contract changes. Known risks deserve their own section covering what may fail, what warning signs matter and who can help, and a project moving into operations may need monitoring thresholds, warranty contacts and unresolved defects, not just a launch date.

Decisions and assumptions should be traceable, so if management has not approved a price change, mark it pending. A handover meeting gives the recipient a chance to question unclear items, so demonstrate an important process where possible, then let the recipient try it.

Make a short priority view for the first week, because a long inventory can hide a payment deadline or regulator filing, and mark what must happen today, this week and later, with an escalation route for surprises. A checklist can track coverage: if 27 of 30 items are documented, coverage is 90%, which says nothing about whether the missing three are the most important or whether the instructions are accurate.

Keep a version date and a named owner for updates, validate the document against systems and assign open responsibilities before the leaver loses access where overlap is short, and close the handover deliberately by confirming which open items were accepted, which remain unassigned and which need separate approval.