How to Write an SOP (Standard Operating Procedure) People Follow
An SOP only works if people read and use it. Here is how to write procedures that survive contact with real work.
Why Most SOPs Sit Unread
A standard operating procedure should be the most useful document in a company. In practice, most are written once, filed away, and ignored until something breaks. The reason is rarely the process itself. It is that the document was written for an auditor or a manager, not for the person who actually has to do the work.
An SOP that people follow is written for a reader who is tired, distracted, and doing the task for the first time in months. It is short, action-first, and built around the real steps rather than the idealized ones. When it matches how the work actually happens, people use it. When it does not, they improvise and the document goes stale.
What follows is how to write procedures that survive contact with real work: the structure, the level of detail, and the habits that keep the document alive.
Two Audiences, Two Different Needs
| Reader | What they need from the SOP | What that means for writing |
|---|---|---|
| New hire learning the task | Every step spelled out, with context | More detail, screenshots, edge cases |
| Experienced person doing it weekly | A fast checklist they can scan | Lean steps, skip the obvious context |
| Auditor checking compliance | Evidence the process is controlled | Version history, owner, review date |
Write Steps as Actions, Not Narratives
The core failure of bad SOPs is that they describe the process in prose instead of steps. A paragraph that explains what happens during onboarding is useless to someone who needs to do onboarding. They need a numbered action they can follow and check off, not a summary.
Start each step with a verb. Open the admin panel. Click Users, then Invite. Enter the email and select the Editor role. That structure lets a reader move through the task without parsing sentences. It also makes the gaps obvious, because any step that does not begin with an action probably hides two.
Test the steps by doing the task exactly as written, with no outside knowledge. Wherever you reach for a step that is not on the page, that is a missing step. This dry run catches more errors than any review meeting, and it takes ten minutes.
Writing an SOP in Six Moves
- 1Watch the work before you write
Sit with the person who does the task and observe it end to end. Write down what they actually do, including the shortcuts they will never admit to. The real process is your source material, not the official flowchart.
- 2Define the scope and trigger
Open with one sentence on when this SOP applies and what starts it. 'Use this when a new full-time employee starts and needs system access.' Scope prevents the document from being misapplied.
- 3List the steps in order
Write each as a verb-first action on its own line. If a step has sub-steps, indent them. Aim for the level of detail a competent but new person would need, then trim.
- 4Add the edge cases
After the main flow, add a short section on what to do when something deviates: a tool is down, a field is missing, an approval is denied. Most SOP failures happen in these gaps.
- 5Name an owner and a review date
Every SOP needs one accountable owner and a date to revisit it. Without these, the document rots. Set the review cycle to match how often the process changes.
- 6Test it cold
Hand the draft to someone who has never done the task and watch them try to follow it. The places they stall are the places your writing failed. Fix those before publishing.
What Makes an SOP Go Stale
- Steps written from memory instead of observation, which miss the real workflow.
- Screenshots that go out of date the moment the tool updates its interface.
- No named owner, so nobody notices when the process changes underneath.
- Buried in a folder nobody checks, instead of linked where the work happens.
- Edge cases left out, forcing people to improvise around the documented flow.
- No review date, so the team trusts a document that is years out of date.
For tasks people do often, strip the SOP down to a one-page checklist. The full version lives in the system for training. The checklist lives next to the work. Hospitals and aviation crews use checklists for a reason: they cut errors and survive stress far better than paragraphs of instructions.
Where the Document Lives Matters
An SOP that sits in a shared drive three clicks deep is functionally invisible. The document needs to live where the work happens, linked from the tools people already use. If onboarding happens in the HR system, the onboarding SOP belongs there. If the task is run from a project tracker, link the SOP in the ticket template.
This is also why format matters more than completeness. A short, scannable checklist that people actually open beats a thirty-page manual that looks thorough. Aim for the version a tired person will use at 4pm on a Friday, because that is the real test.
What Good Procedures Achieve
An SOP is working when the person doing the task opens it without being told to. If they only reach for it under threat of an audit, the document has already failed.
Make your writing sound human
Humanize AI-generated text in one click with AI Humanizer Lab.
Try for free