How to Write an SOP Step by Step (With Template)

I've written or reviewed a few hundred SOPs across client implementations, and the ones that actually get followed share one trait: they were written by the person who does the task, not the manager who remembers roughly how it used to work. If you want to know how to write an SOP step by step, the format matters less than that single decision. This article gives you the format anyway, because a bad format wastes the good input you collect.

Start with the outcome, not the steps

Before you write step one, write one sentence describing what "done" looks like. "Client onboarding is complete when the client has portal access, a signed contract on file, and their first project created with a kickoff date." That sentence becomes your test at the end — if someone follows your SOP and doesn't reach that outcome, the SOP is wrong, not the person.

Also capture the trigger: what starts this process. "A deal moves to Closed Won" or "a client requests a refund." Without a clear trigger, SOPs get half-followed because nobody's sure when to start.

The step-by-step format that holds up

Here's the structure I use for every SOP, regardless of complexity:

1. Title and outcome. One line each. "Client Onboarding SOP — outcome: client has portal access and a live project within 48 hours of contract signature."
2. Owner and last reviewed date. A name, not a department. Departments don't answer Slack messages.
3. Trigger. The event that starts the process.
4. Tools required. List every system touched, in the order they're touched.
5. Numbered steps. One action per step, written in the imperative: "Create a client record," not "A client record should be created."
6. Exceptions. The 2 to 4 situations that come up often enough to document — a client without a signed contract, a rush request, a refund.
7. Definition of done. Repeat the outcome sentence from step 1, as a checklist.

This isn't a rigid template you have to reproduce exactly — SOP software for small business covers a few reasonable variants — but skipping the owner, trigger, or exceptions sections is where most SOPs I've audited go wrong.

Writing individual steps well

Each step should pass three tests:

• One verb. "Send the welcome email and create the folder" is two steps wearing one number.
• Named responsible role. Not "someone checks the contract" — "the account manager checks the contract."
• No jargon without a definition. If your team says "spin up," write "create," unless every reader already knows the shorthand.

A step like "Create the client's project using the Standard Onboarding template and set the kickoff date to five business days out" is specific enough that two different people would do the same thing. "Set up the project" is not.

When to use screenshots instead of prose

If a step involves clicking something specific in a piece of software, describe it once in words and then show it. I've watched support tickets drop by roughly a third at one client after we added screenshots to their top five SOPs, purely because "click the gear icon" means nothing until you've seen the gear icon. Annotate the screenshot with an arrow or a number matching the step — don't make the reader hunt.

Keep screenshots current. A screenshot of a UI that changed six months ago is worse than no screenshot, because it actively misleads. This is the argument for document version control for teams — an SOP with dated version history tells you at a glance whether the screenshots can be trusted.

Exceptions: the section most SOPs skip

Every real process has edge cases that come up regularly enough to plan for. Onboarding without a signed contract yet. A refund request outside the standard window. A client who wants to skip a step in your normal flow. If you don't document these, whoever hits them first improvises, and that improvisation becomes the unwritten "actual" process — which is exactly the drift SOPs exist to prevent.

Three to five exceptions is normal. If you're documenting more than that, the process itself is probably too rigid for how the business actually works, and it's worth redesigning before you keep documenting exceptions to it.

A comparison of where teams write SOPs

Scribe and similar tools are genuinely good at auto-capturing screenshots as you click through a process — if that automatic capture is your priority, it's a fair choice. Where I steer clients toward a workspace like EvronStudio instead is when the SOP needs to sit next to the client record or task it governs, so the person doing the work finds it without leaving their task.

Get it reviewed before you publish it

Have someone who doesn't do the task follow your SOP literally, with no verbal help. Every place they hesitate, ask a question, or guess is a gap in the document, not a gap in their competence. This single step catches more problems than any amount of re-reading your own writing, because you already know what you meant.

Keep SOPs where the work happens

An SOP nobody can find gets ignored, then quietly rewritten from memory, then wrong. Store SOPs attached to the client, project, or task they govern rather than in a general wiki three clicks away — see how to organize company documents for the filing pattern I use across client implementations. If you're building a library of process documents specifically, internal wiki software for small teams and knowledge base software for small business cover the structural options in more depth.

Review cadence and ownership

Assign an owner and a review date to every SOP the day you publish it — not "eventually," now, while you remember why decisions were made. I use 6 months for anything touching a client-facing process and 12 months for internal admin processes with low risk. According to NIST's guidance on documentation practices, documentation that lacks a defined review cycle degrades faster than teams expect, because nobody owns catching the drift.

When a client onboarding SOP is the process in question, pair it with a client onboarding checklist for agencies — the SOP explains the reasoning, the checklist is what the account manager actually ticks through on the day.

The template, compressed

Outcome: one sentence. Owner: one name. Trigger: one event. Tools: a short list. Steps: numbered, one verb each, named responsible role, screenshots where visual. Exceptions: 3 to 5 real ones. Definition of done: repeat the outcome as a checklist. That's the whole format — the discipline is in keeping each section short enough that someone reads it instead of skimming past it.

I've seen teams try to make SOP writing a quarterly project and stall out because the scope felt enormous. It works better as a habit: write the SOP for a task the first time you notice two people doing it differently. That's usually the moment it's worth 20 minutes, and 20 minutes now is cheaper than a client complaint later. HBR's research on process documentation makes a similar point about capturing tacit knowledge before it walks out the door with an employee.