How to document a process someone else can run

Write process documentation that a new person can follow unaided by capturing decision points and exceptions rather than a tidy list of happy-path steps.

One person knows how and that is the whole risk

Month end closing happens because one person knows the sequence. Dispatch works because somebody remembers which courier refuses which pin codes. When that person takes leave the work either waits or gets done badly and everybody has agreed for two years that it should be written down.

The reason it is not written down is that documentation is usually attempted as a writing exercise after the fact. Somebody sits with a blank page and produces eleven numbered steps that are accurate and unusable because the steps were never the difficult part. The decisions between them were.

What it costs and what a document cannot do

A document does not train anybody. It shortens training and removes the need to ask the same question twice and it does not substitute for somebody watching the work once. Treat it as a reference for a competent beginner rather than as a replacement for handover.

The cost is the expert's time and that is the most expensive and most contested hour in the business. Expect a few hours spread across two or three real runs of the process rather than a single long session. Where you pay an outsider to write it the fee attracts GST at 18% as a service and you still spend the expert's hours because only they know the exceptions.

There is a maintenance cost as well. A document that drifts out of date is worse than none because somebody will follow it confidently. Budget a review whenever the process changes and name who performs it.

What is not worth documenting

Do not document a process that changes every few weeks. You will maintain the document more often than you use it and eventually abandon both. Wait for stability. Teams often document the newest process because it is unfamiliar and that is the one most likely to be rewritten.

Do not document a task performed once a year by the owner of the business. Annual tasks are relearned from scratch anyway and a year-old document rarely survives a changed interface. A short note of where things are kept and who to contact serves better than a procedure.

And do not document what you intend to automate within the quarter. Write a brief for the automation instead. Businesses produce careful documentation for data entry that disappears two months later and the hours are gone. Documentation earns its cost when the process is stable and frequent and performed by more than one person over time.

How to write one that works

Write it during the work rather than after it. Have the person who does the task perform it normally while narrating and capture that. Screen recordings and photographs of physical steps carry more than prose and cost no extra time. The transcript becomes the draft.

Then structure it around decisions rather than actions. Each step that involves a choice needs the condition written out plainly. What you check and what each answer means and what you do in each case. Then list the exceptions you know about with the response to each. The exceptions are the valuable half of the document and they are the half always omitted because the expert handles them without conscious thought.

Finish with the practical scaffolding. Name the owner and the date reviewed at the top. State what finished looks like so the reader knows when to stop. Record where the inputs come from and who to escalate to. Then store it beside the work rather than in a folder nobody opens because a document that is not where the task happens will not be read.

How to know it is good enough

Length and completeness are the flattering measures. A forty page procedure that nobody can execute is a worse document than two pages with the exceptions in them. So is the fact that the expert approved it because they read it with everything they know already loaded.

The only real test is to have somebody who has never done the task run it from the document alone while the expert stays silent and counts interruptions. Every question is a gap and the questions arrive in priority order for free. Two or three questions is a usable document. Eleven means you wrote a summary. Run it again after the next revision because the second count tells you whether the fixes landed.

The common mistake

The expensive error is documenting only the path where nothing goes wrong. The result reads cleanly and it fails on first use because real work is mostly exceptions. The courier that rejects an address and the payment that arrives short and the customer who asks for a changed invoice are the moments where a new person stops and asks for help. A document covering none of them has not reduced the dependency on the expert and the business now believes the risk is handled.

The second error is writing from memory in one sitting without performing the task. Memory skips everything automatic including the login that needs a second factor and the field that must be set before another becomes available. The document then reads as authoritative and sends the reader down a path that does not work. Nothing makes a team distrust documentation faster.

This guide explains how something works. It is not legal, tax or financial advice, and rules change. Confirm anything regulatory with a qualified professional before you act on it.