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.