How to write SOPs that people actually follow

Most SOPs are written once and ignored forever. They sit in a shared drive, growing stale, while the team keeps doing things the way they’ve always done them — slightly differently each time. The problem isn’t discipline. It’s that the SOPs were bad to begin with.

A good SOP doesn’t just list steps. It answers the questions people actually have when they’re doing the work: what triggers this process, who owns each step, what do I do when something goes wrong, and how do I know I’m done.

Why most SOPs fail

The typical SOP is written by someone who knows the process so well they skip the parts that aren’t obvious. They write “process the order” when what the reader needs is “open the Orders tab in Shopify, click the order number, verify the shipping address matches the billing address, then click Fulfill.”

The other failure mode is the opposite: SOPs that are so detailed they read like legal contracts. Nobody is going to consult a 12-page document to onboard a new team member. If it takes longer to read the SOP than to do the task, you’ve lost.

The sweet spot is somewhere in between — specific enough that someone new can follow it without asking questions, short enough that someone experienced can scan it as a checklist.

The five parts of an SOP that works

Every SOP worth reading has five sections. Skip any of them and you’ll get questions.

1. Purpose. One sentence. Why does this process exist? “To ensure every new customer gets a working account within 24 hours of signing.” If you can’t write this sentence, you’re not ready to write the SOP.
2. Scope. Who does this apply to? When does it trigger? This saves people from reading an entire SOP only to realize it’s not for them.
3. Steps. Numbered, action-oriented, starting with a verb. “Open,” “Click,” “Send,” “Verify.” Each step should be one action. If a step has the word “and” in it, split it into two steps.
4. Roles. Who does what. “CS sends the welcome email. Engineering creates the workspace.” If everyone is responsible, nobody is responsible.
5. Edge cases and notes. The stuff that bites you. What happens if the customer doesn’t respond? What if the system is down? Put these at the end so they don’t clutter the main flow.

Write it the way you’d explain it to a new hire

Here’s a useful test: imagine someone starts on your team on Monday. They’re smart but know nothing about your systems. Could they follow this SOP and get the right result without asking you anything?

If the answer is no, you’re relying on tribal knowledge. That works until someone goes on vacation, or leaves, or you hire three people at once and don’t have time to hand-hold each one.

The fastest way to write an SOP is to actually do the process and narrate what you’re doing. Write down each action as you take it. Or better yet — say it out loud and let a tool structure it for you.

Keep it alive

An SOP is only useful if it reflects reality. The moment your process changes and the SOP doesn’t, you’ve created a trap. Someone will follow the old steps, get a wrong result, and never trust documentation again.

The fix is simple: make updating the SOP part of changing the process. If you change how you onboard customers, the SOP update is part of that change — not a follow-up task that never happens.

Tools like Viking Docs help here because the docs live in the same place where you edit them. There’s no separate publish step, no file to update in a shared drive. Edit the SOP, and it’s live.

Start with the process you explain most often

You don’t need to document everything at once. Start with the one process you keep explaining to people. The one where someone pings you on Slack every week asking “how do I do X?”

That’s your first SOP. Write it once, share the link, and stop being the bottleneck.

Need a starting point? Try our free SOP Generator — describe your process and get a structured SOP in seconds.