Most SOPs sit in a wiki page nobody reads. The version that gets used follows specific structural rules — and is short enough that a new hire actually completes them. Claude can produce these in 15 minutes if you brief it right.
Most SOPs are written by the person who knows the process best, who then over-includes context, exceptions, and edge cases. The result is a 12-page document that nobody reads.
The version that gets used is structured by what someone needs to DO, not what someone needs to KNOW. Step-by-step, decision points clearly marked, exception handling separate from main flow.
1. Purpose (2 sentences). When does someone use this? What does success look like?
2. Prerequisites (bulleted). What needs to be true before starting?
3. Step-by-step procedure (numbered, no ambiguity). Each step is one action. Decision points are clearly marked.
4. Exception handling (separate section). When to deviate. Who to escalate to.
5. Success criteria (checklist). How do you know the process was completed correctly?
Write an SOP for [PROCESS NAME]. Who follows this SOP: [ROLE] When do they use it: [TRIGGER] What does the process accomplish: [OUTCOME] What I know about how it currently runs (informal description): [DESCRIPTION] Known exceptions: [LIST] Who owns this process: [PERSON/ROLE] Format the SOP using the 5-section structure (Purpose / Prerequisites / Procedure / Exceptions / Success). Constraints: - Maximum 600 words total - Each procedure step is one action, no compound steps - Decision points clearly marked as "IF X THEN Y" - Exception handling separate from main flow - Plain language, no jargon - Written for someone who has never done this before Goal: a new hire could follow this without asking questions.