Most SOPs are dead on arrival. They get written once, filed in a wiki nobody opens, and referenced in onboarding slides that get skimmed. Six months later, the actual process has drifted and the SOP is a historical artifact.
The problem is not effort. Teams spend real hours writing SOPs. The problem is structure, ownership, and feedback loops. Fix those three and your SOPs become load-bearing. Skip them and you are writing fiction.
The Core Insight
An SOP is not a document. It is a contract between the person doing the work and the person who will judge whether it was done right. If either party cannot point to the contract, the SOP failed.
The SOP Anatomy
Every SOP we ship has exactly these sections. No more, no less.
| Section | What goes here | |---|---| | Purpose | One sentence. Why this exists. | | Owner | One name. Not a team. A person. | | Trigger | The specific event that starts this process | | Inputs | What you need before you begin | | Steps | Numbered, atomic, verifiable | | Definition of Done | How you know it is complete | | Edge Cases | What to do when the normal path breaks | | Escalation | Who to ask when stuck | | Last Reviewed | Date and reviewer name |
Everything else is noise.
Step Writing Rules
- One action per step. "Open the dashboard and check the report" is two steps.
- Start with a verb. "Navigate to..." "Click..." "Email..." "Verify..."
- Include the exact UI label. Not "go to settings." Say "click the gear icon, then select Account Settings."
- Include screenshots for anything visual.
- Include time estimates for steps over 5 minutes.
- End with a verifiable outcome.
Atomic, specific, verifiable.
The Format That Works
The format that gets followed is a numbered checklist that the person can literally check off as they go. Long narrative docs do not get read to the end. Bullet lists are partial. Video walkthroughs are great as supplements but bad for reference.
The Ownership Rule
Every SOP has exactly one owner. Not a team. A single named person. The owner keeps the SOP current, reviews it quarterly, updates it when the process changes, and fields questions about edge cases. Teams that "own" an SOP own nothing.
The Review Cadence
Quarterly review, nothing more frequent, nothing less. The owner runs through it themselves and answers: Does this match how the work is actually done today? What step has caused the most questions? What edge case have we hit that is not documented?
Where Most SOPs Break
- Written by someone who does not do the work.
- No trigger — just advice, not a process.
- Steps too coarse.
- No definition of done.
- Hidden in a wiki nobody opens.
- Written once, never touched again.
The "Where It Lives" Problem
An SOP that lives in the wiki but not in the workflow tool is a reference. An SOP that lives where the work actually happens is operational. Wiki is a secondary copy. The primary copy lives next to the work.
The Onboarding Litmus Test
Hand a new team member an SOP. Give them no training beyond the document. Watch them execute. They complete correctly with no questions: SOP works. They get stuck or do it wrong: SOP is fiction, rewrite. This is the only real test.
The Starter Library
The first five SOPs to write: new client onboarding, client offboarding, lead qualification, weekly reporting, incident response. These five cover most operational leverage.
The One Rule That Changes Everything
If an SOP is not followed, do not blame the team. Fix the SOP. Every "violation" is a signal that the document does not match reality. Reality wins. The SOP has to match.