A standard operating procedure is a set of steps that turns a task you do every week into something a new person can do on their first try. It does not have to be a binder of rules. A useful SOP produces one thing: a repeatable sequence where each step names who does it, what tool or record they use, and when the step counts as done. This guide walks through writing one from scratch, then shows the shape it takes in a retail store, on a factory floor, and in a customer service team. You can build it directly in the standard operating procedure template and edit the steps in your browser.
What a standard operating procedure should achieve
An SOP is not a policy document and not a to-do list. A policy says what is allowed; a to-do list says what you hope to get to; an SOP says how the work actually moves from one person to the next. A workable SOP should answer four questions for every single step: who does it, what they use, what they do, and how you know it is finished.
A useful SOP produces five outcomes:
- every step has one named owner or role, never "someone";
- every step names the tool or record it uses or produces;
- every step has a done-when condition you can check, not a feeling;
- the sequence matches the order people actually work in, not the order that looks tidy on paper;
- the SOP survives staff changes because owners are roles, not names.
Don't treat every procedure as one size. Opening a store is a daily handover, a machine pre-start is a safety sequence, and complaint handling is a chain of handoffs with a compliance-sensitive step in the middle. Start from the same backbone — step, owner, tool, done-when — and branch only where the work genuinely differs.
How to write a standard operating procedure
1. Pick a procedure people repeat
Choose something that happens regularly and costs time when it goes wrong: opening the store, starting a machine, onboarding a client, handling a complaint. If the task only happens once a year, an SOP is still worth it — that is exactly when nobody remembers the details. But the best first SOP is the one you repeat weekly.
2. List the steps in order, one action each
Write the steps in the order they happen, and keep each step to a single action. "Unlock the door and disarm the alarm" is one step; "open the store" is not a step, it is the whole procedure. If a step needs "and then," it is probably two steps.
3. Assign an owner to every step
Every step needs an owner or role. The moment a step says "someone should check the till," it stops getting done. Owners work best as roles rather than names — "opening manager" and "cashier" survive the person who holds the job today.
4. Name the tool or record
Each step should point at the thing that makes it concrete: a POS terminal, an opening checklist, a handover log, a ticket system. Naming the tool does two jobs. It tells the person where to look, and it creates the record that proves the step happened.
5. Write the done-when condition
This is the part most SOPs skip, and it is the part that matters most. "Check the machine" is a wish; "levels within spec" is a check. A done-when condition is verifiable — a number, a signed log, or a confirmed status — so the next person in the chain knows the step is actually complete.
6. Review it with the people who do the work
An SOP written from a desk misses the exceptions the operator handles every day. Sit with the person who actually opens the store, runs the machine, or answers the ticket, and walk the list together. Cut steps that add no check, a handoff, or a record. What is left is a procedure people will actually follow.
Retail store opening example
A store opening is a good first SOP because it repeats every day and the consequences of a missed step show up immediately — an alarm that does not disarm, a till that does not match, doors that open late.
The opening sequence usually runs six steps. First, unlock the door and disarm the alarm, owned by the opening manager, done when the alarm is off. Second, count the opening float and log it — the cashier uses the POS and a float sheet, and the step is done when the float matches the log. Third, walk the floor for lights, stock, and safety, owned by the shift lead against an opening checklist. Fourth, turn on the register and test the scanner, done when the scanner and receipt printer work. Fifth, read last night's handover notes, done when every open item has an owner. Sixth, unlock the entrance and open to customers, done when the doors open at the posted time.
The mistake that costs the most here is leaving a step without an owner. "Someone checks the till" becomes nobody checks the till, and the shortage is discovered an hour later with no way to trace when it happened.
Factory machine pre-start example
A machine pre-start inspection is a different animal: it is a safety sequence, and each check exists because skipping it can hurt someone. The order matters more, and the done-when conditions need to be pass/fail.
The sequence starts with clearing tools and debris from the machine zone, done when the zone is clear of hazards. Then confirm guards and safety sensors are in place — the operator checks the guard checklist, done when all guards are closed and locked. Check oil, coolant, and power levels, owned by the maintenance tech against the gauges, done when levels are within spec. Press and reset the emergency stop, done when it trips and resets. Run a no-load test cycle, done when there is no unusual noise or vibration. Finally, record the check and sign the pre-start log, done when the log is signed and filed.
Here the done-when column does real work: "levels within spec" and "e-stop trips and resets" are checks someone can fail, which is the point. A vague "check the machine" would let a tired operator sign off without actually looking. For procedures that branch — if a level is out of spec, who do you call — that fork belongs in a flowchart template, not crammed into the linear list.
Customer service complaint example
Complaint handling is a chain of handoffs, and that changes what the owner column means. It is less about one person doing six steps and more about six steps moving the case from one owner to the next with a record at each point.
The flow runs from listening and restating the issue, through pulling the order or account history from the CRM, to diagnosing the cause and the fix path. Then a senior agent proposes a fix, refund, or replacement against the refund policy — this is the compliance-sensitive step, which is why it has a senior owner. The agent applies the agreed action and confirms it, then closes the ticket with a follow-up scheduled. Each step's done-when condition is the handoff: "issue understood, logged," "customer agrees to the fix," "fix applied, customer notified."
The SOP pattern that matters most here is accountability. When a refund needs approval, the owner column is what prevents a junior agent from improvising a policy decision. If your complaint process forks by severity or refund amount, model those branches with a process map template rather than overloading one list.
Common SOP mistakes
Steps with no owner
"Someone should check the till" never gets done. Give every step a role, and make sure the role maps to a real person or a real shift, not a department name nobody answers to.
No done-when condition
Without a completion signal, every step is optional. "Check the machine" is a wish; "levels within spec" is a check. The done-when column is what makes an SOP executable instead of aspirational.
Branches stuffed into one linear list
A procedure that forks — "if the level is out of spec, call maintenance" — reads badly as a single list. Keep the linear SOP for fixed sequences and move the branches to a flowchart, so the person in the moment can see both paths without hunting.
Writing it without the people who do the work
The operator who has run the machine for years knows the exceptions that never make it into a desk-written SOP. Review the list with them, and you will cut steps that add nothing and add the checks that actually prevent the failures.
Steps that exist out of habit
Some steps survive because they were always there, not because they add a check, a handoff, or a record. If a step does none of those three things, cut it. A shorter SOP is a more followed SOP.
Keep the SOP useful over time
An SOP is a living document, not a plaque. Review it when the work changes — a new register, a new machine, a new refund policy — and update the owner, tool, or done-when tags in place. Keep the short version in the same file as the long one, and let the people who do the work own the edits; they are the ones who notice first when a step stops matching reality.
Start with the standard operating procedure template, replace the sample steps with your own, and copy a row whenever you need one more step. When the procedure forks, reach for the flowchart template; when you need to assign steps across roles, the swimlane diagram template does that job.
