In short
Write the SOP at the moment of use, not in a planning session. Have the person who does the task narrate it while doing it, capture their exact words, then cut everything that is not a decision, a threshold, or a step that is easy to get wrong. Good SOPs are short, name a single owner, state the trigger that starts them and the condition that ends them, and live one click from where the work happens. Anything longer than two screens will be skimmed once and then ignored.
Key takeaways
- An SOP is a decision aid, not a transcript. Document judgement calls and thresholds; assume competence at everything else.
- Write it while the task is being done. Procedures written from memory in a meeting room are reliably wrong in the places that matter.
- Every SOP needs a named owner and a review date, or it silently rots into a liability.
- Distance kills adoption. If the procedure is not linked from the tool where the work happens, it does not exist.
- Measure SOPs by whether someone new can complete the task unaided, not by how many you have written.
Why most SOPs are never opened twice
The typical standard operating procedure fails for reasons that have nothing to do with effort. Somebody sat down, wrote a thorough document, put it in a shared drive, and announced it. Six weeks later, nobody has opened it. The usual conclusion is that the team is resistant to process. The real explanations are more mundane.
It was written from memory. Someone described the process as they believe it runs, in a quiet room, away from the work. What they produced is the idealised version: the path with no exceptions, no waiting, and no awkward client who needs the third step done differently. The first time a reader hits reality and the document has nothing to say, they stop trusting it.
It documented the obvious and skipped the hard part. Pages describing how to log in and where to click, and one line saying “review and approve” for the step that carries all the risk and all the judgement. The reader already knew how to log in. What they needed was the approval criteria, and it was not there.
It lives somewhere nobody goes. A folder three levels into a drive, named after the project that created it. The work happens in a project tool, an inbox and a CRM, and the procedure is in none of them.
The test of an SOP is not whether it is accurate. It is whether someone reaches for it when they are uncertain. Accuracy in a document nobody opens is worth nothing.
These are all failures of format and placement, not of discipline. Which is good news, because format and placement are cheap to fix.
What actually belongs in an SOP
Start from the reader. Somebody competent, who has done this once or twice, is halfway through the task and unsure about something specific. They do not want a narrative. They want an answer, fast, and then to get back to work.
That framing settles most arguments about what to include.
| Include | Leave out |
|---|---|
| Decisions and the rule for making them | Steps a competent adult does without prompting |
| Thresholds and numbers (“over £2,000 needs a second approval”) | Justification for why the process exists |
| Sequence where order genuinely matters | Sequence where it does not |
| Named exceptions and what to do about them | Every theoretical edge case anyone can imagine |
| The condition that means the task is finished | Screenshots of interfaces that change quarterly |
| Who to ask when the document does not cover it | Background on the tool the reader already uses daily |
The single most valuable line in most SOPs is a threshold. “Escalate if the client has asked twice.” “Anything above 15% discount goes to the founder.” “If the file is over 200MB, use the transfer service instead.” These are the things people currently interrupt someone to ask, and each one written down is a permanent reduction in the number of interruptions.
- Decision rule
- An explicit statement of the condition under which a choice is made, written so that a second person applying it reaches the same conclusion. Converting repeated judgement into decision rules is the mechanism by which documentation actually reduces key-person dependency.
This is also why documentation and key person risk are the same problem viewed from two angles. What makes someone irreplaceable is rarely a skill. It is an accumulation of undocumented decision rules that exist only in their head.
A format that survives contact with reality
Six elements, in this order. Anything else is optional and most of it is decoration.
- Trigger. What causes this procedure to start. A signed contract, a form submission, a date. If you cannot state the trigger, the procedure is not a procedure, it is a topic.
- Owner. One named person accountable for the document being right. Not a team, not a department.
- Last reviewed and next review date. Two dates, at the top, where they cannot be missed.
- Steps. Numbered, one action each, in the imperative. Decisions marked clearly with their rule.
- Exceptions. The three or four things that genuinely go differently, and what to do about each.
- Done condition. The observable state that means this is complete. Not “finish the handover” but “the delivery lead has confirmed in the project tool.”
The done condition is the element most often missing and the one that causes the most trouble downstream, because a task without a clear finish line is a task that gets handed off half complete. That is the failure mode described in handoffs are where work goes to die, and it starts here, in a procedure that never said what finished looks like.
On tone
Write in the imperative, address one reader, and use the vocabulary the team already uses. If everyone calls it the deck, the SOP calls it the deck, not the client-facing presentation asset. Documentation written in a register nobody speaks in is documentation that feels like it came from outside the team, and it gets treated accordingly.
Capture it live, edit it later
The most reliable way to get an accurate first draft is to stop writing and start recording. The method takes about forty minutes per process and produces better material than any amount of solitary drafting.
- Book a session with the person who does the task, timed for when they would actually be doing it.
- Ask them to work through it while narrating. Record the call or take notes verbatim.
- Every time they say “usually”, “normally”, or “it depends”, stop and ask what it depends on. This is where the decision rules are hiding.
- Every time they open something without explaining it, ask what they are checking for.
- Do not correct the process during the session. You are documenting what happens, not what should happen. Improvement comes second and gets easier once the current state is visible.
Minutes of live capture is usually enough for one process. The bottleneck is almost never the writing. It is getting time with the person who knows, which is why the highest-value processes to document are the ones belonging to your busiest people.
Editing afterwards is straightforward: delete anything the reader would do without being told, convert every “it depends” into a stated rule, and cut the length by half. The half you cut is almost always narration; the half you keep is decisions.
Keeping SOPs current without a documentation team
Documentation does not decay at a constant rate. It decays in steps, each one triggered by a change: a new tool, a new person, a policy revision, a client who negotiated something different. The maintenance system that works is not a calendar reminder. It is a habit of updating the document at the moment the change happens.
Three practices carry most of the load.
| Practice | What it prevents |
|---|---|
| Every SOP names one owner, visible at the top | Documents that are everyone's responsibility and therefore nobody's |
| Any change to a process includes updating its SOP before the change is announced | The gap between what people are told and what the document says, which destroys trust in the document permanently |
| Readers can flag an error in one click, without editing rights | Silent drift, where everyone knows step four is wrong and works around it |
That last one matters more than it looks. The people who discover a procedure is out of date are usually the people least empowered to change it: new hires, freelancers, junior staff. If the only route to fixing it is to request edit access and negotiate with the author, the error stays. A comment box, a form, a Slack channel, anything with no friction, converts those people into your maintenance team.
How many SOPs do you need?
Fewer than you think. In most businesses under fifty people, somewhere between eight and fifteen documents cover the processes that carry real risk. Trying to document everything is the reliable way to complete nothing, and a library of ninety procedures, most of them stale, is worse than a shelf of twelve that are correct. Rank by frequency multiplied by cost of getting it wrong, then start at the top.
Testing an SOP: the new-person standard
There is exactly one meaningful test. Give the document to someone who has never performed the task and watch them attempt it without help.
Watching is the important part. Every question they ask is a defect in the document, and every moment of hesitation is an ambiguity worth fixing. Resist the urge to answer verbally: the whole point is to find where the procedure stops carrying the reader. Write the questions down, fix the document, and try again with a different person.
Most SOPs fail this test the first time in the same three places: an undefined term the author assumed was obvious, a decision with no stated rule, and a missing done condition. Fixing those three usually takes twenty minutes and converts a document from decorative to functional.
A business that can pass this test on its top ten processes has removed most of the operational risk that documentation is capable of removing. The Mayim Ops assessment scores documentation and knowledge as its highest-weighted dimension precisely because so much else depends on it, including whether you can safely automate anything at all.
Frequently asked questions
What is the difference between an SOP and a process map?
A process map shows the shape of the work at a distance: which steps exist, who touches them, and where handoffs occur. An SOP is the instruction for performing one of those steps. Map first when you do not know how the work flows, then write SOPs only for the steps where variation is expensive.
How long should an SOP be?
Short enough to read on one or two screens. If a procedure runs longer than that, it usually contains several distinct tasks that should be separate documents, or it is describing basic competence that does not need writing down. Length is a symptom of unclear scope, not thoroughness.
Who should write the SOP, the manager or the person doing the work?
The person doing the work supplies the content; someone else does the writing. People performing a task daily cannot see their own decision points, because those decisions have stopped feeling like decisions. A second person asking why at each step surfaces the judgement that needs capturing.
How often should SOPs be reviewed?
Every six months for stable processes, and immediately after any change to the tool, the team, or the rule the procedure depends on. Set the review date inside the document. A procedure with no review date will be quietly wrong long before anyone notices.
Should SOPs include screenshots?
Sparingly. Screenshots go out of date faster than any other element and are the most common reason a document loses credibility. Use them only where the interface is genuinely ambiguous, and never for steps in a tool that updates its layout frequently.