The expert says the task is straightforward. The colleague covering it has three questions before finishing the first step. Both can be right: experience hides decisions that a written process needs to make visible.
Instead of beginning with a blank document, take one real task and follow it from trigger to handover. Ask what starts the work, what counts as complete and what happens when the information is not there. Those three answers create the spine of a useful process.
Define a finish someone can recognise
“Manage enquiries” is too broad. “Create a checked handover with the requested work, open questions and named owner” gives the next person something to inspect. Decide where that handover belongs and who accepts it.
Use a harmless example when drafting documentation. Do not copy a customer’s personal details into a training page simply because the original record is convenient.
Write the decisions beside the steps
Here is a fictional enquiry-handover sequence:
- Confirm that the enquiry belongs to the correct team.
- Copy the requested outcome from the approved record; do not add a promise.
- Mark missing dates or requirements as unresolved.
- Assign the person who will clarify each open question.
- Send the checked handover through the agreed internal channel.
The useful detail is what to do when the record is incomplete. “Complete the form” would conceal that decision and encourage guessing.
Add one finished example
A short example could read: “Requested: a discussion about automating weekly reporting. Timing: not confirmed. Open question: which source files are approved for use? Next owner: operations lead. Next action: clarify the inputs before proposing a pilot.” This is invented for illustration.
Place the example beside the checklist. A reader should not have to search another folder to discover the intended level of detail. Keep access credentials out of the document and link to the approved access process instead.
Test with the person who normally asks questions
Ask a colleague unfamiliar with the task to follow the draft using a suitable test record. Observe where they hesitate. If they need to call the original expert, capture the missing decision rather than expanding every section equally.
Finish by asking the recipient whether the output is usable. A checklist can be easy to follow and still produce a poor handover.
Give the process an owner and an expiry trigger
Record the maintainer and review it when the underlying tool, responsibility or input changes. Keep one current version in the place the team uses. Archive superseded copies so a search does not return several equally plausible instructions.
Common questions
How do I write a handover process a colleague can follow without calling me?
Take one real task and follow it from trigger to handover, asking what starts the work, what counts as complete and what happens when the information is not there. Write the decisions beside the steps and place one finished example next to the checklist.
How can I test whether my process document works?
Ask a colleague unfamiliar with the task to follow it with a suitable test record and watch where they hesitate. If they need to call the original expert, capture the missing decision, then ask the recipient whether the output is usable.
How do I keep process documentation up to date?
Record who maintains it and review it when the underlying tool, responsibility or input changes. Keep one current version where the team works and archive superseded copies so a search does not return several equally plausible instructions.
Editorial notes
Reviewed on 20 September 2026. This is an original operations method with fictional examples, not a report of a client implementation. For a related experiment, read how to choose a first AI workflow.
Something changed or worth adding?
Send a correction or suggestion
