How to Write an SOP Your Team Will Actually Follow

You did the responsible thing. You wrote the standard operating procedure. It took you an afternoon, it's thorough, and it's sitting in a folder somewhere with a name like Customer_Onboarding_Process_FINAL_v2.

And nobody follows it. People still ask you how to do the thing. The new hire learned it by watching someone else, not by reading your document. When you check, half the team didn't know the SOP existed and the other half read it once and went back to doing it their own way.

It's tempting to blame the team's discipline. Don't. After twenty years building training and quality systems — including running quality for a provider network of 135,000 at Guardian Life, where "people don't follow the procedure" was a daily, expensive problem — I can tell you the issue is almost never discipline. It's that most SOPs are written in a way that guarantees they won't be used. Fix the writing, and the following takes care of itself.

Why SOPs get ignored

The same six failures, over and over:

• Written by the expert, for the expert. The person who knows the process best writes down what they would need — which is almost nothing, because they already know it. The newest person needs ten times more detail, and it isn't there.
• It's prose, not steps. Three dense paragraphs describing a process can't be followed while doing the process. People need a numbered list they can check off, not an essay they have to interpret.
• Too long. A 12-page SOP for a 6-step task doesn't get read. Length signals "this will be painful," and people route around it.
• No owner. When nobody owns the document, nobody updates it, and the moment it's wrong once, people stop trusting it entirely.
• It's stale. The tool changed, the step changed, and the SOP didn't. One outdated step teaches the whole team that the SOP lies — and a document people don't trust is worse than no document.
• It lives where nobody looks. If the SOP is in a drive folder three clicks from where the work happens, it might as well not exist. It has to be where the hands are.

The principles of an SOP people follow

1. One process per document

Not "Customer Operations." "Onboarding a new customer." One job, start to finish. If you're tempted to put two processes in one doc, you've got two SOPs.

2. Write for the newest person who'll ever do it

Not for yourself. Picture the person three weeks into the job, doing this for the first time, with you on vacation and unreachable. Every step should be followable by that person. This single shift fixes most bad SOPs.

3. Numbered, actionable steps

Each step starts with a verb and describes one concrete action. "Open the admin panel and click New Customer." Not "the customer is created in the system." If a step has a sub-decision — "if they're on the annual plan, do X; if monthly, do Y" — call it out explicitly. Decision points are where people get stuck and come ask you.

4. The "why" only where it changes behavior

Don't bury the steps in background. But where a step is counterintuitive — "send the welcome email before creating the account, or the link breaks" — a one-line why prevents the helpful person from "improving" it into a bug. Reason where it matters, nowhere else.

5. An owner and a review date, on the document

Put a name and a "last reviewed" date right at the top. The owner is responsible for keeping it true. The date tells a reader whether to trust it. Both are what make the SOP a living thing instead of a dead file.

6. It lives where the work happens

Linked from the tool, pinned in the channel, one click from the task — not buried in a drive. The best-written SOP in the world fails if finding it takes more effort than just asking a colleague.

The structure that works

You don't need a fancy template. Six parts, in this order:

1. Title — the one process, named plainly.
2. Purpose — one or two sentences on why this exists and what "done right" looks like.
3. Scope — one line on when this applies and who does it.
4. Roles — who's responsible for what, if more than one person touches it.
5. Procedure — the numbered steps. This is the document. Everything else is framing.
6. Notes — edge cases, common mistakes, and the one or two quality checks that catch problems.

The only test that matters

This is the step almost everyone skips, and it's the one that separates an SOP that works from a document that decorates a folder.

Getting it out of someone's head when they're too busy to write

Here's the real bottleneck. The person who knows the process is the person with no time to document it, and asking them to "write up how you do onboarding" produces either nothing or a rushed, expert-for-expert mess.

So don't ask them to write. Ask them to talk. Sit with them for fifteen minutes while they do the task or narrate it, and you capture the steps. Or have them brain-dump the rough version — messy notes, out of order, missing detail — and let a tool or a second person turn that into a structured draft they only have to correct. Correcting a draft takes a fraction of the time of writing from scratch, and the expert is far more willing to do it. The fastest way to get knowledge out of someone's head is to do the structuring for them.

There's a harder version of this bottleneck — I've mostly run into it in enterprise organizations, but it happens in small and mid-size businesses too — and it's worth naming plainly: sometimes a person won't hand over the process because, somewhere underneath, they believe that being the only one who knows how to do it is what keeps them employed. It's an understandable instinct and a completely backwards one — and the way to move them isn't to argue with the fear, it's to flip it.

The person whose knowledge is trapped in their head is the one who can't be promoted (nobody can backfill them), can't take a real vacation (the panicked message finds them anyway), and can't move to the more interesting work (they're load-bearing right where they are). Indispensable isn't security; it's a ceiling. And from leadership's side, a single point of failure is exactly the risk a company wants to remove — which, over time, makes the hoarder more exposed, not less.

So reframe it: writing the SOP is how they stop being the bottleneck and start being the person who scales themselves. Put their name on the document as its owner, position them as the expert who's now training the team rather than the clerk who's being replaced, and tie it to something they actually want — the promotion, the week off that stays off, the project they've been asking for. People protect what they're afraid to lose; your job is to make documenting the process the thing they gain by, not the thing they're giving away.

The reframe: this is key-person insurance

Founders treat SOPs as bureaucracy. They're the opposite. The real cost an SOP addresses isn't messy process — it's the day your best operator quits, goes on leave, or gets hit by the proverbial bus, and walks out the door with a process that lived only in their head. For a small company, that single point of failure is one of the biggest unmanaged risks you have. Every SOP you write is one fewer person who is irreplaceable, and one faster onboarding for the next hire. That's not bureaucracy. That's the business getting more durable.

So write the one-process doc, for the newest person, as numbered steps, with an owner and a date, stored where the work happens — and prove it works by handing it to someone who's never done it. Do that and the SOP stops being a file nobody reads and starts being the thing that lets the company run without you in the room.