How to Write an SOP (Step by Step)

Last updated: January 2026

TL;DR

To write a standard operating procedure: pick one process and define its scope, record the process as it is actually performed, choose a format, draft each step with a screenshot, add roles and exceptions, review it with someone who has never done the task, then publish it where people look and set a review date.

A standard operating procedure is only useful if someone who has never done the task can follow it and get the same result every time. That single test, repeatability by a stranger, is what separates a real SOP from a page of notes, and it is the standard every step below is built to meet.

This guide walks through the seven steps in order, with a quotable rule, the concrete detail, and the common mistake for each, then shows one complete short SOP so you can see the shape of the finished thing. When you are ready to build, our free SOP templates give you a copyable format, and if you are choosing a tool, the SOP software guide and the broader comparison hub cover the field. If you first need to pin down terminology, see SOP vs work instructions vs process documentation.

The 7 steps to write an SOP

Each step opens with a rule you can quote, then the specific thing to do and the mistake to avoid. Do them in order: scope before capture, capture before drafting, review before you publish.

1. Pick one process and define its scope

“An SOP with a fuzzy scope is a document nobody trusts, because no one can tell whether it applies to them.”

Name the single process the SOP covers and write one sentence each for its purpose (why it exists), its trigger (what starts it), and its boundaries (where it stops and hands off). "Processing a customer refund" is a scope; "customer service" is a category that will sprawl into ten procedures. Nail the start and end points before you write a single step. They decide everything that goes in and stays out.

Common mistake: bundling several tasks under one title. If your steps branch into "if it's a chargeback, instead do…" more than once, you have two SOPs pretending to be one, so split them.

2. Observe and record the process as it is actually performed

“Document the process as it is really done, not as the org chart imagines it. The gap between the two is where every bad SOP is born.”

Watch the task happen, in full, at least once. The most reliable way is to record the process while someone performs it for real: every click, field, and decision is captured in order, with no reliance on memory. This is where a tool earns its place. Instead of interviewing the doer and reconstructing steps from notes, you record it once and read the actual sequence back off the capture. It surfaces the undocumented shortcuts and the "oh, and then I always check…" steps that verbal descriptions quietly drop.

Common mistake: writing the SOP from memory or from how it "should" work. Memory smooths over the fiddly real steps (the extra approval, the field that must be filled in a specific order) which are exactly the ones a new hire gets wrong.

3. Choose a format that matches how it will be read

“The best SOP format is the one your reader will actually open and follow: usually numbered steps with screenshots, not prose.”

For anything performed on a screen, numbered steps with a screenshot per step beat paragraphs every time; for physical or phone tasks, a clean numbered checklist is enough. Keep the header light: title, purpose, scope, roles, and metadata (owner, version, review date). You do not need to invent this from scratch; start from a proven layout. Our free SOP template gives you copyable Google Docs, Word, and markdown formats, so you fill in steps instead of designing a document. Grab a free SOP template here.

Common mistake: over-formatting. A twelve-field cover page and a formal tone make an SOP feel official and go unread. Optimise for the person following it under time pressure, not for how it looks in a binder.

4. Draft the steps with a screenshot for each

“One action per step, in the imperative: 'Click Refund', not 'The refund button should then be clicked'.”

Write each step as a single, concrete action starting with a verb, and pair it with the exact screen the reader will see at that moment. Screenshots do the heavy lifting: they remove ambiguity about which button, which field, which menu, and they cut reading time in half. Number the steps so people can refer to "step 4" out loud. Keep decisions explicit: if a step depends on a condition, state the condition first ("If the order is over $500, …").

Common mistake: cramming three actions into one step. "Open the order, verify the payment, and issue the refund" is three steps; collapsed into one, readers skip the middle action and the SOP silently fails.

5. Add roles, exceptions, and edge cases

“A procedure that only documents the happy path is a demo, not an SOP. The value lives in what to do when things go sideways.”

State who performs each step (or the whole procedure) so accountability is unambiguous, then handle the branches: what to do when the refund exceeds a threshold, when the payment method has expired, when a manager approval is required. List the two or three most common exceptions inline and link out to a separate SOP for anything genuinely complex. This is also where you note prerequisites: the access, permissions, or information the reader needs before step 1.

Common mistake: burying exceptions at the bottom in a wall of caveats. Put each exception next to the step it affects, so the reader meets it exactly when it becomes relevant.

6. Review it with someone who has never done the task

“An SOP is finished when a stranger can complete the task from it without asking a single question, not before.”

Hand the draft to someone who has never performed the procedure and watch them follow it, doing nothing they were not told to do. Every place they hesitate, guess, or ask a question is a defect in the SOP, not a failing of the reader. This test finds the assumed knowledge the author literally cannot see: the login they forgot to mention, the tab that must already be open. Fix each stumble, then, ideally, run it once more with a fresh person.

Common mistake: reviewing it only with experts. Someone who already knows the task will unconsciously fill the gaps and pronounce the SOP clear; the whole point is to catch what only a newcomer would trip over.

7. Publish where people look, and set a review date

“An SOP nobody can find is the same as an SOP that does not exist, and one with no review date is out of date the day the software changes.”

Put the finished procedure where the work happens: the knowledge base, wiki, or shared drive your team already opens daily, not a folder they have to remember exists. Give it an owner and a review date, and make sure it is searchable by the words people actually use. Guides that paste cleanly into Notion, Confluence, or Google Docs matter here; a procedure trapped as a link on a vendor's server is one your team will not reach for.

Common mistake: publishing and walking away. Without a named owner and a scheduled review, the first interface change turns your screenshots into lies, and readers quietly stop trusting the whole library.

