The SOP That Only Works When Nothing Goes Wrong

Pull the SOP for almost any process in a mid-market business and it will read cleanly: step one, step two, step three, done. Order comes in, order gets processed, order ships. It’s clear, it’s logical, and it’s an accurate description of exactly one version of events — the version where nothing unusual happens.

The version where the customer’s purchase order doesn’t match the quote, or the vendor ships two weeks late, or the system is down when the invoice needs generating — none of that is in the document. It doesn’t need to be, according to whoever wrote it, because “that’s not really part of the normal process.” Except in most businesses, some version of “not normal” happens often enough that it’s effectively part of the real process, just not the documented one.

Why SOPs get written this way

Documenting the happy path is genuinely useful and genuinely much easier than documenting every plausible exception. The person writing the SOP — often the person who does the job best — has usually internalised how to handle the exceptions so thoroughly that they don’t register as decisions anymore. They just know what to do when the PO doesn’t match, because they’ve done it fifty times. Writing that judgment down feels unnecessary to them, precisely because it’s become automatic.

This is exactly the gap that causes damage. The knowledge of what to do when things deviate is real, valuable, and entirely undocumented — living in one or two people’s heads rather than in the process itself.

Where this actually costs money

The cost shows up whenever the person who holds that undocumented knowledge is unavailable. A new hire follows the SOP exactly as written, hits the first genuine exception, and has no guidance at all — because the document was never built to handle it. They either freeze, escalate everything, or improvise something reasonable-sounding that may or may not match what the business actually wants done in that situation.

It also shows up at scale. A process that one experienced person can navigate by instinct becomes a bottleneck the moment volume increases past what that person can personally oversee, because the SOP itself was never actually capable of running the process — only the person’s judgment layered on top of it was.

Why nobody notices until it’s tested

Exceptions, individually, don’t feel worth documenting. Each one seems like a one-off — “this specific vendor is always late, so we just add a few days” — rather than a pattern. It’s only when you step back and count how often “the exception” actually occurs that it becomes clear the exception isn’t an edge case at all. It’s a routine part of the work that’s been quietly excluded from the process documentation because no single instance of it ever felt significant enough to write down.

What an SOP that actually holds up looks like

Document the two or three most common deviations explicitly, not just the ideal path. Not every possible exception — that’s an impossible standard — but the handful that come up often enough to be genuinely routine. If a vendor’s late shipment happens once a month, that deserves its own documented branch, not a footnote in someone’s memory.

Ask the person who does the job best what they do when things don’t go to plan, and write that down as a first-class part of the process. This is usually the single highest-value conversation in any process documentation exercise, and it’s the one most likely to get skipped because it’s less tidy than describing the ideal case.

Build in an explicit escalation path for genuine one-offs. Not every exception can or should be pre-documented. But the process should say clearly what to do when something entirely new comes up — who to ask, not just “use your judgment,” because a new hire doesn’t have the judgment yet to know when that’s the right call.

Revisit the SOP when the same “exception” comes up for the third time. A deviation that recurs has stopped being an exception. Treating it as one indefinitely is how a process document quietly diverges further and further from the process it’s supposed to describe.

The reframe worth making

An SOP that only works when nothing goes wrong isn’t really a description of the process. It’s a description of the easiest ten percent of the process, with the hardest and most valuable ninety percent left undocumented in someone’s head. The businesses with genuinely resilient operations aren’t the ones with the cleanest-looking process documents — they’re the ones who wrote down what actually happens when things don’t go to plan, because that’s the part a new hire, or a busy day, or an absent expert will actually need.

If your best-documented process still depends on one person’s judgment the moment something goes wrong, that gap is worth closing before it’s tested by their absence. See how our Operations & Supply Chain practice works →