Process Documentation Guide
How to document a whole area of the business rather than a single procedure — what to write first, how much is enough, and when to stop.
Documenting one procedure is a task. Documenting a business is a project, and most of them stall at thirty percent.
They stall for the same reason: they start at the beginning and try to be complete. A documentation effort that aims for completeness produces a lot of unused pages and runs out of energy before it reaches the processes that mattered.
This is how to do it so it finishes.
Read how to write a single SOP · Request Your Free Systems Audit
Start from the pain, not the org chart
The instinct is to work through the business systematically — sales, then delivery, then finance. It feels thorough and it fails, because the first thing documented is rarely the thing that needed documenting.
Order by this instead:
- What breaks most often
- What only one person can do
- What runs most frequently
- Everything else, maybe never
The fourth category is larger than people expect and that's correct. Not everything needs documenting.
Three levels of detail
Not every process needs the same treatment. Decide the level before you start writing.
| Level | What it is | Use when |
|---|---|---|
| Map | the flow, steps, decisions, handoffs | you need to understand or improve it |
| Procedure | executable steps someone can follow | someone else will do the work |
| Reference | rules, formats, standards | people need to look something up |
Most efforts fail by writing procedures for everything. A process you will always do yourself needs a map, not a procedure. A naming convention needs a reference page, not a numbered sequence.
The order of work
1 · Inventory, before anything else
List the processes. Just names, one line each. Don't document anything yet.
Aim for twenty to forty lines. If you have a hundred, you're listing tasks rather than processes.
For each, note three things: how often it runs, who does it, and whether it breaks.
This takes an afternoon and it changes what you do next. Most people discover their priority order is different from what they assumed.
2 · Pick five
Not all of them. Five.
Five documented processes is a result. Forty half-documented ones is a graveyard, and the half-done state is worse than nothing because nobody knows which pages to trust.
3 · Map before you procedure
For each of the five, map it first — what actually happens, confirmed with the person who does it. Then decide whether it needs a procedure at all.
Roughly half won't. That's a successful outcome, not a shortfall.
4 · Simplify before you write
The map will surface steps that exist for no current reason. Remove them before writing the procedure. Documenting a step you're about to delete is the most common form of wasted effort in this work.
5 · Write, test, and stop
Write the five. Test each with the person who'll use it. Then stop and use them for a month before adding more.
How much is enough
The test is always the same: can someone who wasn't there execute this without asking a question?
Not: is it comprehensive. Not: does it cover every edge case. Those lead to documents that are technically complete and practically unread.
Signs you've written too much:
- Explaining why a step exists, inside the step
- Covering cases that happen once a year
- Describing the software's interface rather than what to do in it
- A procedure longer than two pages for a process shorter than an hour
Signs you've written too little:
- "Depends" appears anywhere
- A step says "as appropriate" or "as needed"
- No exceptions listed
- No verification section
Structure for a whole area
When documenting a business area rather than a single process, use three layers:
Overview — one page. What this area does, which processes live in it, who owns them, where the documents are.
Procedures — one per process, in the standard format.
Reference — the rules that apply across several procedures. Naming conventions, data standards, decision rules, approval thresholds.
Pulling the shared rules into reference pages is what stops the same rule being restated in six procedures and then updated in two of them.
Keeping it alive
Documentation degrades. The question is whether it degrades visibly.
Every document has an owner. One name. Not a department.
Every document has a review date. Set when written. Six months is reasonable for most, three for anything that touches a tool that updates often.
Every change gets a version. Not a full history — just a number and a date, so people can tell whether what they're reading is current.
One location. The most common failure isn't choosing the wrong tool, it's ending up with procedures in three places and nobody knowing which is authoritative.
The stale document problem
A procedure that's wrong is more dangerous than one that's missing. Missing procedures make people ask. Wrong ones make people act.
Two defences:
Date everything prominently. A reader who can see a document is eighteen months old will check before relying on it.
Make correction trivial. If updating a procedure requires a request to someone, it won't happen. The person who finds the error should be able to fix it, or at minimum flag it in one click.
When documentation is the wrong answer
Some problems look like documentation problems and aren't:
The process changes constantly. Stabilise it first. A document chasing a moving process is permanent work.
Nobody follows the existing documentation. More documentation won't fix that. Find out why — usually it's wrong, hard to find, or the real process diverged.
The process is genuinely one person's expertise. Document the decision framework and the inputs, not an imitation of judgement.
It only happens once. Write a note. Move on.
A realistic timeline
| Phase | Time |
|---|---|
| Inventory | half a day |
| Map five processes | one to two weeks, part-time |
| Simplify and write | one week |
| Test and correct | one week |
| Use before adding more | one month |
Roughly six weeks to a documented core, and most of it is waiting for other people rather than writing.
Anyone promising a documented business in a fortnight is selling you pages.
Document the five that matter. Use them for a month. Then decide whether you need more — you'll usually need fewer than you thought.
Not sure which five?
A free systems audit produces the inventory and tells you where to start.