A worked example: processing a customer refund

Here is a complete, real-world SOP written to the standard above: short, scoped, with exceptions attached to the steps they affect. Copy the shape, not the specifics.

SOP: Processing a customer refund

Owner: Support Team Lead

Version: 1.0 · Review by: July 2027

Role: Support agent

Purpose: Refund a customer correctly, on the original payment method, with an audit trail.

Scope: Applies to standard refund requests. Chargebacks and disputes follow a separate SOP.

  1. 1Open the order in the admin dashboard using the order ID from the customer's request.
  2. 2Confirm the order status is "Paid" or "Fulfilled". If it is "Refunded", stop, as it was already processed.Exception
  3. 3Check the refund amount against policy: full refunds within 30 days are pre-approved.
  4. 4If the amount is over $500, request manager approval in the #refunds channel before continuing.Exception
  5. 5Click Refund, enter the amount, and select the original payment method as the destination.
  6. 6Add an internal note with the reason code and your name, then confirm the refund.
  7. 7Send the customer the refund-confirmation email template, filling in the amount and expected timing (5–10 business days).
  8. 8Update the support ticket to "Resolved" and tag it "refund".

Note how short it is: eight steps, two exceptions attached where they matter, and metadata in the header. In a real SOP, steps 1, 5, and 6 would each carry a screenshot of the actual screen.

Writing SOPs with Dubble

The slowest part of writing an SOP is capturing the steps and screenshots, so Dubble does that part while you simply do the task once.

This is where step 2 and step 4 collapse into a single action. You turn on Dubble, perform the refund (or whatever the process is) exactly as you normally would, and it records every click and captures a screenshot of each screen. When you stop, you have a draft SOP: numbered steps, screenshots, and auto-written step titles you then edit down to the imperative, one-action-per-step standard above. You get a first draft from one recording instead of an interview and a manual write-up.

Honest scope: Dubble gets you a strong first draft fast, but it does not replace steps 1, 5, or 6; you still define the scope, add the exceptions, and run the newcomer review yourself. Its free plan includes unlimited guides, editing, and redaction (so you can blur customer data before sharing), and guides paste straight into Notion, Confluence, or Google Docs, so the SOP lives where your team already works rather than behind a link. If you would rather draft from a prompt than a recording, see the AI SOP generator.

Frequently asked questions

As short as it can be and still be followed by someone who has never done the task, usually one to two pages, or five to fifteen numbered steps. Length is a symptom, not a target: if an SOP runs past two pages it is often two procedures wearing one title, and splitting it makes both easier to follow and to maintain. Screenshots do not count against length; they replace paragraphs of description, so a heavily illustrated one-pager beats a dense wall of text every time.

The person who actually performs the task, reviewed by someone who does not. The doer knows the real steps, the shortcuts, and the exceptions that a manager writing from memory will miss; the reviewer catches the assumed knowledge the doer cannot see. The worst SOPs are written top-down by someone who last did the task two years ago. If you must centralise authoring, have the doer record the process and hand the raw capture to the writer, not a vague verbal description.

ISO 9001:2015 does not mandate a specific template or layout. It dropped the rigid six-procedure requirement and instead asks for 'documented information' that is controlled: identified (title, ID, version), reviewed and approved before use, and kept current. So there is no official ISO SOP format to copy. What auditors check is control: a version number, an owner, an approval date, and a review date on every procedure, plus a way to prove which revision was in force on a given day. Any clear format meets ISO 9001 as long as that document control wraps around it.

Set a review date on every SOP. Annually is the common default, but tie it to change, not just the calendar. Any procedure that touches software should be reviewed whenever the underlying tool's interface changes, because a screenshot that no longer matches the screen is worse than no screenshot. High-risk or regulated procedures warrant every six months. The practical rule: an SOP with no owner and no review date is already out of date, whatever the timestamp says.

An SOP describes a whole procedure end to end and the 'why' around it; a work instruction is the granular, step-by-step 'how' for a single task inside that procedure. In practice a refund SOP might reference three work instructions (issue the refund, notify the customer, log the case). The distinction matters mostly for larger or regulated documentation systems; small teams can keep both in one clear guide. We break the terminology down in full in our companion piece on SOPs versus work instructions versus process documentation.

Screenshots for anything performed on a screen: they cut ambiguity and reading time dramatically, and they are the single biggest reason a new hire can follow a software SOP without asking questions. The catch is maintenance: hand-cropped screenshots go stale the moment the app's interface changes, which is why many text-only SOPs exist at all. Capture tools that re-shoot a single step, or regenerate the whole guide from a fresh recording, remove that excuse. Text-only is genuinely fine for non-screen tasks like physical or phone-based procedures.

A title, a purpose (one line on why the procedure exists), a scope (when it applies and when it does not), the numbered steps themselves, roles (who does what), and metadata: an owner, a version, and a review date. Anything beyond that (approvals, linked policies, revision history) is added because your context needs it, not because a template said so. Start with that minimum and grow it only when a real gap appears.

AI helps most when it is grounded in what you actually did, not inventing steps from a prompt. A prompt-only draft reads plausibly but hallucinates button names and skips the exceptions that make an SOP useful, so it needs heavy fact-checking against the real process. The stronger pattern is to record the task once and let AI turn that capture into a first draft with the right screenshots and step titles, then you edit. We cover the prompt-only approach and its limits on our AI SOP generator page.

Keep reading

Skip the manual write-up

Dubble watches you do the task once and hands back a draft SOP with numbered steps and screenshots, free to start, paste anywhere, no export paywall. Do the process, get the procedure.

Add To Chrome - It's free→