How to Write an SOP That People Actually Follow
RedHub AI Editorialupdated October 4, 20265 min read
Jump to a section8
How to write an SOP that people follow comes down to one test: could someone who has never done the task reach the same result you would, using only the page? Formatting barely moves that test. Accuracy, short steps and named exceptions move it a lot, and all three start with writing from what you do rather than what you remember doing.
TL;DR: An SOP gets followed when it matches the real task, so write it from a recording. Give every SOP a trigger, numbered one-action steps, named decision points, exact locations and a definition of done. Spend your words on the exceptions, since the easy path needs little help. Then test it with two readers: someone who knows the job, for accuracy, and someone who doesn't, for clarity. The AI-First SOP Engine ($79) drafts the SOP from your recording, so the first version starts from what happened.
Why SOPs get routed around
You have seen the SOP nobody follows. It sits in a shared drive, it says "update the CRM" in a business that switched CRMs in the spring, and the team quietly works around it. Once one step is wrong, people stop trusting the rest. An untrusted SOP gets skipped the first time it is inconvenient, and the person who wrote it usually hears about the workaround last.
Write it from a recording
Do the task once with a recorder running and talk through every click. You will say things out loud that never reach a from-memory draft: "I always check the billing contact here, because the person who signed is often not the person who pays." That sentence is a step. Written from memory, it usually goes missing, because you stopped noticing it a long time ago.
Our guide to documenting a process from one recording covers the recording itself: what to capture, and what a single run leaves out.
Five fields every followable SOP has
- A clear trigger: the exact event that starts the process, such as a form submission, a specific email or a date on the calendar
- Numbered steps, one action each: not paragraphs someone has to reread to find the instruction
- Named decision points: "if X, do A; if Y, do B" instead of judgment left to the reader
- Where things live: the exact tool, folder or link for each step, not "the shared drive"
- A definition of done: what confirms the process is finished, not just started
Keep each step to one action
A step that runs three sentences gets skimmed. "Open the client record, confirm the billing contact, and if it differs from the signer, email both" is three steps wearing one number. Split it. If a step needs context, put a short note under it and keep the step itself an instruction. The person following the SOP mid-task wants the next action, not the reasoning behind it every time.
Spend your words on the exceptions
Nobody needs much help with the version of the task where everything goes right. They need the page when the customer's card declines, when the upload arrives as a PDF instead of a spreadsheet, or when the client stops answering halfway through a project. Write each exception as a branch: if this happens, do that, and if you can't, tell this named person. An SOP that covers only the smooth run is missing the part people open it for.
Test it with two readers
Someone who knows the process has to check the draft for accuracy. AI-drafted or not, a step can be missing, out of order or invented, and a recording-based draft can still mishear a tool name. The expert catches those.
The expert is also the worst judge of clarity, because they fill every gap without noticing it. "Send the usual welcome pack" is obvious to the person who wrote it and meaningless to a new hire. So hand the draft to someone who has never done the task and watch where they stop. Every stop is a missing step. In a three-person business, that second reader may not exist yet. Then the first new hire's first run becomes the test whether you planned it or not, and our post on turning SOPs into real delegation covers how to run that first handoff on purpose.
Start from the recording, not the blank page
Your walkthrough's transcript goes in. A first draft comes out in a fixed format (trigger, owner, time to complete, numbered steps with decision branches, escalation criteria), along with a Claude skill and an automation map. It runs in Claude Pro, Team or the API. The two-reader check is still yours.
Turn a recording into a written SOP — $79Pairs well with
If the SOP will be run by an AI agent rather than a person, the Agent-Executable SOP Readiness Gate ($79) grades each step on six signals, including a defined success criterion and a stop or escalation path; a step missing either forces NOT EXECUTABLE. Agencies can start from the Agency Operators Skills Pack ($89), six Claude skills for client onboarding, weekly status reports, scope-creep detection, kickoff decks, invoice and time reconciliation, and renewal proposals. And when the written processes feed numbers you track, the Operating Cadence Engine ($299) rolls each week up to STEADY, NEEDS ATTENTION or OFF PLAN in a Monday report to your own inbox.
More in this guide
What should an SOP include?
A trigger, numbered steps with one action each, named decision points, the exact location of every tool or file, and a definition of done. Add an owner and an escalation rule if someone other than you will run it.
What makes an SOP get ignored?
It doesn't match what people do: a missing step, an outdated tool name, or vague instructions at the exact point where someone needs guidance. Once one part is wrong, people stop trusting the whole document.
Should an SOP explain why a step exists?
Keep the reason out of the step itself. If context matters, add a short note underneath, so the step still reads as a clear instruction mid-task.
How detailed should an SOP be?
Detailed enough that someone with no prior context can follow it and reach the same result you would, including what to do at each decision point, not just on the straightforward steps.
Is it faster to write an SOP from a recording than from scratch?
Usually. Narrating a task while you do it skips the work of rebuilding it from memory, and it captures judgment calls a from-memory draft tends to leave out. You still need to review the draft.
Who should review an SOP before it ships?
Two people if you can manage it: someone who knows the process, to check every step is accurate, and someone who has never done it, to find the steps that only make sense to the author.
The gate this post refers to, drawn from the tool’s own logic. See the tool.