The Complete Guide to Documenting How Your Business Works

Most documentation efforts fail for reasons that have nothing to do with the writing. The document was the wrong format for its reader, or it was filed somewhere nobody looks, or it went stale and quietly stopped being trusted.

This guide is the system around the documents — how to choose the form, where it lives, how it stays true, and what to do about the decisions that are the real bottleneck.

The individual document is covered separately in how to write an SOP people actually follow. Everything here sits above that.

The order

| Step | Fixes | |---|---| | 1. Choose the format | Documents nobody reads because they were written wrong | | 2. Make it findable | Documents nobody encounters at the moment of need | | 3. Keep it true | Documents that quietly stop being trusted | | 4. Standardise deliberately | Two people, two versions, no agreed answer | | 5. Systemise decisions | The bottleneck that documentation alone doesn't touch |

Steps one and two account for most failed documentation projects, which is why they come before any writing.

Step 1 — Format before content

Two questions decide it: does the order matter, and does the person need to make judgement calls?

• Checklist — for people who already know. Prevents omission, doesn't teach. Short lines, no explanation. The moment it starts explaining, it stops being used as a checklist.
• SOP — for people who need teaching. Trigger, exact names, verifiable outcomes, exception handling.
• Playbook — for situations that vary. Principle, options, escalation. Steps would be wrong half the time.
• Policy — for boundaries rather than sequences. A threshold and a rule, not a procedure.

If your SOPs are only read by people who already know the job, you wrote the wrong document. Extract a checklist and let the SOP be the training material it should have been.

A useful signal: if you find yourself writing "it depends" more than twice, stop and switch to a playbook.

Full comparison: checklists, SOPs, playbooks and policies.

Step 2 — Findable beats well-organised

The highest-value move in this guide, and it beats any folder structure: link the documentation from the point of use.

In the project template, on the task, in the CRM stage, pinned in the channel, in the recurring calendar invite. Someone about to do a task should encounter the document without having to remember it exists.

Beyond that:

• Organise by work, not org chart. Departments change; the work is more stable.
• Two levels of hierarchy, maximum. Depth is usually a substitute for good titles.
• Titles in the words people would search — "Onboard a new client", not "Client Onboarding Documentation v2".
• One home per document. A duplicate drifts, someone follows the stale copy, and after that nobody trusts any of it.

Full structure: where your documentation should live.

Step 3 — Maintenance beats coverage

Documentation rots faster than code because nothing breaks visibly when it's wrong. Somebody just follows it and gets a worse result.

The asymmetry that matters: a missing document is honest, a stale one lies. Fifteen documents you trust beat sixty you don't.

Three mechanics do nearly all the work:

The person who runs it, edits it — immediately, without approval. Requiring sign-off to fix a step guarantees staleness, because the discrepancy is noticed at the exact moment someone is busy.

Review on a cadence tied to change rate, not one annual sweep. Quarterly for anything built on a third-party tool or touching regulation; annually for stable internal process.

Delete more than feels comfortable. A library full of dead documents makes people distrust the live ones. Pruning is what makes the remainder credible.

And put the owner and the last-reviewed date in every header. A reader who can see "reviewed eleven months ago" knows how much to trust it.

Full model: how to stop your documentation going stale.

Step 4 — Standardise, but ask why first

Two people run the same process differently. The instinct is to issue the correct version.

Variance is information before it's a problem. Ask why, and the answers sort into four kinds — an improvement worth adopting, a gap in the standard, a training failure, or genuine drift. Only the last is what people assume all variance is, and going straight to enforcement means you frequently standardise on the worse version.

When you do standardise, work outward-in: output first, then constraints, then steps. For a lot of work, agreeing what must exist at the end and what must not happen is enough, and legislating the route costs flexibility for no gain.

Some variance should stay. Judgement-heavy work standardises into worse outcomes — that's what playbooks are for.

And if people drift back after you standardise, that's feedback rather than indiscipline. The standard is usually wrong in a way that wasn't visible when it was written.

Full method: when two people do the same job differently.

Step 5 — Systemise the decisions

This is the step that separates documentation from actually removing yourself as the bottleneck.

You can document every task, hire well, and still be the constraint — because work keeps stopping at a decision only you make. Can I refund this? Is this discount okay? Should we take this client?

Documenting tasks removes execution work. Documenting decisions removes the waiting.

Write the rule from your last ten actual decisions, not from principle — a rule invented from principle won't match your behaviour, so you'll overrule it, which teaches everyone it isn't real.

Every rule needs three parts:

Threshold:  the number or condition
Default:    what happens — an action, never "use judgement"
Escalate:   when to come to me anyway

Then delegate the decision, not the recommendation. Someone bringing you options is still a queue with you at the end of it.

Keep the rare, the expensive and irreversible, and the strategic. Rules are for the recurring middle.

Full method: systemising decisions, not just tasks.

What this connects to

• Before this — documentation only pays on processes that recur and will be handed over. Write the SOP on the third repetition, not the first.
• After this — a documented, stable process is the precondition for automating it. Automating an undocumented process encodes the mistakes and makes them faster.
• Alongside — documentation is what makes delegation work. Handing over undocumented work teaches by interruption.

The mistakes, collected

1. Wrong format for the reader. An SOP read by experts, or a checklist given to novices.
2. A library with no links from the work. Correct, filed, unread.
3. Approval required to edit. Guarantees staleness.
4. Never deleting. Dead documents discredit the live ones.
5. Enforcing variance away before asking why. You lose the improvement.
6. Documenting tasks but not decisions. You remain the bottleneck.
7. Overruling a correctly applied rule. Teaches everyone the rule is fiction.

Where to start this week

Take the process you get asked about most and do two things: check it's in the right format for whoever reads it, and put a link to it at the exact point where the work starts.

Then, for the next fortnight, note every decision someone brings you. The one that recurs most is your first decision rule — and it will probably remove more interruption than any document you write.