How to Write a Standard Operating Procedure (SOP): Template + Examples
To write an SOP, define one specific outcome, watch someone actually perform the task, then document it in 7 parts: title and ID, purpose, scope, roles, numbered steps (one action per step, starting with a verb), exceptions, and a revision log. Test it on a person who has never done the task — if they can complete it without asking questions, the SOP works. Most usable SOPs are 1–3 pages and take 2–4 hours to write and test.
What is a standard operating procedure, exactly?
A standard operating procedure is a written, step-by-step instruction set that lets a qualified person complete a specific recurring task the same way every time, without relying on memory or tribal knowledge. It differs from a policy (which says what the rule is) and a process map (which shows how work flows between people): the SOP says exactly how one task is executed, by whom, in what order. Good SOPs share three properties. They are outcome-scoped — "Process a customer refund" is an SOP; "Handle customer service" is a manual. They are testable — a new hire can follow one and produce the correct result. And they are owned — one named role is responsible for keeping the document current. Companies typically write SOPs for tasks that repeat at least weekly, involve handoffs between people, carry compliance risk, or fail expensively when done from memory.
Standard Operating Procedure Template Pack & Workbook
- 3 fill-in SOP formats + worked example
- 10 ready-to-adapt SOP skeletons
- Training manual & new-hire plan templates
Why do SOPs matter for small businesses?
Because undocumented processes make the owner the bottleneck. In a small business, the operational knowledge usually lives in one or two heads; every vacation, sick day, resignation, or new hire turns that into a crisis. The measurable payoffs of writing things down:
- Faster onboarding. Teams with documented procedures routinely cut new-hire ramp time by 30–50%, because training becomes "follow the SOP with supervision" instead of shadowing for weeks.
- Fewer errors. One action per step with verification points catches the 3–5 predictable mistakes that generate most rework in any recurring task.
- Delegation becomes possible. You cannot hand off what only exists in your memory. An SOP is the transfer format.
- The business becomes sellable. Buyers and lenders discount businesses that stop working when the owner steps away; a documented operations binder is due-diligence gold.
The rule of thumb: if you have done a task more than 3 times and will do it 10 more, the 2–4 hours to document it pays back within a quarter.
What sections does every SOP need?
Use the same skeleton for every procedure so readers always know where to look. The 9-part structure below covers 95% of business SOPs; small internal tasks can drop the definitions and references sections.
| # | Section | What it contains | Typical length |
|---|---|---|---|
| 1 | Title + document ID | Task name, unique ID (e.g., FIN-004), version | 1 line |
| 2 | Purpose | Why this task exists, in one sentence | 1–2 sentences |
| 3 | Scope | What's covered and explicitly what's not | 2–4 sentences |
| 4 | Roles & responsibilities | Who performs, who approves, who to escalate to | Short table |
| 5 | Prerequisites | Tools, access, materials needed before step 1 | Bulleted list |
| 6 | Procedure | Numbered steps, one action each | 5–25 steps |
| 7 | Exceptions & troubleshooting | The 3–5 most common "what if" branches | Short table |
| 8 | Definitions/references | Jargon, linked documents, screenshots appendix | As needed |
| 9 | Revision history | Date, version, author, what changed | Table, 1 row per change |
The document ID and revision table look bureaucratic but earn their keep the first time two versions of a procedure circulate at once — which, in most teams, is within the first year.
How do you write the procedure steps themselves?
Five rules turn vague instructions into steps people can actually follow. First, start every step with an imperative verb: "Click," "Enter," "Verify," "Send" — never "The invoice should be checked." Second, one action per step. If a step contains the word "and," split it. Third, state the expected result where ambiguity is possible: "Click Export. A CSV downloads within 10 seconds." This is how the reader knows they are still on the rails. Fourth, name exact locations and values: the button label, the folder path, the dollar threshold — "the usual folder" documents nothing. Fifth, write decision points as if/then lines, not prose: "If the refund exceeds $200, stop and go to Section 7." Formatting matters as much as wording: number every step, bold the interface elements, and keep the whole procedure between 5 and 25 steps. Longer than 25? You have two SOPs pretending to be one — split them.
What does a real SOP example look like?
Here is a condensed example you can pattern-match against — a refund-processing SOP for a small e-commerce shop:
SOP FIN-004 — Process a Customer Refund (v1.2) Purpose: Issue refunds accurately within 1 business day of an approved request. Scope: Card and PayPal refunds up to $200. Excludes chargebacks (see FIN-006). Performed by: Customer Support Agent. Approver for exceptions: Store Manager. Prerequisites: Access to the payments dashboard and the refund log sheet. Procedure:
- Open the refund request email and verify the order number exists in the dashboard.
- Check the order date. If more than 30 days old, stop — escalate to Manager.
- Click Orders → order number → Refund.
- Enter the item amount only. Do not refund original shipping.
- Click Submit refund. Confirmation banner appears within 15 seconds.
- Reply to the customer using template R-2 ("Refund confirmed").
- Log the refund in the refund sheet: date, order #, amount, reason code. Exceptions: Amount over $200 → Manager approval required before step 3. Revision history: v1.2 — 2026-05-10 — raised limit from $150 to $200 (J.M.).
Notice what makes it work: 7 steps, every one starts with a verb, two stop-and-escalate lines, and an expected on-screen result where the reader might worry the system froze.
How do you test and roll out an SOP?
An untested SOP is a guess. The test is simple and brutal: hand the draft to someone who has never done the task and observe silently while they attempt it. Every question they ask is a defect in the document — fix the document, not the person. In practice, expect 5–10 revisions from the first observed run; a procedure usually stabilizes by the second or third test. Then roll out in this order:
- Approve and version it. Mark it v1.0, add the owner's name and a review date.
- Store it in one canonical location — a shared drive folder, wiki, or printed operations binder. Duplicate copies are how outdated versions escape.
- Announce the switch: from a set date, the SOP is the way the task is done, and deviations require telling the owner (that feedback is how the SOP improves).
- Schedule the review. Every SOP gets a review date — every 6 months for fast-changing tasks, 12 months for stable ones. An SOP with a 3-year-old revision date is read as fiction, and rightly so.
What are the biggest SOP mistakes to avoid?
Six failure modes account for nearly every dead SOP folder:
- Writing from memory instead of observation. Memory documents the idealized task; observation captures the 4 workarounds reality requires. Always watch a real run.
- Documenting everything at once. Teams that attempt "document all our processes" burn out by week 3. Write the 5 highest-frequency, highest-risk SOPs first; add 1–2 per month after.
- Prose paragraphs instead of numbered steps. A wall of text cannot be followed under time pressure. If it isn't numbered, it isn't a procedure.
- No owner, no review date. Documents without a named owner drift out of date within months and poison trust in the whole library.
- Wrong altitude. Steps like "handle the customer professionally" (too vague) or "move the mouse to the top left" (too granular) both fail. Write for a competent beginner.
- Hiding the exceptions. The 80% happy path is easy; the value is in the 20% — refund limits, error messages, escalation contacts. If the exceptions live only in someone's head, the SOP fails exactly when it's needed most.
Should you use a template or start from scratch?
Use a template — the structure of an SOP is a solved problem, and reinventing section headers is procrastination dressed as work. The 9-section skeleton above is deliberately boring because boring is what makes a library of 20 SOPs scannable. If you want the whole system ready to go, our Standard Operating Procedure Template Pack includes the full SOP template with all 9 sections pre-formatted, a one-page quick-task variant, a process-inventory worksheet for choosing which 5 SOPs to write first, a revision-log system, and filled example pages you can pattern-match — printable or usable digitally. It turns the 2–4 hour first SOP into closer to 1 hour, because you only write content, never structure. Whichever route you take, the sequence is the same: pick one weekly task, watch a real run, fill the skeleton, test it on a novice, and put a review date on it.
FAQ
How long should an SOP be?
1–3 pages for most business tasks, with 5–25 numbered steps. If you pass 25 steps, split the task into two SOPs with a handoff line ("Continue in SOP FIN-005"). Length itself isn't the goal — a novice completing the task without questions is. Screenshots go in an appendix so the step list stays scannable.
What's the difference between an SOP, a policy, and a work instruction?
A policy states the rule ("Refunds allowed within 30 days"). An SOP describes how a role executes a task end to end ("Process a customer refund"). A work instruction zooms into one step in machine-level detail. Small businesses usually need only two layers: a short policy sheet plus SOPs.
What software do you need to write SOPs?
None beyond a word processor. Start with a document template stored in one shared folder; a printed operations binder works fine for teams under 10. Dedicated SOP software ($20–$100+ per user/month) earns its cost only once you have 30+ living documents and need search, permissions, and read-tracking.
If you're documenting a freelance or service business, also grab the free Freelance Get-Paid Starter Kit — ready-made invoice and payment-follow-up templates, i.e., two SOPs you won't have to write.
3 ready-to-send client email scripts + red-flag checklist — see the RESELLOLABS quality before you buy anything.
Keep reading
What to Do When a Client Won't Pay: A Freelancer's Recovery Plan
A step-by-step recovery plan for unpaid invoices: the escalation timeline, email scripts, late fees, small claims, and when to walk away.
Food Truck Startup Costs: The Real Numbers (2026 Breakdown)
Food truck startup costs in 2026: truck prices, permits, equipment, and monthly overhead — with real ranges and a line-item breakdown.