How to create an SOP. One that people actually follow.

I'm Lauren Pearson, and most SOPs I am asked to review were written the same way: someone sat down, wrote out how the task is supposed to work from memory, and published it. Six months later nobody follows it, because it does not match what the task actually involves once you account for the two exceptions that come up every week. This guide is the method I use instead, built to produce a document people genuinely reach for rather than one that sits in a folder looking tidy.

The short answer. Write down what happens, not what should happen.

A usable SOP is written from direct observation of the task being done, not from how the task is meant to work in a policy document or a manager's mental model of it. That single distinction is the difference between an SOP that gets followed and one that gets quietly ignored the first time reality does not match the page. Watch or ask the person who actually does the task to walk you through it, including the small workarounds and judgement calls they make without thinking, and you already have most of the content the SOP needs.

Supered's 2026 State of Sales Enablement report, based on a survey of revenue teams, found that 89% had a defined, documented sales process, but only 36% saw it followed as designed, a 53-point gap between having a document and having a process people actually use. That gap is not unique to sales. It shows up wherever an SOP describes an idealised version of a task rather than the real one, and it is the single biggest reason SOP projects fail to change how work actually gets done.

Step by step. Six steps from blank page to usable SOP.

Step 1: pick one task and watch it happen

Choose a single, specific task, not a whole department's workflow. "How we process a subscription cancellation" is a task. "How customer success works" is not, and trying to document it as one SOP produces something too broad for anyone to actually use. Once you have the task, watch a competent person do it, or have them talk you through it in detail, rather than writing from memory or from a policy document that may never have matched reality in the first place.

Step 2: write the trigger and the outcome first

Before writing a single step, state plainly what starts the task, a specific email, a status change, a customer request, and what a correctly finished task looks like. This gives you a boundary. Every step you write afterwards has to earn its place between those two points, which stops the document drifting into unrelated detail that belongs in a different SOP entirely.

Step 3: choose a format that matches the task's complexity

A simple, linear task with no real decisions in it needs nothing more than a numbered checklist. A task with genuine either-or branches, "if the customer is on an annual plan, do X, if monthly, do Y", needs a decision tree or a clearly separated branching format, so the reader only has to read the path that applies to them rather than wading through every possible variation to find their own case.

Step 4: write the exceptions, not just the happy path

List the two or three most common ways the task diverges from the ideal case, and exactly what to do, including who to escalate to and how, when it does. This is the step most SOPs skip entirely, and it is the reason they fail the moment reality deviates from the page even slightly. A support agent following an SOP that only covers a customer who cancels for a normal reason has nothing to fall back on the moment a customer disputes a charge or asks for a partial refund instead, and ends up back where you started: asking a colleague what to do.

Step 5: test it on someone who did not write it

Hand the draft to someone unfamiliar with the task and have them follow it exactly as written, without helping them along or answering questions as they go. Every point where they pause, guess, or have to ask something marks a genuine gap in the document, not a gap in their competence. This step catches more problems in twenty minutes than another round of the author rereading their own draft ever will, because the author already knows what they meant.

Step 6: assign an owner and a review date

Name one person responsible for the SOP staying accurate, and set a fixed review date, six months for a task that changes often, twelve for one that rarely does. The owner is not expected to rewrite the document every cycle. Their job is to confirm it still matches how the task is genuinely being done, and to update it the moment the process changes rather than waiting for the scheduled check.

A worked example. Processing a subscription cancellation.

Here is how the method plays out on a real task I helped a small SaaS support team document. The trigger was a cancellation request arriving through the support inbox or the billing portal. The outcome was a cancelled subscription, a confirmation sent to the customer, and the reason logged in the CRM. Between those two points, the happy path was three steps: confirm the cancellation date against the billing cycle, action it in the billing system, send the confirmation email and log the reason.

The exceptions were where the first draft, written from the team lead's memory of "how it should work", fell apart under testing. It had nothing for a customer disputing a charge rather than simply cancelling, nothing for a customer on an annual plan asking about a partial refund, and nothing for a cancellation that arrived after the renewal had already processed. Watching an agent actually handle a week's worth of cancellation requests surfaced all three, because they came up repeatedly and the agent already had informal, undocumented answers for each one worked out through trial and error. Writing those answers into the SOP explicitly, with a clear line on when to escalate a dispute to a manager rather than resolve it directly, turned a document that covered maybe six in ten real cancellation requests into one that covered closer to all of them.

The judgement call worth naming is what we did not do: we did not try to eliminate the exceptions by changing the underlying policy so that every cancellation became a simple case. Some businesses reach for that instead of documenting the exceptions properly, and it usually just pushes the complexity somewhere else, into a stricter policy customers dislike, rather than removing it. Documenting the exception clearly was faster and left the actual customer policy untouched.

Common mistakes. Where SOPs stop being useful.

The most common mistake is writing from a manager's mental model rather than from direct observation of the task. It produces a document that reads well and matches almost nobody's actual day, and the gap only becomes visible the first time someone tries to follow it literally and cannot.

The second is covering only the happy path. A document with clean, linear steps and no exceptions looks finished and complete right up until the first real case that does not fit it arrives, at which point it is functionally useless for that situation and everyone reverts to asking a colleague, which is exactly the dependency the SOP was meant to remove.

The third is skipping the test step. A draft that has only ever been read by the person who wrote it, never followed by someone else, routinely contains gaps the author cannot see, because they already know the parts they left out. Twenty minutes of someone else following it literally catches what a dozen readthroughs by the author never will.

The fourth is publishing an SOP with no owner and no review date. It goes stale the first time the underlying process changes, whether that is a new tool, a new policy or a new team structure, and nobody notices until someone follows an outdated step and gets it wrong. A named owner and a scheduled check are what keep the document worth trusting six months on, not just on the day it was written.

The fifth is treating SOP creation as a one-off documentation project rather than an ongoing part of how the business runs. Businesses that get real value from SOPs build writing one into how a new process gets rolled out in the first place, rather than retrofitting documentation after a task has already been running informally for a year. If you are documenting your first handful of processes now, our SOP and process documentation work is built around exactly this method: watch the real task, write the real exceptions, test it before it goes live, and give it an owner who will actually keep it current.