Most SOPs fail for a boring reason: they describe the task the way an expert remembers it, not the way a newcomer experiences it. Steps get skipped because they feel obvious. Screens get described vaguely. Nobody knows who owns the document, so it rots.
This guide walks through how to write an SOP that a new teammate can follow on their first day, with a worked example you can copy. If you want a head start, the free SOP template generator gives you the same structure as a form and exports it as Markdown, Word-ready HTML, or PDF.
What an SOP is (and what it isn't)
A standard operating procedure is a written, step-by-step description of how to complete one recurring task the same way every time. It is narrower than a policy and more specific than a process map.
| Document | Answers | Example |
|---|---|---|
| Policy | What are the rules? | Refunds over $500 need a manager's approval. |
| Process | What happens, in which order, across teams? | Refund request → triage → approval → payout → follow-up. |
| SOP | Exactly how do I do this one task? | How to issue a partial refund in the billing dashboard. |
| Checklist | Did I remember everything? | Pre-launch QA checklist. |
If your draft starts arguing about whether something should happen, it is turning into a policy. If it spans five teams, it is a process. Keep the SOP to the hands-on part one person performs.
How to write an SOP in 7 steps
1. Pick one task with one finish line
Good SOP titles are verb + object: “Issue a partial refund,” “Offboard a contractor,” “Rotate the on-call schedule.” If you can't name the single outcome, split the document. “Billing SOP” is a folder, not an SOP.
2. Write the purpose and scope in two sentences
Purpose says why the procedure exists. Scope says who it applies to and when it does not apply. The “does not apply” part prevents most misuse: “This SOP covers refunds for card payments. Invoice-paid accounts follow the finance team's procedure.”
3. List roles and prerequisites before the steps
Readers should know before step 1 whether they're allowed to do this and whether they have what they need. List the role that performs the task, who approves, and any access, tools, or information required. Discovering at step 6 that you need admin rights is how SOPs lose trust.
4. Walk the task and capture it as you go
Don't write from memory. Do the task once, live, and capture every click and field as it happens. Experts skip steps they no longer notice, like selecting the right workspace or switching a toggle that defaults to the wrong value.
For software tasks, recording your screen while you do it is the fastest way to catch those steps. Steperly turns one screen recording into a step-by-step guide with a screenshot per step, which you then edit instead of writing from scratch.
5. Write each step as a single, testable action
This is where most SOPs are won or lost. Each step should start with a verb, name the exact place in the UI, and end with what the reader should see. Compare:
- Before: “Process the refund in Stripe and update the ticket.”
- After: “In the payment's detail page, click Refund. Enter the partial amount, choose the reason Requested by customer, and click Refund. The payment status changes to Partially refunded.”
The rewrite is longer, but nobody has to guess. Keep one action per step; if a step contains “and then,” consider splitting it. Add a screenshot when the click target is small or easy to confuse. The free screenshot annotator adds numbered markers and arrows so the image matches the step number.
6. Add exceptions and what to do when it goes wrong
A short “Notes and exceptions” section handles the 10% of cases the main path doesn't cover: what to do if a button is greyed out, if the amount exceeds an approval limit, or if the customer paid by invoice. Say who to escalate to by role, not by name, so the SOP survives team changes.
7. Test it, then set an owner and a review date
Hand the draft to someone who has never done the task. Watch them follow it without helping. Every question they ask and every pause is a missing or unclear line. Fix those, then record the owner, version, effective date, and approver at the top.
A worked example SOP
Here's a complete, realistic SOP for a support team. It uses the same sections the template generator produces.
- Roles: Support agent performs the refund. Support lead approves anything outside scope.
- Before you start: Billing dashboard access with the Refunds permission; the customer's account email; the ticket ID.
- Open the billing dashboard and search for the customer's account email. The customer's profile opens.
- Under Payments, open the payment that matches the ticket's invoice date. Confirm the amount and last four card digits with the ticket.
- Click Refund. In Amount, enter the partial refund. Do not use the default full amount.
- Set Reason to Requested by customer and paste the ticket ID into the internal note.
- Click Refund. The payment shows Partially refunded with today's date.
- In the ticket, add the macro Refund issued, fill in the amount, and set status to Pending customer.
- Exception: If Refund is greyed out, the payment is still pending. Wait until it settles and set a reminder on the ticket.
- Exception: If the customer disputes the charge with their bank, stop and escalate to the support lead. Do not refund a disputed payment.
Notice what makes it work: every step names a screen and a field, every step ends with something you can verify, and the scope tells you when to stop reading and escalate.
SOP format: which sections to include
Readers scan SOPs under time pressure, so a fixed order matters more than a perfect order. Use the same skeleton for every SOP in your team:
- Header: title, owner or department, version, effective date, approver.
- Purpose: one or two sentences on why it exists.
- Scope: who it applies to and when it does not.
- Roles and responsibilities: who does, who approves, who to escalate to.
- Before you start: access, tools, and information needed.
- Steps: numbered, one action each, with the expected result.
- Notes and exceptions: edge cases and escalation paths.
- Revision history: what changed, when, and by whom.
The SOP template generator follows this order for the header through exceptions, so you don't have to rebuild the skeleton each time. If the task happens in software, the AI SOP generator builds a visual SOP from a workflow recording, with steps and screenshots you edit.
Common SOP mistakes (and quick fixes)
| Mistake | Fix |
|---|---|
| Steps written from memory skip “obvious” clicks | Write while doing the task, or record it and edit the captured steps |
| “Update the record” with no location | Name the screen, the field, and the value |
| No expected result | End each step with what the reader should see |
| Names instead of roles (“ask Priya”) | Use roles; people change teams |
| Screenshots with no markers | Number the click target to match the step number |
| No owner or review date | Assign one owner and review after any UI or policy change |
When a written SOP isn't enough
Text SOPs work well for decisions and checks. For software tasks with a lot of clicking, people often learn faster by watching or trying. That's the case for pairing the written SOP with visuals rather than replacing it.
Steperly is built for this: one recording produces a step-by-step guide with screenshots, a walkthrough video with AI voiceover, and an interactive demo, all from the same source. You can publish them together in a branded help center or embed them where your team works. For internal teams, see how this applies to employee training documentation.
Whatever format you use, the rules above don't change: one task, verb-first steps, a visible result for each step, and an owner who keeps it current.