How to Write an SOP That People Actually Follow

Picture the new hire on their third day. A customer refund needs processing, the person who normally handles it is out, and somebody says, "There's an SOP for that." So they open it. It's nine pages. The first two are a revision history table and a glossary. By page four they've closed the doc and pinged the team channel: "uh, how do I actually do a refund?"

That SOP exists. It's "done." Nobody follows it.

This is the gap most teams miss. Writing a standard operating procedure and writing one people actually use are two different jobs. The first is about coverage. The second is about getting a real person through a real task without friction. If you only know how to write an SOP that satisfies a compliance checkbox, you'll keep producing documents that quietly rot in a shared drive. Let's fix that.

Why most SOPs get ignored

We've read a lot of these. The failures rhyme.

They're written for the wrong reader. Too many SOPs are written to impress an auditor or a manager, not to help the tired person doing the task. So they're padded with formal language, background nobody needs, and "context" that buries the one instruction that matters.

They describe instead of show. "Navigate to the settings panel and locate the configuration option." Which settings panel? There are four. A screenshot would have answered that in half a second.

They go stale and nobody notices. The button moves. The vendor changes their UI. A step that used to work now sends people in a circle. The doc says one thing, reality says another, and people learn to trust the doc less every time.

You can't find them. An SOP buried three folders deep, named "Process_v2_FINAL_updated.docx," might as well not exist. If finding it takes longer than asking a coworker, people ask the coworker.

How to write an SOP, step by step

Here's how to write an SOP that survives contact with a real user. Five moves.

1. Pin down one task, one trigger, one reader

Before you write a word, answer three questions. What single task does this cover? What event kicks it off (a ticket comes in, a deal closes, it's the first of the month)? And who is doing it, on what bad day? "A support agent who has never done this before, while three other tickets are waiting." Write for that person. Everything gets sharper.

If you can't describe the task in one sentence, it's probably two SOPs.

2. Write the steps as actions, in order

Each step starts with a verb. "Open," "click," "select," "confirm." One action per step. If a step has an "and" in it, consider splitting it. The reader should be able to do a step, look up, and find their place again instantly.

3. Mark the decision points

Real work has forks. "If the refund is over $500, get manager approval. Otherwise, continue." Call these out plainly. Most confusion in an SOP lives at the moment someone has to decide something and the doc stays silent.

4. Show the screen

For anything happening in software, a picture beats a paragraph. Capture the actual screen, with the button circled. This is the step most teams skip because grabbing, cropping, annotating, and re-grabbing screenshots every time the UI shifts is tedious. It's also where a tool like WriteHow earns its keep: you record yourself doing the task once, and it turns the recording into ordered steps with screenshots and annotations already in place. The manual screenshot grind is the part that quietly kills documentation, so removing it matters more than it sounds.

5. Test it on someone who's never done the task

Hand the draft to a person who doesn't know the process. Watch them try. Don't help. Every place they hesitate is a place your SOP is broken. This single test catches more problems than any amount of re-reading your own work, because you can't see your own blind spots.

A copy-paste SOP template

Steal this. Fill in the brackets, delete what you don't need, and keep it short. It works in a doc, a wiki, or a help center article.

Notice what's not in there: no glossary, no five-paragraph intro, no revision-history table eating the top of the page. Put the work first. Put the housekeeping at the bottom where it belongs.

Make it followable, not just complete

Completeness and followability pull in opposite directions, and followability should usually win. A few rules we'd stand behind.

Front-load the common path. Ninety percent of the time, the task is the same. Write that path cleanly, top to bottom. Push the rare edge cases into an "if something goes wrong" section or a linked doc. Don't make everyone wade through the exception that happens twice a year.

Use the reader's words, not the system's. If your team calls it the "refund button," don't write "the reimbursement action control." Match how people actually talk.

One screenshot is worth a paragraph of directions. Especially for "where do I click" moments. And if the screenshot has the right area marked, the reader never has to hunt. The catch is keeping those images current, which is exactly why so many SOPs end up with screenshots from two redesigns ago.

Keep sentences short. An SOP is read by someone in a hurry, often mid-task. Long sentences make them re-read. Re-reading is friction. Friction is when they give up and ask a coworker instead.

Keep it from going stale

The best-written SOP in the world is worthless six months later if the process changed and the doc didn't. This is where almost everyone drops the ball. Writing it feels like the finish line. It's actually the start.

Three habits keep an SOP alive.

• Give it an owner. A role, not a volunteer. "The team lead for support owns the refund SOP." When ownership is everyone's, it's no one's.
• Set a review date. Put it in the doc and on a calendar. Quarterly is fine for stable processes. Tie it to events for volatile ones: "review whenever the billing tool ships an update."
• Make updating cheap. If fixing one wrong screenshot means re-recording and re-annotating everything by hand, it won't happen. The easier the edit, the more likely your docs stay true. This is the quiet reason teams let SOPs die: not laziness, just a high cost to keep them honest.

And measure the one thing that matters: are people following it? If the same question keeps landing in your team chat despite an SOP existing, the SOP isn't done. It's wrong, hidden, or stale. Go find out which.

Write for the tired reader on their third day. Show the screen. Mark the decisions. Give it an owner and a review date. Do that, and you'll have written an SOP people actually follow, which is the only kind worth writing.