How to document a business process in one sitting

Process documentation stalls because people treat it as a project. It doesn't need to be. One process, one sitting, forty-five minutes.

Here's the method.

Minutes 0–5: Define the boundaries

Write three lines before anything else:

• Trigger: what starts this process
• Done: what exists when it's finished, and how you know it's correct
• Owner: which role is accountable

Most documentation confusion comes from skipping this. Without agreed boundaries, two people document overlapping halves of different processes.

Minutes 5–20: Record, don't write

Do the process while narrating. Screen-record if it's on a computer, voice-record if it isn't.

Narrate the decisions, not just the actions. "I'm checking whether they're an existing client, because that changes which template I use" is the sentence that makes the document valuable. Clicks are easy to infer; judgment isn't.

If the process takes longer than twenty minutes to perform, document it in two parts.

Minutes 20–35: Edit into steps

Transcribe the recording — automatic transcription is fine — and cut it down to numbered steps, each starting with a verb.

Strip everything that isn't instruction. A 2,000-word transcript usually becomes twelve steps.

Then add two sections:

• Exceptions: the three or four situations that actually recur, and what to do in each
• Decision rules: thresholds, approvals, when to escalate

Minutes 35–45: Test with someone else

Hand it to a person who doesn't do this task. Watch them follow it. Say nothing.

Every hesitation is a defect. Note them, fix them, and you're finished.

This step is the one people skip and it's the one that determines whether the document gets used. Twenty minutes of watching produces a better result than two hours of careful writing.

Keep the format identical every time

Purpose. Trigger. Owner. Steps. Exceptions. Done means. Last reviewed.

Same shape, every process. Consistency is what makes a set of documents feel like a system rather than a folder.

What to avoid

Over-detailing. Write for a competent colleague, not a stranger who has never used a computer. Excessive detail ages faster and gets skimmed.

Screenshots everywhere. Use them only where words would be genuinely ambiguous. Every screenshot is future maintenance.

Documenting the ideal. Write what happens, including the workaround everyone uses. If the real process is wrong, fix the process first, then document the fixed version.

Waiting for the process to settle. It never will. Document the current version with a date on it.

Then do the next one

One process per sitting, two a week. Within a month you'll have the eight processes that matter most — which is more than most businesses of any size ever manage.