---
name: "ops-write-an-sop"
description: "Use when the user names a process to document, hands over notes or a transcript of how it is done, or asks what the standard way of doing something is."
triggers: ["write an SOP", "document this process", "turn this into a playbook", "work instruction draft", "what is the standard way to do this", "SOP owner and review date"]
version: "1"
---
# Write an SOP
Use this when the user names a process to document, hands over notes or
a transcript, or asks what the standard way of doing something is.
## What you need first
The process name, how it is done today (notes, a transcript, or a
walkthrough), who does it, and the systems it touches.
Nothing to work from means you draft from their one-line description
and mark every step INFERENCE until they walk it with you. No owner
named means the SOP stays a draft until someone owns it.
## Say the process back in one line
What it produces, who does it, how often. Ask only what changes the
steps.
## Pick the format by shape
- A checklist for ten or fewer linear steps.
- Hierarchical steps for sub-steps and exceptions.
- A flowchart for branches and handoffs.
## Write the SOP
Every SOP carries: purpose in one line; scope (what it covers and what
it does not); roles with one owner; prerequisites; definitions for any
term a newcomer would trip on; numbered steps where each step names who
does it and what done looks like; the exceptions with what to do for
each; the process metrics that prove it ran right; and the linked
templates or systems.
Keep steps checkable, not adjectives.
## Add the header every SOP carries
SOP ID, owner, approval sign-off (approver plus date — an unapproved
SOP carries no authority), effective date, last-verified date, review
date (90 days out unless they say otherwise), revision number, and a
revision-history table.
An SOP with no owner and no review date is a draft, said plainly.
## Test it cold before it publishes
Show it in chat and take one round of edits. Then cold-user test it:
someone who has never done the task follows the draft exactly, and it
publishes only if they finish with no outside help. Save it to the SOP
home they picked and add it to the library index with owner and review
date.
## Re-verify on a cadence and on triggers
Quarterly, or whenever they say a process changed, walk the steps
against reality, rewrite what drifted, and bump the revision. Review
early on trigger events too: a regulation change, an incident, new
tools, or an employee flag. Never append contradictions — rewrite.
## Rules
Never describe a step you were not told as fact. Never publish an SOP
to the team wiki without the owner's yes.
Save under sops, one doc per SOP, named for the process.