How to write an SOP: a simple step by step guide
Short answer: Write an SOP by doing the task yourself (or watching someone who does it well) while taking notes on every step in order, including the decisions and exceptions, not just the happy path. Turn those notes into numbered steps written for the least experienced person who'll ever read it, add the materials or access needed before starting, have someone unfamiliar with the task try to follow it exactly as written, fix whatever confused them, and set a review date. Most owners skip the "have someone test it" step, and that's the one that catches the gaps you can't see because you already know the task too well.
You know a process needs to be written down and want the actual method, not just "write down the steps."
I'm Ranjit, and I run Blur Studio: 15+ years building software, 120 apps taken live, and clients who have gone on to raise $10M+. I build AI systems and processes that help businesses do a lot more with a lot less time. I also work differently from most of what else is out there, more on that further down this page. Say hello.
This page may contain affiliate links from which Blur Studio earns commissions.
What an SOP is, and isn't
A standard operating procedure is a specific, repeatable set of steps for doing one task the same way every time, written clearly enough that someone who's never done it before can follow it unsupervised. It's not a general policy ("we treat customers with respect"), not a vague goal ("improve response times"), and not a flowchart with no actual instructions inside each box. If a new hire can't physically do the task from your document alone, it's not an SOP yet, it's notes toward one. The difference from a policy or a checklist is covered in SOP vs work instruction vs policy.
Seven steps to write an SOP that actually gets followed
1. Pick one task, not a whole department
"How we do customer service" is too broad to document well. "How we respond to a one-star Google review" is a real SOP. Narrow the scope until it's a single task with a clear start and end point.
2. Do the task yourself, or watch the best person do it
Writing from memory misses steps you've internalized so deeply you don't notice doing them. Either perform the task yourself while narrating out loud, or sit with the person who does it best and have them talk through every decision as they go, including the ones that feel obvious to them.
3. Write down every step in order, including decisions
Capture not just the actions but the decision points: "if the customer paid by card, do X, if by invoice, do Y." A step that says "handle the payment" without explaining the branch forces every future reader to guess, which is exactly what an SOP is supposed to prevent.
4. List what's needed before starting
Note any logins, tools, templates or physical materials required, at the top of the document, not buried in step four. A new hire who discovers mid-task that they needed a password nobody gave them has already failed the SOP, through no fault of their own.
5. Write for the least experienced reader
Assume the reader has never done this task and doesn't know your internal shorthand. Spell out acronyms the first time, name specific buttons and screens rather than "go to the dashboard," and avoid jargon entirely, say "software subscription" instead of assuming everyone knows what a specific tool's interface looks like.
6. Test it on someone unfamiliar with the task
This is the step almost everyone skips, and it's the one that matters most. Hand the written SOP to someone who's never done the task and watch them try to follow it exactly as written, without helping. Every place they hesitate, ask a question, or do it wrong is a gap in the document, not a gap in them.
7. Set an owner and a review date
Every SOP needs one person responsible for keeping it current and a date to review it again, six months out is reasonable for most operational procedures. A procedure with no owner is the first thing that goes stale when a tool or price changes and nobody remembers to update the document.
A worked example: "how we respond to a one-star Google review"
Scope: just the response to a one-star review, not general reputation management. Materials needed: access to the Google Business Profile, the customer's order or job history if available. Steps: (1) Read the review fully before responding, note whether it names a specific staff member or issue. (2) Check internal records for that customer's order or appointment within 24 hours of the review. (3) Draft a response that acknowledges the specific complaint by name, never a generic "sorry to hear that," and offers a concrete next step (a call, a refund review, a redo). (4) Have a manager approve any response offering a refund or discount before posting. (5) Post the public response within one business day. (6) If the complaint reveals a real operational gap, log it for the next team meeting. Owner: the office manager. Review date: every six months, or immediately if your review response policy changes. Notice how much of the document is the decision branches and the approval step, not the posting itself, that's deliberate: the posting is the one part any staff member could already guess, the branches are where they'd actually get stuck without guidance. More samples for office, field and online work are in standard operating procedure examples.
Common mistakes that make an SOP useless
Beyond skipping the test step, a few patterns show up constantly in SOPs that look finished but fail the first time a new hire relies on them. Writing in passive, vague language ("the order is processed") instead of a specific action with a specific actor ("the dispatcher enters the order into the scheduling tool") leaves readers guessing who does what. Burying the one critical safety or compliance step in the middle of a long paragraph instead of calling it out separately, often the exact step someone skips under time pressure. Describing software screens from memory instead of checking them, so step 4 says "click Settings" when the button was renamed two updates ago. And writing an SOP once and never assigning anyone to actually read it, which means all the work above produces a document, not a trained employee.
Tools that save time
Trainual, a platform for writing up your company's processes, policies and training material in one place and assigning it to staff with completion tracking, is where a finished SOP like the one above can live once it's written, with quizzes to confirm new hires actually understood it rather than just skimmed it. It doesn't publish fixed pricing, quoting after a demo based on team size. Check current pricing here. Scribe, a browser and desktop tool that watches you perform a task and automatically generates a step-by-step guide with screenshots, speeds up step 3 above dramatically if the task happens on a screen, with a genuinely free Basic plan. Tango works the same way, a browser extension recording clicks into a numbered walkthrough, free for small teams and from $20 a user monthly beyond that. None of the three replace steps 6 and 7, the test and the review date, those still need a human. If you want a faster first draft, read how to write SOPs with AI.
How does Blur Studio approach SOP writing?
Writing good SOPs is almost entirely a method problem, not a software problem, the seven steps above work whether you type them into a free Google Doc or a paid platform. Where software genuinely changes the outcome is tracking whether people actually read and understood what you wrote, and that's worth paying for once you have more than a handful of procedures and staff. If you reach a point where your procedures need to connect to something else you run, like auto-assigning the right SOP based on a job type in your scheduling software, that's a custom conversation, and I'm happy to have it.
Questions people ask
How long should a single SOP be?
As long as it needs to be to cover every real decision point, and no longer. Most single-task SOPs run one to two pages. If yours is running past three or four pages, it's probably actually several SOPs that should be split apart.
Who should write the SOP, the owner or the person who does the task?
The person who actually does the task should either write it or be closely involved, since they know the real exceptions and shortcuts that an owner watching from a distance will miss. The owner's job is usually to review, test and approve it, not draft it from scratch alone.
What's the biggest mistake people make writing their first SOP?
Writing only the happy path and skipping the exceptions, like what to do when a customer doesn't respond, a part is out of stock, or a payment fails. The exceptions are usually where staff actually need guidance, since the straightforward case rarely confuses anyone.
Should I use a template or write from scratch?
A template is useful for consistency across many SOPs (same headings, same place for materials needed), but don't let a generic template substitute for actually testing the content on someone unfamiliar with the task, that step catches real problems no template can.
How do I keep SOPs from going out of date?
Assign one owner per SOP and a fixed review date, and build a habit of updating the document the same day any tool, price or policy it references changes, rather than batching updates. A six-month full review catches anything that slipped through in between. A 30 day plan for this is in managing SOPs for a small business.
Should every SOP include screenshots?
For anything done inside software, yes, a screenshot removes ambiguity that words alone can't, which is exactly why capture tools like Scribe and Tango generate them automatically. For physical tasks, a photo of the correct end result often works better than a screenshot ever could.