A standard operating procedure is a written description of how a specific task is done, in enough detail that a competent person can follow it and get the same result every time. That is the whole idea, and it is a genuinely valuable one: an SOP is how an organisation stops depending on the fact that Priya knows how to do the month-end reconciliation. But SOPs also have a reputation, largely earned, for being long documents that were written once for an auditor, saved in a folder, and never read again by anybody doing the work.
This guide covers what an SOP actually is, how it differs from the four documents it gets confused with, when you need one, how to structure and write it, how version control should work, why SOPs fail, and the step most organisations miss: turning the procedure into the form that records it being done.
What Is an SOP?
An SOP is a documented set of instructions for carrying out a routine operation. The word "standard" is doing the important work: the point is not merely that the task is written down, but that it is done the same way by everyone, every time.
That standardisation buys four things. Consistency, so the output does not depend on who is on shift. Training, because a new person has something to learn from other than shadowing. Continuity, so the organisation survives someone leaving. And evidence, because in regulated work you frequently have to demonstrate not just that you did something correctly but that you have a defined method for doing it.
It is worth being honest about the flip side. SOPs impose rigidity, they go out of date, and they can substitute a document for actual competence. They are worth writing for tasks that are repeated, that matter when they go wrong, and where variation causes problems. They are not worth writing for everything, and an organisation with an SOP for every conceivable activity usually has an SOP library nobody consults.
SOP, Policy, Process, Work Instruction, Checklist
Five documents, endlessly conflated. The hierarchy is the clearest way to hold them apart.
A policy states the rule and the reason. "All expenses over £500 require director approval." It says what must be true, not how to achieve it.
A process maps the end-to-end flow, usually across several people or departments. Order to cash, hire to retire, incident to resolution. It answers "what happens, in what order, and who hands off to whom".
An SOP describes how one task within that process is actually performed, by one role. It answers "how do I do this".
A work instruction goes one level deeper, covering a single step in detail, often with screenshots or photographs. Not every SOP needs them; complicated or safety-critical steps do.
A checklist or form is the artefact produced when the procedure is executed. It records that the steps were done, by whom, and when.
The most common structural mistake is writing an SOP that is really a policy (all principle, no steps) or really a process (all handoffs, no instructions). If a reader cannot do the task after reading it, it is not an SOP.
When You Need One
Write an SOP when a task is repeated, when getting it wrong is costly (safety, money, compliance, reputation), when it is currently done differently by different people, when it is held in one person's head, or when a regulator, standard, or client contract requires documented procedures.
Do not write one for tasks that are genuinely one-off, for work where judgement is the point rather than consistency, or purely because a document seemed like the answer to a problem that was actually about training or staffing.
How to Structure One
A workable SOP has a predictable shape, and a header block that most people skip.
Title and document ID. A unique reference, so it can be cited and superseded cleanly.
Version number, effective date, and author. Without these you get three copies in circulation and no way to tell which is current.
Purpose. One or two sentences: what this achieves and why it matters. People follow instructions better when they know what the step is for, and it is the purpose that tells them what to do when reality does not match the page.
Scope. What this covers and, importantly, what it does not.
Roles and responsibilities. Who performs it, who approves, who is informed. Name roles, not individuals, so the document survives staff changes.
Prerequisites, materials, and access. Equipment, systems, permissions, and training needed before starting. Half of all failed procedures fail here.
Definitions. Only for genuinely ambiguous or specialist terms. A glossary of obvious words is padding.
The steps. Numbered, sequential, one action each.
Exceptions and what to do when it goes wrong. The most valuable section and the most commonly missing one. What are the known failure points, and who do you escalate to?
Records produced. What form, log, or entry results, and where it is stored. This is the link between the procedure and the evidence that it happened.
Review date and approver. A date by which someone must confirm it is still accurate.
Writing the Steps
One action per step. If a step contains "and then", split it.
Start with a verb. "Open the reconciliation report" beats "The reconciliation report should be opened", which is vague about who is doing it.
Write for the least experienced person who will legitimately do this job, not for the expert who wrote it. The author's curse is that everything obvious to them is invisible.
Be specific about values, names, and thresholds. "Wait until it cools" is untestable; "wait until it reads below 40 degrees" is.
Put the decision point where the decision happens. If step 6 depends on a condition, say so at step 6, not in a paragraph at the end.
Include what "done correctly" looks like. A short statement of the expected result lets someone check themselves.
Keep formatting boring and consistent. Numbered steps, short lines, warnings in a consistent place. Anything that has to be decoded gets skimmed.
Test it by having someone else follow it exactly. This is the single highest-return step in writing an SOP, and almost nobody does it. Watch, do not help, and note every place they hesitate.
Version Control and Review
An SOP that is out of date is worse than no SOP, because it carries authority it no longer deserves and it teaches people that the documents are not to be trusted.
Keep one authoritative copy in one place, and link to it rather than emailing copies, since every emailed copy is a future stale version. Number versions and record what changed, so someone can see whether the change matters to them. Set a review date, typically annually or whenever the underlying system changes, and put a named owner on it rather than a department. When a procedure changes, tell the people who perform it rather than assuming they will notice, and archive superseded versions rather than deleting them, because in regulated work you may need to show what the procedure was at a past date.
Why SOPs Fail
Written by someone who does not do the job. Produces a document that describes the official version rather than the real one.
Too long. A twenty-page SOP for a twenty-minute task will not be read. Length should track the task, not the importance of appearing thorough.
Written for the auditor. The tell is a document heavy on policy language and light on actual steps.
No exceptions section. Real work is full of edge cases, and a procedure that only covers the happy path gets abandoned the first time reality diverges.
Never tested. Nobody ever tried to follow it without the author present.
Impossible to find. An excellent SOP in a folder structure nobody can navigate is a nonexistent SOP. It should be findable from where the work happens.
No feedback route. The people doing the task find the errors first. If there is no easy way for them to say so, the document rots and they quietly go back to doing it their own way.
From Procedure to Record
Here is the step that most SOP projects stop just short of, and it is the one that makes the difference between a document and a working system.
An SOP describes how the task is done. It does not, by itself, produce any evidence that it was done, by whom, or with what result. That evidence comes from the artefact the procedure generates: the checklist ticked, the reading logged, the form submitted. If your SOP ends at "record the results", without specifying where, you have written the instructions for a process whose output disappears.
The practical approach is to design the two together. Write the steps, then build the form that captures exactly the fields those steps produce, in the same order, with the same terms. When the form mirrors the procedure, following the procedure and completing the record become a single action rather than two, which is the only version people reliably do.
Build the Form Your SOP Produces in Good Form
Most procedures generate a record: an inspection result, a handover note, a completed check, a set of readings. That record is what turns a written intention into evidence, and it is the half that usually stays on paper or in somebody's notebook.
You can build the form your SOP produces in minutes with the free form builder, matching the fields to the steps, capturing who completed it and when, and collecting every run of the procedure in one searchable place. The same approach supports the specific procedures around it, like the inspection checklist, the incident report form for when a step goes wrong, and the attendance register for who was on shift. If you are choosing a tool to run these on, the guide to the best free form builders covers what to look for.
Build your procedure form in Good Form →
An SOP is worth writing when a task is repeated, matters when it goes wrong, and is currently done three different ways. Write it for the least experienced person who will do it, one action per numbered step, with a purpose at the top so people know what to do when the page and reality disagree, an exceptions section because they will, and a review date with a named owner. Then have somebody else follow it while you watch and say nothing. Do that, pair it with a form that captures what the steps produce, and you have the thing SOPs are actually for: a task that comes out the same whoever does it, with the evidence to show it.