An SOP written by an expert for themselves is just notes. A real SOP assumes the reader knows nothing, leaves nothing to memory, and gets tested by someone who's never done the task.
Quick gut check. If you got hit by a bus tomorrow (sorry, dark, but stay with me), could your business keep running? Or does a scary amount of how things work live entirely inside your head?
For most owners I talk to, it's the head. And the usual answer is "I should really write some SOPs." Cool. The problem is most SOPs are written badly, so they don't actually help, so people decide SOPs don't work. SOPs work. Most just aren't written for the right reader.
The expert curse
Here's the trap. The person who writes the SOP is the person who already knows how to do the thing perfectly. So they write it for themselves. They skip the "obvious" parts, because to them those parts are obvious.
"Log into the CRM and update the contact." Update it how? Which fields? What if the contact doesn't exist yet? What counts as done? The expert doesn't ask those questions because the expert already knows. But the SOP isn't for the expert. It's for the person who doesn't know yet. And that person is now stuck on line one.
An SOP written by an expert for an expert isn't an SOP. It's a sticky note. The whole job of a real SOP is to transfer knowledge to someone who doesn't have it.
Write the SOP for the most capable, most clueless person you can imagine. Smart enough to follow it, brand new enough to need every step.
How to write one that actually works
Here's the approach I use, and it's genuinely not hard, it's just a discipline.
- Assume zero context. Spell out where to log in, what to click, what things are called. The reader should never have to guess or "just know."
- One action per step. If a step has an "and" in it, it's probably two steps. Break it down. Tiny steps are easy to follow and easy to check off.
- Define "done." Every process needs a clear finish line. What does the screen look like when it's right? What's the last action? How do they know they succeeded?
- Show, don't just tell. Screenshots. A quick screen recording. A two-minute video beats two pages of text for anything visual.
- Cover the "what if." What if the contact already exists? What if the payment fails? The edge cases are exactly where a new person panics. Answer them in advance.
The test that proves it works
Here's the step almost everyone skips, and it's the most important one. Once you've written the SOP, do not edit it yourself. Hand it to someone who has never done that task. Watch them try to follow it. Say nothing.
Every time they pause, ask a question, or do something wrong, that's a bug in the SOP. Mark it. Don't explain it to them out loud, fix it in the document. Their confusion is your edit list. It's the most honest feedback you'll ever get.
An SOP that hasn't been tested by a real beginner is just a guess. An SOP that someone brand new ran successfully, start to finish, with you staying quiet, is a real asset. That's the difference between a document and a system.
Why this is worth the effort
Good SOPs do three big things. They let you delegate without the work coming back worse. They make hiring and onboarding actually fast instead of a multi-month babysitting project. And they protect you, because the business stops being hostage to your memory and your availability.
Every process you get out of your head and onto paper is a little piece of your freedom back. You don't have to document everything this week. Pick the one process you're most tired of explaining over and over, and write that one properly. Then test it. Then do the next one. That's how a business slowly learns to run without you standing over it.