Handover Document: A Template the Next Person Can Actually Use
Create a handover document with clear next actions, owners, deadlines, access, and escalation rules. Includes a free editable checklist and worked example.
A useful handover document tells the next person what needs attention, what to do next, where the reliable information lives, and who can make a decision. It also states what is finished, what is waiting, and what must not happen yet. A folder of links is supporting material, not a complete handover.
Use the template below when you leave a role, rotate off a project, or arrange temporary coverage. The test is practical: can the recipient take the next safe action without reconstructing your inbox?
Table of contents
- What belongs in a handover document?
- How do you fill in the template?
- How much detail is enough?
- How do you test the handover?
- What if nobody has accepted ownership?
- Frequently asked questions
What belongs in a handover document?
Include the handover period, named owners, active work, next actions, deadlines, access requirements, and escalation rules. Separate information that requires action from background that only needs to be understood.
Download the editable handover checklist. It opens as a plain text file you can copy into your team's document system without an account.
Use these prompts for each active item:
| Field | Question the recipient needs answered |
|---|---|
| Outcome | What are we trying to deliver or maintain? |
| Current state | What is complete, waiting, blocked, or unstarted? |
| Next action | What exactly should happen next? |
| Owner | Who has accepted responsibility for that action? |
| Due date | When does action become necessary, including time zone? |
| Source | Which document or system contains the current version? |
| Decision boundary | What can the recipient decide, and what needs approval? |
| Escalation | Whom should they contact, and under what condition? |
This is an original general-purpose template. Adapt it to the work rather than filling every box with long paragraphs. GitLab's customer success coverage guidance offers a real organizational example: it distinguishes active priorities, actions during coverage, standing context, and escalation paths.
That separation prevents a common failure. The receiver sees an unfinished item, assumes it is urgent, and changes something that was intentionally waiting for a customer or decision maker.
How do you fill in the template?
Write from the receiver's next working session. Give them the first action they can take, not a chronology of everything you did.
Here is a completed fictional handover item:
Work: October customer onboarding guide.
State: Draft reviewed by support; two product screenshots still need confirmation.
Next action: Ask the product owner to confirm that the screenshots match the current release. Then send the guide to the editor.
Owner: Alex has agreed to coordinate the review while Morgan is away.
Due: October 22, 3 p.m. Eastern Time, for the editorial handoff.
Source: The team's shared onboarding folder; use the document named “October onboarding guide — review version.”
Boundary: Alex may correct wording. Product claims need the product owner's approval.
Escalation: If approval has not arrived by October 21 at noon, contact the team lead to decide whether to postpone publication.
This example names a decision boundary and a trigger. “Finish the guide” would leave both hidden. In your real document, replace the described folder with a verified link and test the receiver's access.
A handover can also state that nothing should move. “Customer has asked us to wait until their review on October 28” is useful information. Without it, a diligent replacement may send an unnecessary chase email.
GitLab's engineering handbook uses coverage issues to define responsibilities and give designated people the context to make decisions during an absence. Your version can be simpler while preserving that purpose.
How much detail is enough?
Include the detail that changes a decision or prevents a likely mistake. Link to stable instructions instead of copying an entire manual into the handover.
A good document has three reading levels:
- Start here: The immediate priorities and anything time-sensitive.
- Active items: Status, next action, owner, due date, and decision boundary.
- Supporting resources: Procedures, contacts, previous decisions, and relevant files.
This three-level structure is our suggested layout, not a formal standard. It lets a busy receiver act quickly while still having access to the background.
Keep a standard operating procedure separate when it explains a recurring process. The handover says which instance is active and what is unusual about it. The procedure explains how the task normally works.
Remove outdated copies, conflicting instructions, and links that only work from your personal account. If two systems disagree, name the source that currently governs the work and record the discrepancy for resolution.
Do not paste passwords, recovery codes, or personal customer details into a broadly shared document. Request access through the organization's normal process. The handover should say which access is needed and who can grant it.
For project completion, Atlassian's project closure guidance includes handoff, documentation, and acceptance among the closing checks. “The file was sent” and “the receiving team accepted the work” are different milestones.
How do you test the handover?
Ask the recipient to find the next task, open its source, and explain what they would do if it became blocked. Watch where they need information that exists only in your memory.
Try this short read-through before the last day:
- “Which item needs attention first?”
- “Can you open the current document with your own account?”
- “Which change can you approve yourself?”
- “What would make you contact the manager?”
- “Which item should remain untouched for now?”
This is a usability check, not an exam for your colleague. If they cannot answer, improve the document rather than explaining everything verbally and leaving the gap in place.
Suppose they find the draft but cannot open the approval history. Fix that access before calling the handover complete. If they think the publication deadline is flexible but it is not, state the constraint and the person who can change it.
After the conversation, record the document version, review date, and unresolved issues. Ask the receiver to acknowledge the responsibilities they have accepted. Do not describe this acknowledgment as legal sign-off unless your organization actually uses such a process.
For temporary leave, pair the internal document with an out-of-office message that routes incoming requests to the agreed contact. The public-facing reply should not expose the internal task list.
What if nobody has accepted ownership?
Make the gap visible to the manager or project lead. A handover cannot assign someone responsibility merely by placing their name in a table.
Use a direct message:
The reporting task needs coverage from October 21. The current state and next action are documented, but no owner has accepted it yet. Please confirm who should take it, whether the deadline should move, or whether it should pause. The main risk is missing the customer review on October 24.
Keep the task marked “unassigned” until that changes. Do not label the whole document complete while a critical decision is unresolved.
If you are leaving permanently, finish the formal departure communication separately; a two-weeks notice letter serves a different purpose. Agree on priorities for the remaining time rather than promising to complete every loose end.
Do Only 3 Things a Day helps with that prioritization problem: choosing the few outcomes that deserve attention and protecting space to finish them. A better handover reduces uncertainty; it does not create unlimited capacity for the person receiving it.
Frequently asked questions
Is a handover the same as an SOP?
No. An SOP explains how a recurring process normally works. A handover explains the current situation, outstanding work, and who takes responsibility now. Link the procedure where it helps the recipient act.
How long should it be?
Long enough to support the decisions the recipient must make. Start with a concise action summary, then link to details. A short document with missing ownership is worse than a longer document that is easy to navigate.
Should passwords go in it?
No. Use the approved access or credential-sharing process. Name the system, required permission, and person responsible for granting access. Verify that the recipient can use their own account before the transition.
What if the replacement starts after I leave?
Agree on an interim owner and store the document somewhere the team controls. Record unresolved decisions and the current version. Your manager should decide how the work is covered during the gap; do not assume the future replacement can act before starting.