Lesson 17: If Your SOP Can’t Be Explained in 90 Seconds, Nobody Will Use It When It Matters
That standard operating procedure sitting buried in a shared drive – fourteen pages long, filled with flowcharts and cross-references, unread by anyone when things go sideways – isn’t really a process. It’s just documentation theatre. Let’s talk about how to actually write an SOP people will use.
There’s a strange irony in most SOPs. They’re supposed to make things consistent, so when something breaks or a new person hops in, anyone can follow the right steps. But they’re written in a way that guarantees the opposite. Fourteen pages, edge case explanations, “background context,” references to other documents, and sometimes instructions that assume the reader already knows the process just to understand the process. People aim for thoroughness but end up with something that experienced team members ignore (because they already know it) and new folks simply can’t use – not when they’re under pressure.
I’ve written SOPs like that. Most operational leaders have. Then, in the middle of some crisis, someone is frantically scrolling through a massive document to find step three and you realize: thorough doesn’t equal usable. If nobody follows it, your “process” hasn’t actually created consistency – it just looks like it does. Execution still depends on memory, judgment, or improvisation.
You don’t need a better-organized fourteen-page manual. You need a single page with the crucial stuff, written brief enough to read while everything is on fire.
The Principle: If It Takes More Than 90 Seconds to Explain, It Won’t Work Under Pressure
If you’ve been following along, your operational toolkit is probably looking solid – processes mapped, failure points handled, signals tracked, experiments run, handoffs managed with checklists, releases protected, incidents turned into lasting improvements through retros.
All that work leads to a set of repeatable plays – you know the interventions and processes that work. Now the question is: can anyone on the team run those plays, even the ones who weren’t there when they were drawn up?
That’s the job of the SOP. But not the lengthy “reference” – the practical one-pager that spells out exactly what to do, what order to do it in, and who to call if things go sideways. Short enough to read in ninety seconds, clear enough to follow with zero background, easy enough to actually find in the heat of the moment.
A Real Example: A Support Team Hits “Day One”
Here’s where this principle became real for me. There was a support team dealing with a recurring issue: a failure that showed up regularly enough to be familiar but not so regular that everyone remembered the fix. Experienced folks sorted it fast, from memory. Newer members would escalate, resolve incorrectly, or take three times as long. Resolution times were all over the place and customers noticed.
The knee-jerk reaction? Document the fix more thoroughly. The existing SOP was just a paragraph in a larger guide; the suggestion was to expand with context, explanations, edge cases.
Instead, we went the opposite way.
We boiled the fix down to one page. Three steps: verify, apply hotfix, confirm with user. Added one explicit escalation step. A simple example showed what each step actually looked like. At the top, a “when to use this” line so nobody had to guess. And the whole thing fit on one page, written big enough for tired eyes.
We pinned it in the support queue, stuck it in the onboarding folder, printed it right near the relevant workstation.
Here’s what happened:
A new hire was able to fix the issue correctly on day one – without shadowing, without escalating. Resolution times dropped across the entire team. Consistency improved – everyone followed the same steps, so the quality gap closed. Escalations happened when they should, not too much or too little. The underlying process didn’t change. Its accessibility did. Turns out, most of the inconsistency was hiding in that gap all along.
How to Write a One-Page SOP (Tactically Speaking)
The template has zero fluff. Every piece has to be essential, or it’s out.
- Title/Purpose – one sentence.
State what this SOP covers and what it achieves. If you can’t summarize in a sentence, the scope is probably too broad.
- When to Use – one sentence.
What triggers someone to reach for this SOP? Make this obvious enough for someone to decide in five seconds.
- Inputs / Pre-conditions – bullet list.
What must be true before you start? Not background – just what the executor needs to check.
- Steps – three to seven bullets, max twelve words each.
These are the actions. Limiting to twelve words forces clarity. If a step takes longer, break it in two or relocate explanation somewhere else.
- Owner / Escalation – name or role.
Who owns it? Who do you call if something goes off script? Name a person or role – no generic “the team” stuff.
- Example – short scenario.
A simple, concrete illustration – helps turn steps into actual working knowledge, especially for someone new.
- Last Reviewed – date, every 90 days.
SOPs get stale. Systems evolve and people change. The review date keeps it honest – nothing is worse than someone following an outdated SOP.
- Where it lives.
Right at the place work happens. On a ticket, in the shared folder people actually use, printed at the workstation. Not tucked away somewhere you need several clicks and a search to find.
The Honest Lesson
My first SOPs were long, detailed, and honestly, I was proud of them. But in reality, they were almost useless “on the ground.” The people who needed them – new hires, anyone under stress, someone stepping into something unfamiliar – couldn’t use them when it mattered. They needed something readable in ninety seconds and actionable immediately. My version took study and prep.
Brevity and context aren’t a compromise. They’re the standard for quality. If an SOP gets everyone consistently following the right process, it’s done its job. If it’s comprehensive but never used when it counts, it’s just paperwork.
Write the version that actually works when everything’s going wrong: when the system is down, a customer’s waiting, and whoever’s reading it has never seen this mess before. That version? One page, three to seven clear steps, twelve words per step, a quick example, and put it where the work happens.
Brevity isn’t slacking – it’s the only way to make sure your SOP actually gets used.
Think about the headaches your team solves just by memory. Pick one. Write its one-page SOP. Title, when to use, pre-conditions, steps, owner, example, review date. Set it right where the action happens. Watch what changes when a new person faces that problem.
Stay tuned for my lesson on how to cover critical roles in my next post.