Handover document template: a structure you can copy
Copy a practical handover document template with a filled consulting example, clear next actions, ownership, access notes and manager review.
A useful handover document gives the next person a place to start. They should be able to open it, see what needs attention, and find the current material without searching through your entire work history.
The template below is designed for client-facing work. Copy it into your team's approved document tool, replace the prompts, and remove sections that genuinely do not apply. A filled consulting example follows so you can see the level of detail to aim for.
The Association for Project Management recommends documents that are useful to the receiving users and dry runs that test the transition. This template applies those principles to a change of role or project owner. It is a suggested working format, not a prescribed standard. APM project handover research
Copy this handover document template
1. Purpose and ownership
Role or workstream: [Name]
Responsibility transfers on: [Date, time and time zone if relevant]
Outgoing owner: [Name and role]
Successor or interim owner: [Name and role]
Reviewing manager: [Name]
Last updated: [Date]
What this handover covers: [Two or three sentences defining responsibilities]
What stays with someone else: [Excluded responsibility and its owner]
2. Start here
First task: [What the successor needs to do first]
Next external commitment: [Deliverable or meeting, date, recipient]
Most important unresolved question: [Question and person responsible for answering it]
Read these first: [Two or three approved links, each with a short explanation]
3. Current work
Repeat this block for each live item:
Item: [Deliverable or responsibility]
Status checked on: [Date]
Current position: [Draft, awaiting review, approved, blocked or complete; add explanation]
Current source: [Link to the authoritative file or record]
Next action: [Specific action]
Owner and due date: [Name; date]
Dependency or escalation: [What could prevent progress; who can resolve it]
4. Decisions and contacts
Decision affecting the next step: [What was agreed, by whom and where it is recorded]
Reason that still matters: [Relevant constraint or assumption]
Key contact: [Name, work role, topic they own, approved contact route]
Introduction still needed: [Who will introduce whom, and when]
For longer explanations, link to a separate project decision record rather than expanding this section indefinitely.
5. Access and open questions
Resource needed: [System, folder or document]
Access checked by successor: [Yes/no; date]
Permission request owner: [Authorized person or service team]
Handling restriction: [Relevant client or company instruction]
Open question: [What remains uncertain]
Resolution owner and date: [Name; date]
Use an approved access process. Do not put passwords, recovery codes or access tokens in this document.
6. Review and acceptance
Manager review: [Date; corrections made; outstanding issues]
Successor walkthrough: [Task attempted; result; missing information]
Remaining gaps: [Each gap, owner and next review date]
Document owner after transfer: [Name]
Next update: [Date or event that triggers a review]
A filled example for a consulting project
The names, company and events below are fictional. The bracketed file descriptions represent links that a real team would replace with approved destinations.
Purpose and ownership
Workstream: Weekly delivery reporting for fictional client Alder Works.
Transfer: 19 October, before the weekly delivery call.
Outgoing owner: Maya, consultant. Successor: Sam, consultant. Reviewing manager: Leila, engagement manager. Updated: 15 October.
Scope: Prepare the weekly report, collect workstream updates, and maintain the delivery action list. Leila retains approval of scope changes and commercial commitments.
Start here
First task: Ask the operations lead for the missing warehouse update before preparing the next report.
Next commitment: Send Leila the report draft on 20 October for review before the client call on 22 October.
Main unresolved question: Has the warehouse team confirmed its revised milestone? Sam will obtain an answer from the operations lead.
Read first: [Approved reporting brief] explains what the report covers. [Current action list] identifies outstanding commitments. [Latest accepted report] shows the agreed format.
Current work
Item: Revised reporting layout.
Status checked: 15 October. The draft has been sent to the client operations lead. It has not been approved.
Current source: [Reporting layout, review version].
Next action: Sam collects comments before 20 October. Until approval is recorded, prepare the next report in the existing accepted format.
Dependency: If feedback is still missing on 20 October, Sam asks Leila whether to keep the existing format for another cycle. Sam does not assume silence means approval.
Decisions and contacts
Decision: Keep the reporting scope limited to the two agreed workstreams. Leila confirmed the boundary in [scope review record].
Reason: The additional workstream has no agreed reporting owner yet. Any expansion needs a separate scope decision.
Contacts: The client operations lead supplies delivery updates. Leila resolves scope and approval questions. Maya will introduce Sam to the operations lead before the transfer.
Access and open questions
Sam can open the reporting folder using his own account. Access to the client dashboard is pending. The client system administrator owns the request; Leila will follow up before the first report is due.
Client material must remain in the approved project workspace. The handover contains links, not a duplicate export of the dashboard.
Review and acceptance
Leila reviewed the draft on 15 October and corrected the approval status. Sam located the accepted report and identified the missing input during the walkthrough. Dashboard access remains an owned gap. Sam becomes the document owner after transfer and updates it after the first reporting cycle.
Keep the document small enough to use
A handover grows quickly when every file becomes a paragraph. Put the immediate work first and link to reference material only when you can explain its purpose.
“Project folder” is a weak label. “Accepted report used as the format for the next update” tells the reader why to open the link. If a source is obsolete, remove it or label it clearly.
There is no universal page count. A short role may need one page. A complex assignment may need a short main document with supporting sections. Use the job handover checklist to spot omissions without turning the main document into an archive.
Check the document from the reader’s side
Ask the successor to attempt the first task using the document and their own account. Watch where they need a missing explanation, a permission, or an introduction. Assign each gap to someone who can resolve it.
If no successor has been named, write for an interim owner. That person needs to know which commitments cannot wait and which work can pause. Update the ownership section when the permanent successor is confirmed.
Keep the reviewed document in one agreed location. After the transfer, update changed responsibilities and unresolved items there. A handover remains useful when the person doing the work can trust which version is current.