Create practical operating documentation for [PROCESS OR WORKFLOW] using these source notes: [SOURCE NOTES]. The document is for [AUDIENCE], who have this starting knowledge and access: [AUDIENCE CONTEXT]. It must cover the process from trigger through completion, including these systems, files, or dependencies: [TOOLS AND DEPENDENCIES]. First, identify the trigger, intended outcome, owner at each stage, inputs, decision points, handoffs, approval gates, and completion evidence. Do not fill gaps with assumed policy, permissions, deadlines, or system behavior. If a required detail is absent, ask up to 3 clarifying questions; otherwise state the gap as “Confirm with process owner.” Produce a publish-ready document with: 1. Purpose, scope, and when not to use this process. 2. Prerequisites: access, files, inputs, and expected timing. 3. A numbered procedure. Every step must begin with the responsible role, specify the action, name the tool or artifact, state the expected result, and include timing where the notes support it. 4. A decision table for exceptions, including condition, decision-maker, action, and escalation path. 5. A handoff table with sender, recipient, artifact, and confirmation method. 6. A “Definition of done” checklist and a short ownership/contact section. Write in plain language, using imperative verbs and one action per numbered step. Keep the main procedure scannable; move edge cases to the exception table. Before answering, check that every step has an owner or explicitly marked owner gap, and flag any instruction that relies on an unsupported assumption from the source notes.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PROCESS OR WORKFLOW] | Name the workflow the documentation should explain. | Publishing a customer case study |
| [SOURCE NOTES] | Paste existing notes, messages, rough steps, or interview notes about the process. | Marketing gets signed interview notes from Customer Success; legal approves customer quotes; web team publishes in CMS. |
| [AUDIENCE] | Describe who will use the documentation. | New content marketers |
| [AUDIENCE CONTEXT] | State what the audience already knows and what access they have. | They can use Notion and the CMS but cannot approve legal copy. |
| [TOOLS AND DEPENDENCIES] | List the software, folders, templates, teams, and approvals involved. | Notion brief, Google Drive interview folder, legal approval email, Contentful CMS |
How to use
- Paste the prompt into Copilot, ChatGPT, or Claude and replace every bracketed input.
- Include raw notes rather than rewriting them first; the model needs the real gaps and inconsistencies.
- Check the output against an actual recent run of the process, especially owners, approvals, and handoffs.
- Follow up with: “Turn the exception table into a one-page troubleshooting guide for new operators.”
Variations
SOP from interview
Use when the process exists mostly in one expert’s head.
Turn this interview with [PROCESS EXPERT] about [PROCESS] into an SOP for [AUDIENCE]. Preserve only claims supported by the interview. Produce: purpose, trigger, prerequisites, numbered steps with role and tool, decisions, handoffs, and completion checklist. Mark unclear ownership, timing, or access as “Validate with [PROCESS EXPERT].” Ask up to 3 questions only if a missing answer blocks the procedure. Check that no step combines separate actions.
Runbook for incidents
Use for an operational procedure that must work under time pressure.
Write an incident runbook for [INCIDENT TYPE] using [EXISTING NOTES]. It is for [ON-CALL ROLE] using [SYSTEMS]. Include severity criteria, first 15-minute actions, evidence to collect, decision tree, escalation contacts by role, customer-communication triggers, recovery verification, and post-incident records. Do not invent thresholds or permissions; flag them. Check that each decision has an owner and each recovery step has a verification signal.
Onboarding guide
Use when teaching a new hire a recurring responsibility.
Create a 30-day operating guide for a new [ROLE] taking over [RESPONSIBILITY]. Use [TEAM NOTES] and [TOOLS]. Organize it by first day, first week, and recurring cadence. For each task, state owner, purpose, expected output, source of truth, quality check, and who can unblock the person. Separate training exercises from live production work. Flag missing access or approval details and do not invent them.
Tips
- Document the trigger and the evidence of completion, not just the actions in between; those are the two points most often omitted from a useful SOP.
- Assign ownership by role rather than a person’s name unless the process truly has a single accountable individual.
- Use an exception table for rare cases so the normal path remains readable and operators can still find escalation rules.
- Test the draft with someone unfamiliar with the process and note where they need to ask a question; that question usually identifies a missing input, decision, or permission.
FAQ
Can AI create documentation from a screen recording?
Yes, if you provide a transcript or detailed notes from the recording. Validate clicks, permissions, and changing interface labels before publishing.
Should every step have an owner?
For cross-functional work, yes. A role owner prevents handoffs from becoming implied responsibilities.
How detailed should an SOP be?
Include enough detail for the stated audience to complete the task safely, then put rare branches and background context outside the main path.