Process documentation is the written record of how a piece of work actually gets done: what starts it, what the steps are, who is allowed to decide what, and what happens when something falls outside the normal path. When it's done well, someone else can run the process without interrupting you. When it's done badly, the document exists and the questions keep coming anyway. Most process documentation on a small team fails for one of five predictable reasons — and each one has a specific, mechanical fix you can apply in a few minutes.
Key takeaways
- Writing steps as a narrative buries the actions; one action per line, starting with a verb, is what a reader can actually follow under pressure.
- A process with no stated trigger gets run at the wrong time, run twice, or not run at all.
- Omitting decision rights is why your team keeps waiting on you — without a written "who may decide, up to what limit, escalate when," asking you is always the safe option.
- A document with no named owner and no review date quietly goes stale, and nobody notices.
The root cause: you wrote a story, they need instructions
People don't write bad SOPs on purpose. They write a description of what happened — a story — because that's how the knowledge sits in their head. A story reads fine to the person who lived it and is close to useless to the person running it next week.
A decision-ready SOP is written for the second reader, not the first. Five things go wrong most often. The fixes below are mechanical; if you'd rather not assemble the structure yourself, the free SOP template at https://tools.exiuss.com/sop-template has these sections built in already.
Five process documentation mistakes and the exact fix
1. Steps written as a narrative instead of a checklist
What it looks like: "The manager reviews the expense and, once satisfied, forwards it to finance, who process the reimbursement."
That single sentence hides four separate actions, two actors, and a judgement call. Nobody can tell where they are in it, and nobody can tell what "satisfied" means.
The fix: one action per line, each starting with a verb, with the actor named.
- Employee submits the receipt, amount, and category through the expense form.
- Manager checks the amount against the category budget.
- Manager approves, returns it to the employee for missing information, or escalates it.
- Finance adds the approved expense to the next payment run.
2. The trigger is missing
What it looks like: the steps start, but nothing says what starts the process, who kicks it off, or when it's finished.
The fix: open every SOP with two sentences — "This process starts when ___" and "It ends when ___."
Worked example: "This process starts when an employee submits an expense through the expense form. It ends when the expense is reimbursed or declined, with the reason written on the record."
That pair of sentences kills most of the "is this the right form?" questions before they get asked.
3. Decision rights are left out
What it looks like: "Manager approves the expense." No limit. No escalation. No statement of what happens when the manager is away.
This is the mistake that costs the most, because it's the reason your team waits for you. If the SOP doesn't say who may decide, the only safe move is to ask the person who usually decides. That's you.
The fix: a decision table with four columns.
| Decision | Who may decide | Limit | Escalate when |
|---|---|---|---|
| Approve a normal expense | Direct manager | Within the team's category budget | The amount falls outside the category budget |
| Reclassify an expense | Finance lead | Any category | The change affects a client-billable line |
| Approve a recurring subscription | Department head | Within the team's budget | It's a new vendor |
| Reimburse without a receipt | Finance lead | Within the receipt policy | The same person is missing receipts repeatedly |
Read each row as one line: decision | who may decide | limit | escalate when. It's short, it's checkable, and it means the manager stops being the bottleneck for things they never needed to see.
4. The exception path is a shrug
What it looks like: the document covers the happy path and stops. The moment an expense doesn't fit a category, the process dissolves and someone phones you.
The fix: write the default. Not every exception — just the default route.
Worked example: "If an expense doesn't fit an existing category, route it to the finance lead. Don't send it back to the employee." One sentence, one behaviour change.
5. No owner and no review date
What it looks like: the document lives in a folder, was accurate the day it was written, and has been drifting ever since.
The fix: put two things at the top of the SOP — a named owner (one person, not a team) and a review date. When the review comes round, the owner reads it once and either confirms it or fixes it.
The five fixes at a glance
| Mistake | What it costs you | The fix |
|---|---|---|
| Narrative steps | Readers stall and ask you anyway | One action per line, verb first, actor named |
| Missing trigger | Process starts late, twice, or never | "Starts when ___ / ends when ___" at the top |
| No decision rights | Everything escalates to you | decision / who may decide / limit / escalate when |
| No exception path | Process collapses on the first odd case | Write the default route in one sentence |
| No owner or review date | Silent drift until it's wrong | One named owner, one review date |
Quick checklist
- Name the trigger and the finish line in two sentences at the top.
- Rewrite every step as one action per line, starting with a verb.
- Add the decision table: decision, who may decide, limit, escalate when.
- Write the default route for the most common exception.
- Name one owner and set a review date.
- Read it back as if you'd never seen the process before.
None of this is hard. It's just easy to skip when you're writing from memory in a hurry — which is exactly why a template that pre-structures the sections is worth more than a blank page.
The free SOP template at https://tools.exiuss.com/sop-template walks you through these sections in order and gives you a clear, ready-to-use standard operating procedure at the end. Click "Fill with an example" and you'll see how decisions get written as decision | who may decide | limit | escalate when. Most people finish their first one in about fifteen minutes, and the tool drafts from your own inputs, so what comes out is your process, not a generic sample. Your next process doesn't need to be perfect — it needs to be written down, with the decisions spelled out, so the next question goes to the document instead of to you.