Handover document template: give the next owner enough to continue
Dylan de Heer
A handover document should tell the next owner where the work stands, what needs attention next, where the authoritative information lives and who can resolve a problem. It is ready when the recipient can use it to take the next agreed step, not simply when every heading contains text.
This template is for handing over an office project or ongoing workstream: a product launch, a client engagement, an internal rollout or similar knowledge work. It includes a copyable structure, an example and a practical acceptance check. Construction completion packs and clinical shift handovers have different requirements and need their own specialist processes.
Start with the recipient's first decision
Imagine the new owner opens your handover tomorrow morning. What must they decide or do first? Put that near the top, before the project history.
“The rollout is progressing” leaves them guessing. “The next decision is whether the pilot can expand; the support review is still outstanding, and the project sponsor owns that decision” gives them something to act on.
Write a short orientation for the recipient, then link to the records that carry the detail. This keeps the document readable without creating a second, quickly outdated copy of every plan, task and discussion.
Copy this handover document template
1. Handover details
Project or workstream: [Name]
Outgoing owner: [Name and role]
Incoming owner: [Name and role]
Transfer date: [Agreed date and time zone where relevant]
Scope: [Responsibilities being transferred]
Excluded responsibilities: [What stays with someone else]
Status last checked: [Date and person]
2. Read this first
Current position: [Two or three sentences on the actual state]
Next required action or decision: [What needs to happen next]
Why it matters now: [Dependency, deadline or risk]
Decision owner: [Who can approve or resolve it]
First source to open: [Link to the current authoritative record]
3. Work in progress
For each active item, record its current status, next action, responsible person, due date and source link. Mark a date as tentative if it has not been agreed. Include blocked work and describe what will unblock it.
4. Decisions and constraints
List the few decisions the new owner needs to understand immediately. Include the reason, date and link to the full record. Separate settled decisions, proposals awaiting approval and assumptions that still need checking.
5. Risks and open questions
For each material issue, explain what could happen, the warning sign to watch, who can help and the next review point. An unanswered question belongs here even if the document would look neater without it.
6. People and working rhythm
Identify the sponsor, delivery contacts, approvers and relevant specialists. Explain who decides what. Link to recurring meeting details and record the next scheduled review, rather than relying on the recipient to infer the routine from your calendar.
7. Files, systems and access
Link to the current plan, task board, approved documents and relevant source notes. State which system is authoritative for each. Record access requested, granted and tested as separate states. Link to the approved access process; do not put passwords or recovery codes in the handover.
8. Acceptance and remaining gaps
Recipient walkthrough completed: [Date or outstanding]
First task tested: [What the incoming owner tried]
Links and permissions checked: [Results and unresolved issues]
Outstanding gaps: [Each gap, owner and agreed next step]
Responsibility accepted: [By whom, when and for which scope]
Follow-up review: [Agreed date]
Example: handing over an internal rollout
The following example is fictional and deliberately includes an unresolved issue.
A product lead is transferring an internal onboarding rollout to a colleague. The pilot has started, but wider access has not been approved. The incoming owner needs to prepare the next review, not announce an expansion.
The opening section could read:
The onboarding pilot is running with the original team. Wider rollout remains pending. Before preparing the expansion review, confirm the support team's assessment and update the open-issues list. The sponsor owns the expansion decision. Start with the current pilot board; the earlier launch plan is retained for background only.
The active-work section then identifies the support review, the pilot feedback summary and the pending approval. If nobody has accepted responsibility for collecting the feedback, the handover says “owner to confirm”. It does not assign the incoming owner by implication.
The recipient's first test is practical: open the pilot board, find the unresolved issue, locate the relevant approval discussion and explain what evidence the sponsor still needs. If they cannot do that, improve the handover before treating the transfer as complete.
Recover context from meetings without copying everything
Meeting records are useful when the written plan does not explain why the scope changed or why an option was rejected. Review the relevant conversations, extract the parts that affect the next owner's work and retain a route back to the source.
Weeve Chat lets you ask about your recording library and inspect linked source material. Start from a relevant recording so you can check the context before drawing a conclusion across several conversations.
Native Weeve interface with demonstration content. The selector illustrates choosing the recording context; this is not a recording of the fictional handover.
Try a focused request:
Prepare a handover outline from this recording. Separate confirmed decisions, open questions, dependencies and proposed next steps. Include supporting sources. Keep missing owners and dates marked as unknown, and flag anything that needs confirmation.
Check each useful point against its source. “We could expand next month” must not become an approved launch date. A person's suggestion must not become an action they accepted. Review later records where a decision may have changed, and ask the outgoing owner about gaps that the recordings cannot resolve.
The current task board, approved plan and access system still need separate checks. Chat's library access does not make it an authority on today's task status or permissions, and it does not transfer ownership in external systems. Copy the reviewed outline into your handover and reconcile it with those systems yourself.
Use Local mode when the material needs to stay in Weeve's on-device Chat workflow. Optional ChatGPT use has a different processing boundary. Review the available Chat modes and limitations before working with sensitive context.
Run a handover walkthrough, then ask the recipient to lead
Use the document as the agenda. Explain the immediate next step, demonstrate where the relevant information lives and walk through one likely exception. Then let the incoming owner perform a small representative task using their own access.
Useful tests include finding the latest approved scope, opening the current board, locating a key decision and identifying the escalation contact. Watching the outgoing owner's screen does not prove that the recipient has the right permissions.
Ask the recipient to explain their first priorities back in their own words. Differences reveal where the document needs more context. Record unresolved questions with named owners instead of treating the meeting's end as automatic acceptance.
Confirm the transfer explicitly: which responsibilities move, which remain elsewhere and when the new arrangement takes effect. Follow with a short meeting follow-up containing the agreed actions and remaining gaps.
Keep the handover useful after the transfer
Set a review point after the incoming owner has attempted the first meaningful step. Check which information was missing, which links failed and whether any responsibility was ambiguous. Update the shared document and keep a record of the changes that affect ownership or scope.
For temporary cover, include the return date and what must be reported back. For a permanent transfer, agree when the outgoing owner's involvement ends and where future questions should go.
Before accepting the handover, the recipient should be able to name the next action, find its supporting information, use the required systems and identify who can resolve a blocker. Those checks make the document a working aid rather than a record that a transfer meeting happened.
