Structuring an SOP people actually follow

A procedure gets followed when it can be held open while the task is being done. That means: a title that names the trigger rather than the topic, one named owner, the conditions that must be true before you start, numbered steps of one action each, the decision points written as if/then, what to do when it fails, a definition of finished, and a date. Procedures that go unread are almost always written as documents — prose, background, context, rationale — by someone recalling the task from memory rather than performing it.

Why the document gets ignored

Three failures account for most of it. The procedure is written in the past tense by a person who already knows the job, so it skips the steps that are obvious to them and invisible to everyone else. It lives somewhere nobody is when the work happens. And it has no owner, so the first time it is wrong, nobody fixes it and everybody quietly stops trusting it.

None of those are writing problems. They are structure and placement problems.

The nine parts

The title is a trigger, not a topic

"Invoicing" is a topic. "When a project is marked complete: raise the final invoice" is a trigger. Someone scanning a list of procedures is looking for their situation, not your taxonomy. Titles that start with "when" or "how to" are found; titles that are nouns are not.

One owner, named by role

Not a team. One role — "Studio manager" — who is responsible for the procedure being correct. Ownership by committee produces documents that rot politely.

Prerequisites

What must exist before step one: access, permissions, files, approvals, a piece of information you need to have to hand. This is the section that stops someone getting to step 4 and discovering they need an admin account they will wait two days for.

Numbered steps, one action each

Imperative mood, present tense, one verb, one actor. "Open the invoicing tool" is a step. "Open the invoicing tool, check the PO number matches, and send" is three steps wearing a coat. The reason for the split is not tidiness — it is that a person interrupted at step 6 can come back and resume, and a person who made a mistake can be asked which step they were on.

Decisions as if/then

Real work branches. Write branches explicitly: "If the client has a PO number on file, use it. If not, request one before sending, and hold the invoice." Prose that says "generally we use the PO number where applicable" pushes the decision back onto the reader, who will make it differently each time.

Screens and values, exactly

Name the button. Name the field. Give the value. "Set Payment terms to Net 30" is followable; "set the usual terms" is not. Where the exact value depends on something, say what it depends on in the same sentence.

Failure and escalation

What the reader does when the step doesn't work: who to contact, what to include, and — this is the part usually missing — whether to stop or carry on. A procedure without an escalation path becomes a procedure people abandon silently the first time it breaks.

Definition of done

An observable end state. "The invoice appears in the Sent folder and the project row shows Invoiced." Not "the invoice is sent", which is what the person thought they had done when they left the browser tab open.

Date and owner review

Last reviewed date, visible at the top. An undated procedure is one nobody can tell is stale, so everyone treats it as stale.

Write it while doing the task

The single change that improves a procedure most is writing it during a real run, not afterwards. Do the task, and record each action as you take it, including the ones that feel too obvious to write down — those are exactly the steps a new person stalls on.

Then have someone who has never done the job follow it, unaided, while you watch and say nothing. Every question they ask is a defect. Fix the document, not the person. Two runs of this usually gets a procedure from "roughly right" to "usable", and it is faster than three rounds of review comments.

For procedures that need to exist in more than one place, we sell an SOP Writing System: the section structure above as a Notion database with a reusable page template, plus the same thing as a Google Docs file for teams that don't use Notion, and a short reviewer's checklist. It is a writing structure, not compliance documentation, and it carries no industry-specific requirements.

How big should a step be

A workable rule: a step is one action, by one person, in one place, that another person could verify happened.

Split when a step contains an "and", when it moves to a different tool, when it hands over to a different person, or when it contains a decision. Merge when you find yourself writing "click Save" as its own line. Between roughly five and fifteen steps is a comfortable length; beyond twenty-five, the procedure is usually two procedures, and the seam is normally where the work changes hands.

When an SOP is the wrong tool

"Document everything" is bad advice, and the folder of eighty procedures that nobody has opened since the quarter they were written is the usual result.

Skip the procedure when the work is judgement rather than sequence. You cannot write steps for pricing a complicated job or handling an angry client; what helps there is a set of criteria, worked examples, and a named person to ask. Writing it as numbered steps produces something either so vague it is useless or so rigid it is wrong.

Skip it when the task runs less often than the procedure would need review — an annual task documented in January is fiction by December, and re-deriving it from scratch costs about the same as re-reading a stale document and trusting it.

Skip it when a template or a form would do the job better. If the reason people get it wrong is that they forget fields, a form with required fields fixes it permanently and a procedure does not.

And before writing any of them: if a step exists only because a tool is configured badly, change the configuration. A procedure that documents a workaround makes the workaround permanent.

Keeping them from rotting

Review by trigger, not by calendar. Tie each procedure to the events that would invalidate it — the tool changes, the person changes, the price changes, the step failed — and let the owner update it then. A blanket "review everything every six months" produces a review that consists of opening the document and changing the date.

One more habit worth the effort: when someone follows a procedure and hits a problem, they edit the document in that moment, or they add a comment to the step. Not later, not in a ticket. The half-life of the correction is about as long as the annoyance.

Related

• Prompts that survive a model update
• Client tracking: when a spreadsheet is enough
• Procedures, runbooks and decks in the shop: Documents & Decks