Every organization has a shared drive folder called something like “SOPs” or “Process Docs,” and in most of them, half the documents are outdated, a third have never been opened by the people actually doing the work, and the ones that are followed tend to be followed from memory, not from the document itself. Writing an SOP is easy. Writing one that survives contact with a busy team on a Tuesday afternoon is a different problem entirely — and it has less to do with writing quality than with how the procedure was built and where it lives.
SOPs that actually get followed share a few structural traits regardless of industry: they’re built with the people who do the work, they answer the questions people actually ask mid-task, and they live somewhere people are already looking when they need them.
Key Takeaways
- SOPs written by management without input from the people doing the work are the most commonly ignored — involve them from the first draft, not just for review.
- A good SOP answers “what do I do when it doesn’t go as planned,” not just the happy path — exceptions are where procedures actually get used.
- Format matters as much as content: a wall of paragraphs gets skimmed and abandoned; numbered steps, decision points, and visuals get followed.
- An SOP nobody has updated in over a year is either perfect or abandoned — and it’s almost never the former.
- Where the document lives matters more than most teams assume — if it’s not accessible at the point of work, it won’t be used at the point of work.
Why Most SOPs Get Ignored
The most common failure pattern is a procedure written top-down: a manager or process owner sits down, documents the process as they understand it, and distributes it. The problem is that the person writing it is rarely the person executing it day to day, and the document ends up missing the small judgment calls and workarounds that the actual practitioners rely on. When the SOP doesn’t match reality, people default to doing the task the way they always have, and the document becomes shelf-ware — technically current, functionally ignored.
A second common failure is scope: SOPs that try to cover every possible variation become long and dense, and length is the enemy of use in the moment. Nobody opens a fifteen-page document to answer a question they need resolved in the next ninety seconds. The procedures that get used are the ones scoped tightly enough to be scanned quickly under time pressure.
Build It With the People Who Do the Work
The single biggest predictor of whether an SOP gets followed is whether the people who execute the process helped write it. This isn’t a review-and-sign-off step at the end — it means starting the draft by shadowing or interviewing the actual practitioners, capturing the process as it’s really done, including the informal adjustments experienced people make that never made it into any official document.
A practical approach: pick the two or three people who are best at the task, walk through it with them step by step, and write the first draft directly from what they show you — not from what a manager assumes the process is. Then have someone newer to the role try to follow the draft literally. Wherever they get stuck or have to guess, that’s a gap in the document, not a gap in their competence.
Design for the Exception, Not Just the Happy Path
Most SOPs document the case where everything goes as expected — step 1, step 2, step 3, done. But people rarely need a procedure document for the case that goes smoothly; they already know how to do that from experience. They need it for the case that doesn’t: the system is down, the customer’s request doesn’t fit the standard categories, the approval didn’t come through in time. An SOP that only covers the happy path is missing the moment it would actually be useful.
For every SOP, explicitly list the two or three most common exceptions and what to do for each. A short “If this happens, do this” section at the end of the main steps is often the most-used part of the entire document, even though it’s usually the last thing written — or skipped entirely.
Format: Steps, Decision Points, and Visuals Over Paragraphs
An SOP written as dense prose paragraphs gets skimmed once and then abandoned, because it’s slow to scan under pressure. A few formatting principles make a measurable difference in whether people actually use the document:
- Numbered steps, not paragraphs. Each step should be a short, scannable action — “Open the request in the queue,” not a paragraph explaining the philosophy behind the queue.
- Explicit decision points. Where the process branches (“if the amount is over $5,000, route to manager approval”), call it out visually rather than burying the condition inside a sentence.
- Screenshots or simple diagrams for system steps. A screenshot with an arrow saves paragraphs of description and is far faster to follow while actually doing the task.
- A one-line summary at the top. Before the detailed steps, one sentence stating what this procedure is for and when to use it — this alone prevents people from following the wrong SOP for a similar-looking situation.
- Length capped to one screen where possible. If a procedure genuinely needs more than that, consider whether it’s really one process or several that should be documented separately.
Keep It Alive: Ownership, Review Cadence, and Retirement
An SOP that hasn’t been touched in over a year is a red flag, not a sign of stability — processes, systems, and teams change, and a document that hasn’t kept pace is quietly drifting out of sync with reality. Every SOP needs a named owner responsible for reviewing it on a set cadence (every six to twelve months is reasonable for most operational procedures), and a lightweight trigger for off-cycle updates whenever the underlying process changes — a new system, a policy change, a reorg.
Just as important: retire SOPs for processes that no longer exist. A folder full of documents for discontinued processes makes it harder to find the ones that are current, and erodes trust in the whole library — if people hit one stale document, they start assuming all of them might be stale, including the ones that aren’t.
Where the Document Lives Matters as Much as What It Says
An excellent SOP buried three folders deep in a shared drive that nobody browses is functionally the same as no SOP at all. Accessibility at the point of work is often the deciding factor in whether a procedure gets used — not the quality of the writing. If the process happens inside a specific system, the SOP should be linked from within that system if at all possible. If it’s a task people do from a task list or ticketing tool, link it directly from the ticket type. The fewer clicks between “I need to check the procedure” and “I’m looking at the procedure,” the more likely it is to actually get used in the moment it matters.
Frequently Asked Questions
How long should a typical SOP be?
Short enough to scan in under a minute for most operational procedures — often one to two pages including an exceptions section. If a process genuinely requires more length, it’s often a sign the process itself should be broken into smaller, separately documented steps.
Who should own SOP maintenance — the process owner or a central quality/ops team?
The process owner, with light coordination from a central function for consistency of format and a shared review calendar. Central ownership of the content itself tends to reproduce the same top-down problem that makes SOPs get ignored in the first place.
How do we know if an SOP is actually being followed, versus just existing?
Ask a few people doing the task to walk you through it without looking at the document, and compare. Large gaps between what’s documented and what’s actually done are the clearest sign the SOP isn’t being used as a working reference — it might just be there for audit purposes.
Should SOPs be approved through a formal sign-off process?
A lightweight sign-off (the process owner and one practitioner confirming it reflects reality) is enough for most procedures. Heavy multi-level approval chains slow down updates and discourage the frequent small revisions that keep an SOP accurate.