What should a practical work handover checklist include?
Quick answer
A practical handover checklist should show what is in progress, its current status, the next action and due date, who owns that action, where the relevant files or tools are, and any known issues or decisions. Add a contact or escalation route if appropriate, and note anything that should not be assumed. Keep it specific enough for someone unfamiliar with the work to take the next step.
The question, the details, the next step.
I need to hand over a few work tasks before I’m away. What should I include so the person covering me can continue, rather than just read project names?
For each task, capture what helps someone act: What is this? Where does it stand? What happens next? Who is responsible? Where are the materials? What might block progress?
A compact checklist can include:
- Task or project name and a one-sentence purpose.
- Current status, including what is complete and what remains.
- Next action, owner and due or check-in date.
- File, tool or record location, using an approved internal link or path.
- Known issue, dependency, pending decision or important context.
- Relevant contact or escalation route, if there is one.
Avoid vague entries such as “follow up with the team.” Say what needs following up, with whom, and what response or decision is needed.
How much detail should I put in the status? I don’t want to write a long history for every item.
Give enough context for the next decision, not a full chronology. Separate what is complete, in progress and waiting on something. If a past decision affects the next step, include it and point to where its background is recorded. Leave out history that does not change what happens next.
For example, instead of “The launch materials have been discussed for weeks,” write: “Draft copy is complete; review is pending from the product lead. If approved, send the final version to the design owner for layout. Review notes are in [approved folder or record].” These are placeholders: replace them with the actual status and location, and do not imply an approval that has not happened.
Can you show me a reusable entry for one task, including what to write if something is blocked?
Use this format and fill in what applies:
Task: [name and purpose] Status: [complete / in progress / waiting; what is true now] Next action: [specific action] Owner: [person or role responsible] Due or review date: [date, if agreed] Materials: [approved file, tool or record location] Dependency or issue: [what is needed; who or what it depends on] Decision or context: [relevant choice or note, if needed] If blocked, do this next: [follow-up action or escalation route]
Example using placeholders: Task: Monthly report — assemble figures and prepare a review draft. Status: Figures are gathered; review draft is not yet checked. Next action: Confirm [unverified figure] with [team or role], then update the draft. Owner: [covering person or role]. Due or review date: [agreed date]. Materials: [approved folder or system location]. Dependency or issue: Confirmation of [figure] is pending from [role]. If blocked, do this next: Ask [designated contact or role] how to proceed; do not mark the figure confirmed until it is checked.
This is a format, not a claim about your workplace. Use real names, dates and locations only in your internal handover, following your organization’s practices.
What about access details and things that could go wrong? Should I include passwords or just mention the systems?
List the systems or materials needed and point to the approved way to request access. Do not put passwords, recovery codes or other credentials in the checklist. If access is missing, make it an action: “Request access to [system] through [approved internal process or contact] before [task].”
For known issues, describe the practical effect and next step without guessing at a cause. For example: “The latest file is missing [item]; check with [owner] before sending the draft.” If you are unsure whether a note is current, label it unconfirmed and say who can verify it. Distinguish checked facts from assumptions or open questions.
How do I make sure I haven’t left out something important when I’m doing several tasks at once?
Review each entry from the covering person’s point of view: can they identify the next action, find the materials, tell who owns the work, and recognize what is blocked or uncertain? Check that dates are explicit, links or paths lead to the intended materials, and open decisions have a follow-up route. If you have time, ask the covering person to read one entry and say what they would do next; revise anything that leaves them guessing.
A practical checklist
Name each task and state its purpose in one sentence.
Record the current status and distinguish completed work from pending work.
Write a specific next action, owner and agreed due or review date.
Point to relevant materials using approved internal locations.
Note dependencies, known issues, pending decisions and what to do if blocked.
Mark uncertain details as unconfirmed and identify who can verify them.
A few more useful answers
Should I include every detail about how the task began?
No. Include background only when it changes the next action, explains a constraint or helps with a decision. Point to a fuller record if more history is needed.
What if nobody has agreed to own the next step?
Label the owner as unassigned rather than implying someone accepted it. Add who needs to assign an owner and when that decision should be revisited, if known.
How should I handle a task that may not need action while I’m away?
State the condition that would trigger action and who should check it. If there is no agreed trigger or owner, flag that as an open decision instead of guessing.