Standard operating procedure
A standard operating procedure template: purpose, when to use it, prerequisites, checked steps, an escalation path, and an owner to review it.
Last updated
Fill in the blanks
Assembled in your browser — nothing you type is stored or sent anywhere.
Your document
How to use it well
- →Every step needs a check, not just an action - "deploy to production" tells someone what to do, "error rate stays flat for 15 minutes" tells them whether it worked.
- →Write the escalation path for the failure you're actually worried about, at the step where it's most likely to happen - a generic "contact your manager" line gets skipped under pressure.
- →An SOP with no review date rots quietly: the dashboard gets renamed, the tool gets replaced, and nobody notices until someone follows stale steps during an actual emergency.
Part by part
- **Owner:** {{owner}}
- A named owner, because an unowned procedure rots. Someone has to be responsible for it still being true.
- **Review by:** {{review_date}}
- An expiry date. Procedures drift from reality silently, and a review date is what turns that from a discovery into a scheduled check.
- ## When to use this
- Scope. A procedure applied in the wrong situation is worse than none, because it carries the authority of being written down.
- ## If something goes wrong
- The escalation path, which is the section people actually need under pressure — and the one most often missing.
Common mistakes
Writing steps that assume the reader's context.An SOP is read by someone doing this for the first time, often at the worst moment. Steps that skip a login, a permission or a prerequisite are the ones that fail in an incident.
No review date.Procedures describe systems that change. Without a scheduled review, an SOP is trusted long after it stopped being accurate, which is more dangerous than having none.
Omitting the escalation path.The procedure covers the expected case, and the reason someone opened it is often that the expected case is not happening. Where to go next is the most valuable line in the document.
Questions
How detailed should the steps be?
Detailed enough for someone who has never done it, using exact names for buttons, commands and systems. The test is whether a new colleague could follow it without asking a question.
How often should it be reviewed?
Every six to twelve months for stable procedures, and after any incident where it was used. The date matters less than there being one, since it is what prompts anyone to check.
What if reality has drifted from the SOP?
Update the document rather than working around it. A procedure everyone knows is wrong trains people to ignore procedures generally, which is the harder problem to fix.
Should every process have one?
No — only those done rarely, under pressure, or by people who did not design them. Documenting a daily routine everyone knows produces maintenance without a reader.