A description is what someone remembers. A record is what happened. Document from the record, then let the description correct it — never the other way round.

Ask a capable person to describe a process they run daily and you will get a clean, ordered account of the happy path. This is not evasion; it is how memory works. The exceptions are handled so automatically that they do not surface as steps, the waiting is invisible because nobody experiences waiting as work, and the order gets tidied into the sequence that makes sense in hindsight rather than the one that actually occurs.

The result is a document that is wrong on the day it is finished — not because anyone was careless, but because the method guaranteed it. Everything below is designed around that one problem. If you want the underlying argument for why the four independent accounts of a business disagree, that is the four sources of truth; this page is the practical procedure.

01 · Pick the boundaries before the steps

Name two things before you write a single step: the trigger that starts the process, and the condition that ends it. "Onboarding" is not a process — it is a topic. "From offer accepted to first productive day completed" is a process.

Get this wrong and everything downstream is contested. Most arguments about process documentation that look like disagreements about a step are actually disagreements about where the process begins and ends, held by two people who never noticed they disagreed.

02 · Pull the last five real instances

Before interviewing anyone, go to whatever system records the work — the scheduler, the ticket queue, the shared inbox, the ledger — and find five completed runs. Include at least one that went badly. If you can only find three, that is itself a finding: the process is rarer than people think, or it is not recorded anywhere, and the second is the more serious discovery.

Read across all five and write the first draft from what they show. The draft will be ugly and full of gaps. That is correct — a draft is not a document, it is bait.

03 · Write each step as an owner, a trigger, and a done condition

Three fields, every step, no exceptions:

Owner — a role, never a name. Names go stale; roles survive turnover.
Trigger — what makes this step start. Usually the previous step's done condition; when it isn't, you have found a handoff worth examining.
Done condition — how anyone can tell it is finished, observably, without asking the owner.

The done condition is the field people skip and the one that carries the weight. A step without one is exactly where work silently stalls: nobody is blocked, nobody is late, because nobody can say what "late" would even mean. Write "the record shows an approval decision" rather than "reviewed."

04 · Write the exceptions as first-class steps

Exceptions are not edge cases; in many operations they are a large share of the volume. Documents that push them into a closing paragraph titled "Exceptions" are documents that stop being useful precisely when someone actually needs them — nobody consults a runbook on a normal day.

Each exception gets a named condition and a route: if the credit check has not cleared by day three, the operations lead decides whether to proceed or hold. Condition, owner, outcomes. If you cannot name the condition, you have found undocumented judgment, which is worth knowing about before you try to automate anything — determinism is one of the four properties that decides whether a process is a viable candidate at all.

05 · Have the person who does the work correct it

Now bring in the operator — not to describe the process, but to correct your wrong draft. This inversion is the whole method. Asking "how does this work?" gets you a summary. Handing over a document that is visibly wrong in three places gets you: no, that only happens if it's a rush order, and you've missed the bit where we check the second system, and that step hasn't existed since we changed vendors.

People recognise what is missing far more reliably than they recall it. A wrong draft is a better instrument than a blank page, and it takes their time in minutes rather than hours.

06 · Run the handover test

The only test that means anything: give the document to someone who has never run the process, ask them to run it, and stay in the room without answering questions.

Every question they need to ask is a defect, and it comes with its own address — you know exactly which step failed. Write the question down, let them ask it, fix the step afterwards. A handful of questions on a substantial process is a good document. A long list means you documented a description after all.

The same test, applied to a whole operation passing to a new team, is the live run in handover to operations.

The bar A competent person who has never done this work should be able to complete it correctly using only the document. Not "understand it." Complete it. That is the difference between documentation that gets followed and documentation that gets filed.

SOP, process, work instruction: which do you need?

A process describes how work moves from start to finish across people and systems: who owns each step, what starts it, and what done looks like. A standard operating procedure (SOP) is the written, maintained instruction for running one of those processes the same way every time; what the six steps above produce is an SOP. A work instruction goes one level lower: the exact steps for a single task, often with screens or photos. A policy is the rule the others must follow: what must happen, not how.

Most operations need processes and SOPs first. Write work instructions only where a task is technical or error-prone enough that the clicks themselves matter, and expect them to need the most upkeep, because they are tied to the tool. A process map, boxes and arrows, is useful for seeing handoffs and loops, and a swimlane map shows owners and exception paths too, but neither shows the done condition for each step. Map first if the flow is unclear; then write it as above.

What to do with it afterwards

A document is only true on the day it is finished unless something keeps it current. The structural reasons procedures decay — and the sampling test for how far yours already have — are in why your SOPs are out of date before anyone reads them. The short version: name an owner per document rather than per folder, trigger review on a change event rather than a calendar date, and make sure something actually notices the change.

A process documented this way is also the kind that is safe to automate. You cannot govern what you have not described, and an agent handed a happy-path document will handle the happy path and improvise the rest — which is the failure mode governing AI agents exists to prevent.

← All writing