A recurring task handoff should tell the new owner what starts the work, which inputs to use, how to produce and check the output, and when to ask for help. Document one bounded process, then use its first two cycles to test and refine the instructions.
The handoff card below makes the responsibilities and support route explicit. It helps you transfer a repeating task without expecting another person to reconstruct the unwritten knowledge in your head.
Choose a bounded process to transfer
Name the recurring task and its purpose. Define where it starts and ends. “Manage customer service” is a broad responsibility. Preparing a weekly list of unresolved customer requests is a more specific process you can document and observe.
Identify the expected output and who uses it. Ask the receiving person to confirm what they understand the responsibility to include. Atlassian’s roles-and-responsibilities guidance supports discussing responsibilities explicitly and identifying work that remains unassigned.
Identify the event that begins the process and the point at which responsibility passes to someone else. A task without a clear ending can quietly expand into general responsibility for an entire function. Write down what is included and what remains outside the handoff. The receiving person should be able to tell whether a new request belongs to this process or needs separate agreement.
Ask who uses the output and what they need from it. A document can be complete according to the preparer’s understanding but unsuitable for the person receiving it if its format, timing, or contents are unclear. Confirm those expectations with the receiving part of the workflow. The handoff should connect two stages of work rather than describe only the actions of one person.
Record the trigger and required inputs
Write what starts the task: a scheduled date, an incoming request, or completion of another activity. List the files, information, and approvals needed before work begins. Include where approved materials are kept.
If an input is missing or outdated, state what the owner should do. Don’t make them guess whether to proceed. Record the person who can supply the missing information and whether the task should wait for an answer.
Specify how the owner recognizes that the trigger has occurred. If a request starts the task, identify the required information that makes the request ready to process. If a schedule starts it, state the relevant period and where the current schedule is kept. Avoid relying on the new owner to infer timing from habits that were never documented.
Check the inputs before the first cycle. Confirm that the person can locate the approved materials and understands which version to use. If something is absent, record the question and its owner. Don’t begin by teaching a workaround that depends on undocumented memory unless that workaround has been deliberately agreed and added to the instructions.
Explain steps around observable results
Write the process in the order it is performed. Describe each meaningful action and the result that tells the owner it is complete. Use the language people see in the actual tools and documents.
Keep the instructions specific enough to follow without filling the card with every possible detail. Link to approved supporting instructions when necessary. Don’t place passwords or private account credentials in a shared handoff document.
Write one meaningful action at a time and include the result it should produce. Avoid instructions like “handle the usual checks” or “send it as normal,” which assume knowledge the new owner may not have. Use a real approved sample where available, with appropriate information removed, to clarify the expected output rather than adding pages of vague explanation.
Test the wording by asking the receiving person what they would do after each stage. Where they hesitate, find out whether the problem is missing information, unfamiliar terminology, or a genuine decision point. Revise the instruction to address that cause. More detail is useful only when it resolves a specific ambiguity in carrying out the task.
Define quality checks and exceptions
State what the person should verify before passing on the output. The check might concern completeness, matching a source, the required file format, or approval by a named person. Choose checks that reflect the actual task.
List the exceptions that require escalation. Include a contact and the information they need to resolve the issue. Make clear which decisions remain with the owner or another reviewer, so handing off execution doesn’t silently transfer approval authority.
Choose checks that the owner can actually perform with the information available. State the source used for comparison and what happens when the output fails the check. A quality instruction should lead to an observable decision, including returning a request for missing information or sending a completed item for approval. “Make sure it is good” leaves the standard undefined.
Describe escalation in operational terms. Identify the condition, the person to contact, and the information that person needs. Also state what happens to the task while the answer is pending. This prevents the owner from having to guess whether they should continue, pause, or change the process when a situation falls outside the agreed instructions.
Fill in a practical handoff card
Use one card for one recurring process. Add the current version date so someone using an old copy can recognize it.
| Handoff field | Agreed instruction |
|---|---|
| Task and purpose | ______ |
| Primary owner and backup | ______ |
| Trigger and expected completion time | ______ |
| Required inputs and their locations | ______ |
| Steps and expected output | ______ |
| Quality checks and approval | ______ |
| Exceptions and escalation contact | ______ |
| Version date and review date | ______ |
Ask the new owner to read the card and describe the process back to you. Treat questions as evidence that an instruction needs clarification. Confirm the boundaries of the task before the first live cycle.
Keep the card as the entry point to the process. Put detailed supporting instructions where they can be maintained and refer to them explicitly from the card. Avoid copying the same instruction into several places unless there is a reliable way to keep the versions aligned. The owner should know which document governs the task when an old copy resurfaces.
Name the person responsible for maintaining the card. Record a review date and the changes that should trigger an earlier review, including a new input, a changed approval route, or a different output requirement. A handoff is not complete merely because the first version was written. The instructions need an owner after the original task owner steps back.
Use the first two cycles to check the instructions
During the first cycle, have the owner perform the task with support available. Record where they needed an answer, which information was missing, and whether the result met the agreed checks. Update the card after reviewing those observations together.
During the second cycle, let the owner work from the revised instructions and use the agreed escalation route. Review the output and remaining questions. Two cycles are a suggested starting check, not proof that every exception has been covered. Schedule further review when the process or tools change.
For the first cycle, observe where the owner has to stop and ask for information. Resist answering from memory without adding the missing instruction afterward. The question is evidence about the document as well as the person’s understanding. Review the resulting output together against the agreed checks and distinguish an instruction gap from an execution mistake.
For the second cycle, use the revised card and note whether the same questions recur. If a new exception appears, decide whether it belongs in the standard instructions or the escalation guidance. Continue support where needed rather than declaring independence after an arbitrary number of attempts. The first two cycles provide a structured starting review, not a guarantee that every future situation has been covered.
What should a handoff card explain?
- The task, owner, and trigger.
- Inputs, steps, and expected output.
- Quality checks and approval boundaries.
- Exceptions, support contact, and review date.
Transfer the process and keep the support route
Confirm that the owner can find the instructions, produce the output, and recognize when to ask for help. Keep the card current and name who maintains it. The handoff is practical when the person can perform the recurring task within agreed limits without depending on unwritten instructions.
