If you've ever spent a Friday night writing an SOP that nobody reads, this is for you.
Operations leaders spend 60% of their writing time on documents that exist to prevent chaos — SOPs, process docs, incident reports, vendor scorecards, onboarding checklists. Most of these follow a predictable structure, which means they're perfect candidates for AI assistance.
The problem: generic AI prompts produce generic ops docs. "Write an SOP for onboarding" gives you a template that could apply to any company in any industry. Useless.
Over the last year I've refined a set of prompts that produce operational documents my team actually uses. Each one forces specific constraints, real examples, and a structure that survives a real operational scenario. Here are 10 of the best.
Want all 200+ prompts I use across my entire business? I packed them into the Developer Productivity Prompt Library — 30 tested prompts for shipping faster. Or grab the SaaS Marketing Copy Prompt Pack if you need customer-facing copy.
How these prompts are structured
Every prompt below uses the same four-part framework:
- Role — who the AI is acting as
- Context — the specific situation
- Constraints — what it can and cannot do
- Output — the exact format
This isn't prompt "engineering." It's just being specific. But the constraints are where the magic happens — they're what separate a document your team uses from one they ignore.
1. The SOP That Doesn't Get Skipped
You are an operations manager documenting a repeatable process.
Process: [INSERT PROCESS NAME — e.g., "Provisioning a new hire's laptop and accounts"]
Audience: [INSERT — e.g., "IT admin with 2 weeks of tenure"]
Write a step-by-step SOP with these rules:
- Number every step. No step may be longer than 2 sentences.
- Every step must start with a verb (Click, Open, Send, Verify...).
- If a step requires a decision, write it as: "IF [condition] THEN [action] ELSE [action]"
- After every 5 steps, add a "Checkpoint:" line stating what should be true at that point.
- End with a "This is wrong if:" section listing 3 failure modes.
- Do NOT include an introduction, background, or "why this matters." The reader is mid-task.
Output format: Plain numbered list. No headers except "Checkpoint:" and "This is wrong if:".
Why it works: The "every 5 steps" checkpoint forces the reader to verify they're on track before continuing. The "This is wrong if" section is more valuable than the happy path — it's what people actually reference when something breaks.
2. Incident Response Runbook from a Messy Slack Thread
You are a senior ops engineer turning a chaotic Slack incident thread into a runbook.
Paste the Slack thread below. Transform it into a runbook with:
[SLACK THREAD]
Rules:
- Extract only actions that someone took or should take. Discard all reactions, jokes, and "looking into it" messages.
- Group actions into phases: Detect → Triage → Mitigate → Resolve → Postmortem.
- Each action must include: WHO did it, WHAT they did, and the TIMESTAMP.
- If an action was wrong (someone tried something that didn't work), include it in a "Dead ends" section — these are lessons, not waste.
- Add a "Trigger conditions" section at the top: what symptoms should cause someone to open this runbook?
- The first line must be: "If [specific symptom], do step 1 immediately. Do not read the rest first."
Output: Markdown with phase headers. Keep it under 400 words.
Why it works: Most incident docs are written after the fact and describe what happened. This prompt produces a document that tells the next responder what to DO — including the dead ends, which are the most valuable lessons.
3. Vendor Scorecard That Forces a Decision
You are a procurement lead creating a vendor evaluation scorecard.
We are evaluating vendors for: [INSERT CATEGORY — e.g., "Customer support ticketing"]
Our must-haves: [LIST 3-5]
Our nice-to-haves: [LIST 3-5]
Budget range: [INSERT]
Team size: [INSERT]
Create a scorecard with:
- Exactly 8 criteria, weighted to total 100 points.
- No single criterion may exceed 20 points (prevents one factor dominating).
- At least 2 criteria must be "risk" criteria (e.g., data portability, vendor lock-in, financial stability).
- For each criterion, write a 1-sentence definition of what a 5/5 looks like AND what a 1/5 looks like.
- End with a "Decision rule:" line — e.g., "If total ≥ 70 AND no risk criterion scores below 3, proceed to contract negotiation."
Do not include a summary, conclusion, or recommendation. The scorecard is the output.
Why it works: The forced weighting (no single criterion > 20 points) prevents the "one shiny feature" bias. The decision rule removes the post-scoring debate. The risk criteria ensure you're not just optimizing for features.
4. Onboarding Checklist That Prevents Day-1 Chaos
You are an ops manager creating a new-hire onboarding checklist for Day 1 through Day 30.
Role: [INSERT ROLE — e.g., "Junior Backend Engineer"]
Start date: [INSERT]
Manager: [INSERT NAME]
Buddy: [INSERT NAME]
Create a checklist with:
- 3 phases: Day 1 (setup + intro), Week 1 (ramp), Weeks 2-4 (first contribution).
- Each item must be assigned to either: [New hire], [Manager], [IT], or [Buddy].
- Every IT item must include the specific tool/account being provisioned.
- Include exactly 3 "social" items (coffee chat, team lunch, intro to adjacent team) — no more, no less.
- Mark items that block other items with "→ blocks: [item name]".
- The LAST item must be: "30-day check-in: [Manager] and [New hire] review this checklist. Anything unfinished becomes a tracked action item."
Output: A table with columns: Item | Owner | Phase | Blocks.
Do not include welcome messages or motivational text.
Why it works: Assigning every item to a specific owner eliminates the "I thought you were doing that" gap. The blocking dependencies surface the critical path. The 30-day review creates accountability for completion.
5. Process Decision Document (One-Pager)
You are an operations lead writing a decision document for a process change.
Decision needed: [INSERT — e.g., "Should we move from manual to automated deployment?"]
Write a one-page decision doc with these EXACT sections, in order:
1. **Decision:** One sentence stating the recommendation. No hedging.
2. **Context:** 3 sentences max. What's happening, why now, who's affected.
3. **Options considered:** List exactly 3 options. For each, one sentence on what it is and one sentence on the main downside.
4. **Recommendation rationale:** Why the recommended option wins. Reference specific tradeoffs, not vibes.
5. **Cost of delay:** What happens if we don't decide in the next 2 weeks.
6. **Reversibility:** Is this decision reversible? If yes, how hard?
7. **Owner:** Who makes the final call and by when.
Rules:
- Total length: maximum 250 words including headers.
- No bullet points longer than one line.
- Do not write "In conclusion" or any closing paragraph.
Output: Markdown.
Why it works: The forced brevity (250 words) kills the tendency to write 5-page decision docs that nobody reads. "Cost of delay" creates urgency. "Reversibility" prevents analysis paralysis on low-stakes decisions.
6. Cross-Team Handoff Document
You are an ops manager writing a handoff document for work moving between two teams.
From team: [INSERT — e.g., "Engineering"]
To team: [INSERT — e.g., "Customer Support"]
Work item: [INSERT — e.g., "Bug fix #2847 — payment failure on Safari"]
Write a handoff doc with:
- A "What's done" section: exactly what was completed, with links.
- A "What's NOT done" section: explicitly list what was NOT addressed, even if it seems obvious. This prevents assumptions.
- A "Known unknowns" section: things the sending team isn't sure about and the receiving team will need to investigate.
- A "Definition of done" section: what the receiving team needs to achieve to close this out.
- A "How to reach us" section: names + channels for questions, with a note: "If no response in [SLA], escalate to [name]."
Format: Plain sections with short paragraphs. No "Dear team" or sign-offs.
The most important section is "What's NOT done" — make it longer than "What's done" if needed.
Why it works: The "What's NOT done" section is the single highest-value part of any handoff. It prevents the receiving team from assuming work was completed when it wasn't. "Known unknowns" gives them permission to investigate without feeling like they missed something.
7. Postmortem Template That Finds Root Cause (Not Blame)
You are facilitating a blameless postmortem for an operational incident.
Incident: [INSERT — e.g., "Checkout was down for 47 minutes on Tuesday"]
Impact: [INSERT — e.g., "~$12K in lost revenue, 340 failed checkouts"]
Write a postmortem document with:
1. **Timeline:** Minute-by-minute from first alert to resolution. Only facts. No "we should have."
2. **Impact:** Quantified. If you can't quantify it, say "Impact unknown — needs measurement" and add a follow-up action.
3. **Root cause(s):** Use the "5 Whys" method. Each "why" must point to a system, process, or tool — NEVER a person. If you find yourself writing "because [person] didn't...", rephrase to "because the process didn't ensure..."
4. **What went well:** At least 2 things that worked during the response.
5. **What went poorly:** At least 2 things that failed.
6. **Action items:** Each action item must have: an owner, a due date, and a priority (P0/P1/P2). No action item may be "improve monitoring" — it must be specific (e.g., "Add alert for checkout latency > 2s, owned by [name], due [date]").
Rules:
- The word "should" is banned. Replace every instance with a specific action item.
- Maximum 1 page.
Output: Markdown.
Why it works: Banning "should" forces every observation into an actionable item. The 5-Whys rule that points to systems (not people) produces blameless analysis that actually surfaces root causes. The "improve monitoring" ban kills the most common useless action item.
8. Meeting Notes That Become Decisions (Not Transcripts)
You are an ops manager converting meeting notes into a decision log.
Raw notes:
[PASTE NOTES]
Transform into a structured doc with:
1. **Decisions made:** List each decision as: "We decided to [action], because [reason], effective [date]." If a decision has no reason recorded, write "Reason: NOT RECORDED — follow up with [likely attendee]."
2. **Decisions deferred:** Things that were discussed but NOT decided. Each must have: "Owner: [name], Revisit by: [date]."
3. **Action items:** Owner + task + due date. Separate from decisions.
4. **Open questions:** Things raised that nobody could answer. Each with an owner to investigate.
Rules:
- No verbatim quotes unless they contain a commitment.
- No "we discussed" or "we talked about" — only outcomes.
- If a section is empty, write "None" — do not omit it.
Output: Markdown table where possible.
Why it works: Meeting notes that capture what was discussed are useless. This prompt extracts only what was decided and what was deferred — the two things people actually need after a meeting. The "NOT RECORDED" flag surfaces gaps immediately.
9. Compliance/Audit Evidence Checklist
You are an ops lead preparing for a [INSERT FRAMEWORK — SOC 2 / ISO 27001 / HIPAA / GDPR] audit.
Scope: [INSERT — e.g., "Access control and change management"]
Systems in scope: [LIST]
Generate an evidence checklist with:
- Each control mapped to the specific framework requirement (cite the section/number).
- For each control, list the evidence type needed: Policy doc | System config screenshot | Log export | Signed approval | Ticket reference.
- Group by evidence type so the team can collect efficiently (don't jump between policy docs and log exports).
- Mark controls that are "new since last audit" with 🆕 — these need extra preparation.
- Add a "Gap" column: if we don't currently have this evidence, mark it and assign an owner.
Do not write explanatory text about what the framework is. The auditor already knows.
Output: Table with columns: Control | Framework Ref | Evidence Type | Status | Owner.
Why it works: Audit prep fails when evidence collection is ad hoc. Grouping by evidence type (all policy docs together, all log exports together) cuts collection time dramatically. The 🆕 flag prevents the classic mistake of assuming last year's evidence still applies.
10. Quarterly Operations Review (For Leadership)
You are an operations lead writing a quarterly ops review for the leadership team.
Quarter: [INSERT]
Team: [INSERT]
Write a review with these sections — and ONLY these sections:
1. **Metrics that moved:** 3-5 key metrics. For each: the number, the change vs last quarter, and ONE sentence on why it moved. No vanity metrics (e.g., "tickets closed"). Only outcome metrics (e.g., "mean time to resolution").
2. **What we shipped:** Operational improvements deployed this quarter. Each in one line. No "ongoing work" — only completed.
3. **What broke:** Incidents or failures this quarter. Each with: root cause (one sentence) and the fix deployed.
4. **What we're stopping:** At least 1 process, tool, or meeting that we're killing next quarter. If you can't think of one, write "Nothing — review whether we're accumulating cruft."
5. **Next quarter's bet:** ONE operational initiative for next quarter. Not a list. One bet, with a success metric and a kill criterion.
Rules:
- Total length: 1 page max.
- No "strategic alignment" or "synergy" language.
- The leadership team skims. Put the most important number first.
Output: Markdown.
Why it works: The "What we're stopping" section is the most powerful — it forces operational hygiene and prevents process accumulation. "One bet with a kill criterion" prevents the laundry-list approach where 12 initiatives get 10% effort each.
How I test these prompts (before trusting them)
I don't trust a prompt until it survives three tests:
- Run it 3 times with the same inputs. If the outputs vary wildly, the prompt is too vague. Tighten constraints.
- Swap in a different context (e.g., change "backend engineer onboarding" to "sales rep onboarding"). If the structure breaks, the prompt is overfit to one scenario.
- Read it aloud. If the output sounds like it could apply to any company, it's too generic. Add company-specific constraints.
The prompts above have survived all three. Your mileage will vary — adapt the constraints to your team's reality.
The prompt system I actually use
These 10 prompts are a slice of the system I run across my entire business — operations, engineering, marketing, sales, and product. I've packaged the full set into a few resources:
- Developer Productivity Prompt Library ($49) — 30 prompts for shipping code faster. If you're technical, start here.
- SaaS Marketing Copy Prompt Pack ($49) — 25 prompts for landing pages, cold emails, and ad copy.
- AI Startup Operations Prompt System ($199) — 50+ prompts + 10 workflows. This is the one ops leaders grab.
- Developer Product-Launch Prompt Pack ($9) — the $9 starter, 7 prompts for shipping a launch.
Or browse the full store and pick what fits.
If you want a custom prompt system built for your specific business — your tools, your team, your workflows — reach out. I build those for founders who don't want to spend 6 months figuring out prompt constraints.
What operational document do you spend the most time on? Drop it in the comments — I'll share the prompt I use for it.
Top comments (0)