Most SOPs are written for legal cover, not for use. They sit in a Confluence page nobody opens, full of “ensure that X is done” instead of testable steps, and the #1 reason they rot is that no single person owns them — when an SOP belongs to “the business,” nobody keeps it accurate. These prompts force a single named owner, verb-led steps, a success check per step, a review date, and an edge-case appendix, so the procedure still runs when the person who wrote it is on PTO. Pair with handover document prompts when documenting role-level knowledge transfer.
TL;DR
- Each prompt below produces an SOP with a named owner, verb-led numbered steps, a success check per step, an escalation path, and a review date — the five things missing from SOPs people ignore.
- Replace every
[bracketed placeholder]with your real process, role, tools, and policy before sending. The more concrete your inputs, the less generic the output. - Which model: any current model can fill these in, but for long, structured procedures Claude (Opus 4.7 / Sonnet 4.6) tends to follow multi-part formatting instructions most consistently; GPT-5.5 and Gemini 3.1 Pro both work well for shorter SOPs.
- Set a review cadence on every SOP: quarterly for fast-moving processes, annually for stable ones. An SOP with no owner and no review date is already out of date.
Best for
- Onboarding new hires
- Support / ops processes
- Engineering on-call runbooks
- Compliance procedures
- Customer-facing workflows
1. One-page SOP template
Draft a 1-page SOP for "[process]". Format: 1 line on purpose, a named owner role,
the trigger, 5-9 numbered steps each starting with a verb, a success criterion per
step, an escalation path, and a review date. Keep it under 400 words.2. Onboarding day-1 SOP
Draft a day-1 onboarding SOP for a new [role] hire. Inputs: [team], [tools], [access lists].
Output: 8 numbered steps, the owner of each, time to complete, and a success check per step.
Include a "what if the buddy is unavailable" fallback.3. Support-ticket triage SOP
Draft a support-ticket triage SOP. Inputs: [ticket categories], [severity bands], [SLA].
Output: numbered triage steps, a decision tree for severity, named escalation paths,
and response-time targets per severity band.4. On-call runbook
Draft an on-call runbook for [service]. Trigger: [alert]. Output: 6 steps, the expected
log or metric to check at each step, the 3 most common causes, links to dashboards,
and a clear "when to wake up the next engineer" threshold.5. Refund / chargeback SOP
Draft a refund SOP. Conditions: [policy]. Output: numbered eligibility checks, a decision
matrix (auto / manual / escalate), customer-facing message templates, and log requirements
for each path.6. Release / deployment SOP
Draft a release SOP for [service]. Inputs: [CI system], [environments], [rollback method].
Output: a pre-release checklist, deployment steps, post-release verification, rollback
trigger criteria, and a comms cadence (who is told what, and when).7. Compliance / audit SOP
Draft a compliance procedure for "[control]". Reference framework: [SOC 2 / GDPR / HIPAA].
Output: who runs the control, how often, the evidence to capture each time, the review path,
and the escalation step if the control fails.8. Customer-onboarding SOP
Draft a customer-onboarding SOP from contract signature to first-value moment.
Output: 6 phases, the owner of each, a success check per phase, communication touchpoints,
and what gates the move to the next phase.9. SOP edge-case appendix
Below is an SOP for "[process]". Add an edge-case appendix: the top 6 edge cases the
current SOP does not cover, how to handle each, and which existing step to link it under.
[paste SOP]10. SOP simplification pass
Below is an overly long SOP. Cut it to 50% length or less without losing any critical step.
Group similar steps. Add a 1-line success check for each remaining step.
[paste SOP]11. SOP testability check
Below is an SOP. For each step, mark whether it is testable (someone can verify it was done).
For untestable steps, rewrite them with a concrete, observable check.
[paste SOP]12. SOP-to-checklist converter
Convert this SOP into a checklist someone can run in 10 minutes on a real ticket.
Output: 12 checkboxes or fewer, each 15 words or fewer. Then add a 1-line
"what to do if any check fails".
[paste SOP]How to get a usable SOP on the first try
- Feed it the real process, not the idea of the process. Paste your actual tool names, role titles, severity bands, and policy text into the brackets. A prompt with
[policy]left blank produces a generic template; one with your real 30-day refund window produces a usable draft. - Ask for a success check on every step. This is the single highest-leverage instruction. A step like “Step 4: notify the customer” is untestable; “Step 4: send the refund-confirmation email; success = email appears in the ticket thread” can be verified by anyone.
- Demand verb-led steps. “Ensure the account is closed” hides the action. “Close the account in Admin > Users > Deactivate” tells the operator exactly what to do.
- Set the review date in the document. Quarterly for processes that change often (support, releases), annually for stable ones (compliance, finance). Put the owner role and next-review date at the top, not buried in metadata nobody reads.
- Keep it to one page where you can. Long SOPs get skimmed and ignored. If a draft runs long, use prompt 10 to cut it, or split it into two procedures.
Common mistakes
- No named owner per step — “the team” owns nothing, so nothing gets maintained.
- Steps not verb-led (“ensure that X is done”) — readers can’t act on it.
- No success criterion — the operator finishes step 4 unsure whether they actually completed step 4.
- No edge cases or “what if” branches — the first unusual situation breaks the SOP.
- Not dated or versioned — readers can’t tell if it’s the current version.
- No review cadence — the process changes, the SOP doesn’t, and the team quietly stops trusting it.
FAQ
Which AI model should I use to draft SOPs? Any current model handles short SOPs. For long, multi-section procedures with strict formatting (owner, steps, checks, escalation, review date all in one pass), Claude Opus 4.7 and Sonnet 4.6 tend to follow complex instructions most consistently. GPT-5.5 and Gemini 3.1 Pro are also strong; pick whichever you already have access to and use the same prompt structure.
How often should I review an SOP? As a rule of thumb, review fast-moving processes (support triage, releases, on-call) quarterly and stable ones (compliance, finance, onboarding) annually — and always re-review immediately after the underlying process or tooling changes. Put the next-review date and owner role at the top of every SOP.
Why do most SOPs end up ignored? The recurring failure is ownership: when an SOP belongs to “the business” instead of a named role, no one keeps it current, it goes stale, and the team stops trusting it. Length is the second culprit — long documents get skimmed. The prompts above counter both by forcing a single owner and keeping output tight.
Can the AI invent a process I don’t actually have? It can, and that’s the risk. The model fills gaps with plausible-sounding generic steps. Always paste your real policy, tools, and severity bands into the brackets, then use prompt 11 (testability check) to flag any step a human can’t verify — those are usually the invented ones.
Should I let AI write a compliance SOP for SOC 2 / GDPR / HIPAA? Use it for the first draft and structure (prompt 7), but have a qualified person verify every control, evidence requirement, and frequency against your actual framework obligations before it goes live. Treat AI output as a starting draft, never as authoritative compliance text.
Related
- Process improvement prompts
- Handover document prompts
- Meeting agenda prompts
- Project planning prompts
- Workflow bottleneck analysis prompts
- Executive summary prompts
Tags: #Prompt #Productivity #SOP