How to Write an SOP People Actually Follow

Most SOPs fail for the same reason: they were written by someone who already knew how to do the task, for an imagined reader who also already knew how to do the task.

The result reads like a reminder rather than an instruction. It works fine for the author and is useless to everyone else — which defeats the entire purpose, since the only reason to write one is so somebody else can run the process.

When to write one

The trigger is repetition plus handoff, not importance.

Write an SOP when all three are true:

1. The task happens more than once
2. Someone other than you will eventually do it
3. Doing it wrong has a cost worth avoiding

If only the first two are true, a checklist is enough. If only the first is true, don't write anything — you're documenting for its own sake, and unused documentation still has to be maintained.

Write it on the third repetition. The first time, you're still figuring it out. The second time tells you the shape. The third time is when you can see which steps are fixed and which vary by situation — and that distinction is most of what makes an SOP useful.

The format

Six parts. Nothing else earns its place.

1. Title — the task, as a verb

Onboard a new client — not Client Onboarding Documentation v2.

2. Trigger — what causes this to run

Runs when: a signed agreement is received.

Without a trigger, an SOP is a description. With one, it's a rule. This single line is the difference between documentation and a system.

3. Owner and time

Owner: account manager · Typical time: 40 minutes · Frequency: per new client

The time estimate does real work. It tells the person whether they can start now, and it lets you cost the process later when you're deciding what to automate.

4. Prerequisites — what you need before starting

Access, credentials, information, approvals. Every SOP that gets abandoned halfway is usually one where the person hit step 4 and discovered they didn't have a login.

5. The steps

This is where most SOPs go wrong. Three rules:

One action per step. "Set up the client in the CRM and send the welcome email" is two steps. It reads as one because you do them together — but the person following it can complete half and believe they're done.

Each step has a verifiable outcome. Not "configure the account" but "configure the account — you'll know it worked when the status shows Active."

Name the exact thing. Not "the usual template" but "the template named client-welcome-v3 in the Templates folder." The usual one is only usual to you.

6. Definition of done

Done when: the client has portal access, the kickoff call is booked, and the project appears in the weekly report.

State this explicitly. Otherwise "done" means whatever the person following it decides, which is how two people running the same SOP produce different results.

Handle the variations

Real processes have branches, and pretending they don't is the fastest way to make an SOP untrustworthy. Handle them inline:

Step 6. Send the kickoff invitation. — If the client is in a different timezone, offer three slots in their working hours. — If the client hasn't responded in 3 business days, escalate to the account lead.

The moment someone hits a situation the SOP doesn't cover, they stop trusting the whole document. One unhandled branch discredits the other nine steps.

Write for the least experienced reader

Assume the reader has never done this, doesn't know your internal vocabulary, and won't guess what you meant.

| Written for you | Written for them | |---|---| | "Update the tracker" | "Open Client Tracker in the shared drive. Add a row. Fill in name, start date, and owner." | | "Send the standard docs" | "Send welcome-pack.pdf and intake-form.pdf from the Templates folder." | | "Get it approved" | "Send to the account lead in Slack. Wait for a written yes before continuing." |

This feels laborious to write and it is. It's also the entire value — the version that assumes context is the version that needs you standing next to it.

Test it by not being there

The only real test: hand it to someone who hasn't done the task and don't answer questions.

Watch where they stop. Every question they have to ask is a defect in the document, not a gap in the person. Fix it, then hand it to the next person.

An SOP that has never been run by anyone but its author is a draft.

Keep it alive

Documentation rots faster than code, because nothing breaks visibly when it's wrong.

• The person who runs it edits it. If they find a step out of date, they fix it right then. Requiring approval to update an SOP guarantees it goes stale.
• Date every version and note what changed.
• Review on a schedule — quarterly for anything touching a tool that ships updates, annually for the rest.
• Delete dead SOPs. A library full of processes nobody runs makes people distrust the ones that matter.

Store it where the work happens

An SOP in a folder someone has to remember to open will not be opened.

Link it from the trigger point: in the project template, in the task itself, in the CRM stage, in the pinned channel message. The best-written SOP in the wrong location loses to a mediocre one that appears at the moment of need.

The mistakes that waste the most time

1. Documenting an unstable process. If the process is still changing weekly, wait. You'll rewrite it three times.
2. Writing from memory. Do the task and write as you go. Memory smooths over exactly the fiddly parts that trip people up.
3. One giant document. Split by trigger. Five focused SOPs beat one that covers a whole department.
4. No owner. An unowned SOP is nobody's job to maintain, and it will rot.
5. Automating before documenting. Automating a process you haven't stabilized just makes the mistakes faster and harder to see.

What to do next

Pick the task you've explained to someone more than twice. Do it once more, writing each step as you complete it. Then hand it to whoever asked and say nothing while they run it — their questions are your revision list.