How to Document a Business Process So Someone Else Can Run It

Short answer: Write process documentation for someone competent but uninformed — state the trigger, the required inputs, each step as an instruction, the decision rules, the definition of done, and what to do when things go wrong. Test it by having someone who has never done the task follow it without asking questions.

Almost every business has some documentation. Almost none of it works, because it was written by the person who does the task, for an imagined reader who already understands the task.

What makes documentation actually usable?

A usable process document answers six questions in order:

1. When does this start? The specific trigger — an email arrives, a deal moves to a stage, the first of the month.
2. What do I need before I begin? Access, information, files, approvals.
3. What exactly do I do? Numbered steps, each an action, each verifiable.
4. How do I decide? The rules behind judgement points, written as conditions rather than instincts.
5. How do I know I'm finished? An observable end state, not a feeling.
6. What if it goes wrong? The three most common exceptions and what to do about each.

The sixth is the one that gets omitted and the one that generates the most interruptions.

How much detail is too much?

The calibration point is the reader: assume general competence, assume zero context about your business. "Send the onboarding pack" is too little. "Click the blue button in the top right" is too much — interfaces change and the document rots. "Send the onboarding pack from the Client Templates folder, addressed to the primary contact listed on the CRM record" is about right.

How do you write down judgement?

This is the genuinely hard part, and it's where most documentation gives up. The technique is to ask the experienced person for recent examples rather than for the rule. "When do you escalate?" gets you "when it feels serious." "Tell me about the last three you escalated" gets you the actual criteria — value over a threshold, a named client, a legal question, a repeat complaint.

Extract the pattern from the cases, write it as conditions, and show it back. You'll usually get one important correction.

Where should documentation live?

Next to the work, and in one place. Process docs scattered across Google Docs, a wiki, and a shared drive are functionally undocumented, because nobody knows which version is current. One knowledge base, one owner per document, one review date on each. Notion, Confluence or a well-structured shared drive all work — consistency matters more than the platform.

How do you test it?

Hand it to someone who has never done the task and watch them attempt it without asking questions. Every question they need to ask is a defect. Fix the defects, repeat once. Two rounds usually gets a document to a workable state.

This test is uncomfortable and it is the only reliable one. Reviewing your own documentation tells you whether it matches your memory, not whether it works.

How do you stop it going stale?

• Assign an owner per document — a name, not a team.
• Set a review cadence, typically six or twelve months.
• Make updating the doc part of changing the process, not a separate task.
• Delete aggressively. A small set of accurate documents beats a large set of plausible ones.

Frequently asked questions

Should I use video instead of written docs?

Video is excellent for demonstrating an interface and poor for reference. Use both: a written procedure with a short screen recording attached to the fiddly steps.

Can AI write my process documentation?

It can draft structure and tidy language from a transcript of you explaining the task, which saves real time. It cannot supply the decision rules — those only exist in your team's heads and have to be extracted.

How many processes should be documented?

Start with the ones that are high-frequency, high-consequence, or currently owned by one person. That's usually five to ten, not fifty.

Every Decode & Grow build ships with the full playbook — documented, trainable, yours. See what's included.