Write a standard operating procedure for [PROCESS NAME]. Purpose and trigger: [PURPOSE AND START EVENT] Roles: [PERFORMER, REVIEWER, APPROVER, RECIPIENT] Workflow: [CURRENT STEPS, SYSTEMS, INPUTS, OUTPUTS, HANDOFFS] Controls: [POLICIES, QUALITY RULES, DEADLINES, SECURITY] Exceptions: [EDGE CASES, FAILURES, ESCALATION PATH] References: [TEMPLATES, LINKS, EXAMPLES] Ask up to 3 clarifying questions only if a required input is missing. Do not invent permissions, policy, service levels, approvals, or factual instructions. Label unknowns “confirm before publishing.” Produce a publishable SOP with document owner, effective-date and version placeholders, review cadence, scope, non-goals, trigger, end state, and roles table. Then provide prerequisites: access, source material, templates, and checks before step 1. Write numbered steps beginning with action verbs. Each must say where to act, what to enter or inspect, expected result, handoff recipient, and evidence to retain. Make decision points explicit as if/then branches. Add a quality-control checklist with measurable acceptance criteria and rework instructions. Add an exceptions table with scenario, immediate action, escalation owner, response timing if known, and documentation required. Finish with a change log and references. Self-check that a trained new employee can identify the next action from every step. Flag undefined terms, unwritten judgment, and access needed but absent from prerequisites.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PROCESS NAME] | Enter the repeatable process the SOP covers. | Publishing a customer case study |
| [PURPOSE AND START EVENT] | Explain why the process exists and exactly what starts it. | Publish an approved customer story; starts when marketing receives signed interview consent. |
| [PERFORMER, REVIEWER, APPROVER, RECIPIENT] | List the roles that do, check, approve, and receive the work. | Content marketer drafts; customer success verifies facts; legal approves permissions; web producer publishes; sales receives the link. |
| [CURRENT STEPS, SYSTEMS, INPUTS, OUTPUTS, HANDOFFS] | Paste the current workflow, systems, materials, outputs, and handoffs. | Notes in Notion, draft in Google Docs, assets in Drive, page in Webflow, final URL sent to sales. |
| [POLICIES, QUALITY RULES, DEADLINES, SECURITY] | List applicable policies, acceptance criteria, timing, and security requirements. | Customer approves quotes and logo use in writing; use approved metrics only; publish within 10 business days. |
| [EDGE CASES, FAILURES, ESCALATION PATH] | Describe common exceptions and who resolves them. | Customer withdraws a quote, metrics conflict, or legal rejects a claim; escalate to head of content. |
| [TEMPLATES, LINKS, EXAMPLES] | Provide reference materials an operator should use. | Case study brief, interview question bank, publishing checklist, consent form. |
How to use
- Paste the process notes even if they are incomplete.
- Ask the operator to validate every step against the actual systems.
- Confirm exceptions with the person authorized to resolve them.
- Then ask: “Convert the quality checklist into a one-page operator checklist.”
Variations
SOP audit
Use this when an SOP is stale or unclear.
Audit this SOP for [PROCESS]: [CURRENT SOP]. Compare it with [CURRENT WORKFLOW AND POLICIES]. Return a table with missing or unclear instructions, operational risk, exact revision needed, and the owner to confirm it. Then write a revised table of contents and rewrite only the highest-risk sections. Do not assume policies, systems, or approval rules. Flag conflicts between the SOP and current workflow.
Training guide
Use this when a new employee must learn the process.
Turn the SOP for [PROCESS] into a training guide for [ROLE]. Use [SOP OR PROCESS NOTES] and [COMMON MISTAKES]. Create a 30-minute learning path with objectives, a guided practice scenario, a knowledge check and answer key, and supervisor sign-off. Keep instructions faithful to the source. Flag steps needing live-system access or supervisor judgment before independent work.
Incident runbook
Use this for time-sensitive operational response.
Create a runbook for [INCIDENT OR TIME-SENSITIVE PROCESS] using [KNOWN PROCEDURE AND TOOLS], [ON-CALL ROLES], and [ESCALATION RULES]. Put first-15-minute actions first, with decision branches, communication requirements, evidence to capture, stop conditions, and post-incident handoff. Do not invent authority levels or system commands; label missing details for confirmation.
Tips
- Write both the exact start event and verifiable end state for the process.
- Keep policy requirements linked to the action they govern, rather than burying them in a reference section.
- Test the SOP with someone who did not write it, using a realistic exception case.
- Use screenshots only where interface details materially change an action; they become stale quickly.
FAQ
Can AI write an SOP from a short description?
It can draft a structure, but operators and owners must validate instructions, controls, and exceptions.
How is an SOP different from a checklist?
An SOP explains roles, decisions, controls, and exceptions; a checklist is a short execution aid.
When should an SOP be reviewed?
Review after material process changes and on a regular risk-based cadence.