Writing SOPs Your Team Will Actually Follow

A standard operating procedure is not documentation. Documentation explains how something works; an SOP tells a specific person what to do next, usually when something has gone wrong and they are not at their best.

That distinction drives every decision about how one should be written. The reader of an SOP is frequently tired, under time pressure, possibly woken at 3am, and may not be the person who normally does this task — which is precisely why the procedure was written down.

Four properties separate a procedure that works from one that merely exists:

1. It is executable without interpretation. Every step is an action with an unambiguous outcome. "Ensure the service is healthy" is not a step; "run curl -sf https://api.example.com/health and confirm it returns 200" is.
2. It states the preconditions. What access, credentials and tools the reader needs, established before step one rather than discovered at step seven.
3. It handles the unhappy path. What to do when a step fails is the part that gets used most.
4. It names an owner and a review date. An unowned procedure decays silently.

The test is simple and worth actually running: hand it to someone who has never done the task and watch them attempt it without helping. Every question they ask is a defect in the document.

A consistent skeleton means readers know where to look rather than reading the whole document to find one thing.

Title and scope. What this covers, and explicitly what it does not. Scope boundaries prevent a procedure being applied to a situation it was never designed for.

When to use this. The trigger. "Use this when the nightly export job reports a non-zero exit code."

Prerequisites. Access, credentials, tools, and any approval needed before starting. This section prevents the most common failure mode: reaching step six and discovering you lack permission, with the system in a half-changed state.

Steps, numbered, one action each, in the imperative. Include the expected result of each step so the reader can confirm they are on track.

Rollback. How to undo this if it goes wrong, stated before the steps that might require it.

Escalation. Who to contact, by what route, and the threshold at which to do so — expressed as a condition rather than a feeling. "If the queue depth is still rising after 15 minutes, page the on-call engineer."

Verification. How to confirm the procedure worked. Without this, "done" means "I reached the last step", which is not the same thing.

Metadata. Owner, last reviewed, version. Three lines that decide whether the document is trusted in two years.

One action per step. A step containing "and" is usually two steps, and a reader interrupted mid-step cannot tell where they stopped.

Imperative mood, second person. "Restart the worker", not "the worker should be restarted". Passive voice hides who acts, which is exactly the information the reader needs.

Exact values, not descriptions. The full command with its flags, the precise menu path, the literal configuration key. Anything a reader must reconstruct is an opportunity to reconstruct it wrongly.

State the expected result. "You should see three healthy replicas." This converts a blind sequence into something the reader can verify continuously, and it turns a deviation into an early signal rather than a late surprise.

Put warnings before the step, not after. A caution following a destructive action has failed at its job.

Mark decision points explicitly. Where the procedure branches, say so and label both paths clearly. Nested conditionals in prose are where procedures become unfollowable.

Do not explain the system in the middle of a procedure. Background belongs in a linked document. A reader executing at 3am is not reading an architecture overview, and burying a step inside explanation is how steps get missed.

Every organisation with SOPs has stale ones, and a stale procedure is more dangerous than none — it carries authority while giving wrong instructions, and someone under pressure will follow it.

What actually keeps them current:

A named owner, not a team. "Platform team" owns nothing. A person owns it, and when they leave, ownership transfers explicitly.

A review date on the document, visible at the top. Overdue is then obvious to every reader, not only to whoever runs an audit.

Update on use. The single most effective habit: whoever executes the procedure fixes what was wrong, immediately, while they remember. This requires the document to be trivially editable — a procedure locked behind a change-approval process will not be corrected.

Delete aggressively. A procedure for a decommissioned system should be removed, not archived into a folder someone will find later and follow.

Link from where it is needed. An SOP nobody can find during an incident does not exist. Link it from the alert, the runbook index, and the dashboard that surfaces the problem.

Version history matters for anything audited. ISO 9001 and similar frameworks require controlled documents with identifiable revisions and approval records, and retrofitting that later is considerably harder than starting with it.

The OpenTools SOP generator assembles procedures in the browser. Operational runbooks describe internal systems, name staff, and often include hostnames and escalation paths — material worth keeping off third-party services while it is being drafted.