How to write SOPs people use
Most SOPs get written once and never opened again. A few habits turn a document nobody reads into something the team reaches for.
Almost every growing team has a folder of SOPs. Most were written in a burst of good intentions, often right after something went wrong, and most haven't been opened since. The team usually does care. The trouble is that the documents were written to prove a process exists, when they needed to help someone do the work.
The fixes are mostly about who writes an SOP, how long it is, and where it lives.
Write the SOP while doing the task
The worst SOPs are written from memory in a meeting room. People describe the process they think they follow, which is usually tidier than the real one. The steps that get left out are the ones that matter: the login that only works from one machine, the client who needs a different file format, the approval that happens in a Slack thread.
We write SOPs with the task open, step by step, while someone does it. If the person doing it says "then I just fix it", that's a step, and it needs writing down.
Keep it to one task per document
An SOP called "Client onboarding" that runs to fifteen pages won't get read. Split it into the tasks people actually look for: setting up the client in the CRM, building the first report, running the kickoff call. Each one should fit on a screen or two. When a process has many parts, give it a short index page that links to each task in order.
Put the checklist first and the detail underneath
Atul Gawande's New Yorker piece on checklists is still the best case for this. In the intensive care units he describes, a short list of basic steps, followed every single time, cut infections, because even experts skip obvious steps when they're under pressure. The WHO's Safe Surgery work and its surgical checklist grew out of the same idea.
Most business tasks are nowhere near that high-stakes, but the lesson carries over. Put the checklist at the top of the SOP, one line per step, so someone who has done the task before can run down it in half a minute. Put the explanation, screenshots and edge cases underneath, for the person doing it the first time.
Use screenshots and short recordings
A screenshot with the right button circled beats a paragraph describing where the button is. A screen recording under a minute long beats both for anything with more than a few clicks. Keep them short enough that re-recording is painless, because the tool will change its layout eventually.
Give every SOP an owner and a review date
Documents go stale. Tools move their menus, the team changes how it works, and within a few months the SOP describes a process nobody follows. Put a name and a review date at the top of every document. The owner should be the person who does the task most often, rather than their manager, because they're the first to notice when the document stops matching reality.
One rule keeps the documents honest: whoever finds a wrong step fixes it on the spot, or tells the owner the same day.
Keep SOPs where the work starts
If the SOP lives in a folder nobody visits, the team will work from memory instead. Link it from the place the task begins: the project template, the ticket type, the recurring calendar event, the stage in the CRM. It should be one click away at the moment someone needs it.
Test it on someone new
The real test of an SOP is whether a person who has never done the task can follow it without asking questions. When someone new joins, have them run the SOP while the owner watches and stays quiet. Every question they ask marks a gap in the document.
It's also how we finish an embedded operator engagement: the team runs the process from the SOPs while we watch, and we fix the documents until nobody needs to ask.