How to structure SOPs that survive the person who wrote them
Most SOPs fail at the exact moment they're supposed to matter.
Someone leaves, or takes real time off, and the next person opens the document expecting it to tell them what to do. It does. It tells them to check the intake form, flag any missing fields, and route the ticket to the right queue. What it doesn't tell them is what to do when the intake form is filled out correctly but something about it still doesn't sit right, the kind of thing the person who wrote the SOP would have caught without thinking, because they'd seen the pattern a hundred times before they ever wrote a word down.
That gap is not a documentation problem in the way most people mean it. It's not that the SOP needs more steps. It's that steps and judgment are two different kinds of information, and almost every SOP only captures one of them.
What gets written down, and what doesn't
Ask someone experienced to document their process and you'll get the steps first, every time. Open the workspace. Check the status. Update the field. That's the easy part to write, because it's the part that's already conscious. The harder part, the part that actually took years to build, is the judgment underneath the steps: when to deviate, what a specific kind of exception actually means, which shortcuts are safe and which only look safe.
That judgment rarely gets written down, not because anyone's hiding it, but because the person who has it has stopped noticing they're using it. It feels like doing the job well. It doesn't feel like a separate thing worth documenting.
What an SOP needs to actually hold, to survive its author leaving
A step without its reasoning is a trap for the next person, because the moment reality doesn't match the documented case exactly, they have nothing to reason from. Three things change that.
The exception log. Every SOP should carry a running list of the situations that didn't fit the standard steps, and what was actually decided each time. Not hypothetical edge cases, the real ones that have already happened. This is where the judgment lives, in the pattern across real exceptions, not in a single "if this, then that" branch that can never anticipate everything.
The why behind each step, not just the step. "Confirm the client's timezone before scheduling" is a step. "Confirm the client's timezone before scheduling, because a missed timezone on this account type has caused two cancelled onboarding calls this year" is the same step with the reasoning attached, and the reasoning is what lets the next person adapt the step when the situation is close but not identical.
A named owner whose job includes updating it. An SOP with no owner decays the moment it's written, because nobody's job is to notice when reality has moved past the document. The update doesn't have to be dramatic or scheduled quarterly, it works best as a habit: when an exception happens, it gets logged that week, not eventually.
The part most people skip
None of this is expensive to build. It's a habit of capture, a few extra minutes at the point something unusual happens, rather than a large documentation project scheduled for someday. The cost isn't time. It's that it requires someone to notice, in the moment, that what they just handled was worth writing down, and most operations don't have anyone whose actual job includes noticing that.
That's the difference between an SOP that's a formality and one that's real infrastructure. One survives being read. The other survives the person who wrote it leaving.
If your systems live mostly in one person's head, including your own, that's usually the first thing worth mapping in a strategy session, not the tenth.