SOP optimization: how to write procedures people actually follow

Standard operating procedures fail for dull reasons. They are too long, they describe the process as designed rather than as run, and they are stored somewhere nobody looks. The fix is not better writing. It is a different structure and a short testing routine.

Why SOPs go unused

• They answer the wrong question. The author describes the whole process. The reader at 4pm on a Friday wants to know what to do next.
• They skip the exceptions. The common path is easy to write. The odd cases, which cause the problems, get a vague line or nothing.
• They are out of date. Once a procedure is wrong once, people stop trusting it for good.
• They live in a folder. If it takes four clicks to find, a colleague asking will always win.

A structure that works

Keep each SOP to one or two pages. Use this order:

1. Purpose and outcome. One sentence: what this procedure achieves and who receives it.
2. Trigger. What starts it: "A signed contract arrives in the shared inbox."
3. Owner and backup. A named person and a named stand-in.
4. What you need. Systems, access rights, documents and information required before starting.
5. Steps. Numbered, each starting with a verb, each with one action. Put decisions as explicit branches: "If the amount is over 5,000, go to step 9."
6. Exceptions. The three or four situations that really occur, and what to do in each.
7. Done means. How you know it is complete, and who is told.
8. Version and review date.

Rewriting an existing SOP

Start with observation, not the old document. Ask someone to do the task while you watch, and write down what they actually do. Compare it with the written version. The gaps fall into three types: steps people skip because they are unnecessary, steps people add because the system needs them, and workarounds for problems nobody fixed. Each type calls for a different response: delete, document or fix at source.

The five-minute test

Give the draft to someone who has not done the task before. Do not explain anything. Ask them to follow it on a real or practice case. Every time they hesitate, ask a question or make a mistake, the SOP has a gap. Fix those and test again with another person. Two rounds of this beat any amount of reviewing by the author.

Style notes that help

• Use screenshots only where a screen is confusing, and date them. Old screenshots erode trust.
• Write "the invoice" and not "the document". Use the term people use at work.
• Put warnings next to the step they apply to, not in an introduction nobody reads.
• If a step needs more than three lines of explanation, it is probably two steps.
• Where you can, replace a paragraph with a checklist or a table.

Keeping SOPs alive

Assign one owner per SOP. Set a review date no later than 12 months out, sooner for fast-changing processes. Add a one-click way for users to report a problem. And store SOPs where work happens: linked from the ticket template, pinned in the team channel, or embedded in the workflow tool. If you are automating a process, update the SOP at the same time, so people know which steps the system now performs and what to do when it stops.

How long should a set of SOPs be?

Fewer than you think. Document the processes that are high-risk, frequent or handed between people. Skip the one-off task that one person does once a year. If you are unsure where to start, the process audit checklist shows which processes lack documentation, and our process consulting includes a draft SOP for each process we map.

Related reading and services