Most standard operating procedures (SOPs) get written once, saved in a shared drive, and never opened again. If your team keeps asking the same questions or making the same mistakes, the problem usually isn’t the people. It’s the document. This guide shows you how to write an SOP that people actually use, based on what separates a living procedure from a dead one.
What an SOP is really for
An SOP exists to make a task produce the same result no matter who performs it. That is its entire job. It is not a policy statement, not a training manual, and not a legal disclaimer. When you mix those purposes together, the document gets long, and long documents get ignored.
The nature of a good SOP is narrow scope and high clarity. One task, one document. “Onboard a new client” is a scope. “Everything the operations team does” is not.
Structure that works
After writing and revising many procedures, a reliable pattern emerges. Keep these sections and drop the rest:
- Purpose: one sentence on what this achieves and why it matters.
- When to use it: the trigger that starts the procedure.
- Who does it: the role, not a person’s name.
- Steps: numbered, in order, one action per step.
- Done means: how the reader knows the task is complete.
Write steps as actions, not descriptions
Start each step with a verb: “Open,” “Send,” “Check,” “Confirm.” Compare these two lines. “The invoice should be reviewed for accuracy” tells the reader nothing about what to look at. “Check that the invoice total matches the signed quote” tells them exactly what to do and what correct looks like.
Show what the outcome looks like
Where a step has a right and wrong result, describe both. Readers learn faster from a concrete example of a completed field than from an abstract instruction.
A real scenario
A small support team kept escalating refund requests to the manager because nobody was sure who could approve what. Their first SOP was three pages of policy language. It didn’t help. The rewrite was one page: trigger (customer asks for a refund), a decision line (under a set amount, agent approves; over it, manager approves), the exact system steps, and what to write in the customer note. Escalations for routine refunds dropped noticeably within two weeks, because the answer now lived where the work happened instead of in the manager’s head.
Pros and limits
A strong SOP reduces errors, speeds up onboarding, and frees senior people from repeat questions. The trade-off is upkeep. An SOP that describes a process that has since changed is worse than none, because it teaches the wrong thing with authority. Treat every SOP as something that needs an owner and a review date, or don’t write it.
Common mistakes and how to fix them
- Too long. If it runs past two pages, you probably merged several tasks. Split it.
- Written for experts. The reader is often the newest person. Remove assumed knowledge and undefined jargon.
- No owner. Assign one role responsible for keeping it current, and put a last-reviewed date at the top.
- Vague verbs. “Handle,” “manage,” and “process” hide the actual action. Name the click, the field, the message.
- Never tested. Give it to someone who has never done the task and watch them try. Every place they hesitate is a gap.
Action checklist
- Pick one task with a clear start and end.
- Write the purpose in a single sentence.
- List steps as verb-first actions, one action each.
- Add a “done means” line so completion is unambiguous.
- Assign an owner and a review date.
- Have a newcomer follow it and fix wherever they stall.
Conclusion and next step
A useful SOP is short, specific, tested, and owned. Your next step is small: choose the one task your team asks about most this week and write a single-page procedure for it. Then hand it to someone else and let their questions guide the edits.
FAQ
How long should an SOP be?
As short as the task allows, ideally one to two pages. Length is a symptom of scope. If it grows, you are usually documenting more than one procedure and should split it.
Should I use text, a flowchart, or a video?
Text works for most step-based tasks and is easiest to update. Use a flowchart when there are several decision branches. Video helps for physical or software actions that are hard to describe in words, but it is slow to revise, so pair it with a short written version.
Who should write the SOP?
The person who does the task well should draft the steps, since they know the real workflow. Someone less familiar should then test it, because they expose the assumptions the expert can’t see.
How often should SOPs be reviewed?
Review on a set schedule and whenever the underlying process, tool, or rule changes. A last-reviewed date at the top makes stale documents easy to spot.