SOP, Runbook & Playbook Generator

Create structured process documents that teams can actually follow. Every step is actionable, every decision has clear criteria, every role is assigned.

Keywords

SOP, runbook, playbook, checklist, process document, standard operating procedure, workflow doc, procedure, operations manual, how-to guide, step-by-step process, process map, incident response, onboarding, offboarding, deployment, launch checklist, sprint review, escalation, decision tree, workflow, process documentation

Philosophy

• A process document nobody follows is worse than no document at all
• Every step must start with a verb — it's an instruction, not a description
• Ambiguity is the enemy: "as appropriate" and "as needed" are banned phrases
• If a step requires a decision, the criteria must be explicit
• Time estimates keep teams honest about effort
• Documents must be reviewed regularly — stale SOPs create false confidence
• The best process doc is the shortest one that covers all edge cases

Document Types

1. SOP (Standard Operating Procedure)

Purpose: Document repeatable business processes so anyone can execute them consistently.

Best for: Customer onboarding, content publishing, hiring workflows, expense approvals, release processes, support ticket handling.

Structure:

# {SOP Title}

## Document Info
| Field | Value |
|-------|-------|
| Owner | {Name, Role} |
| Last Updated | {Date} |
| Review Schedule | {Quarterly / Monthly / After incidents} |
| Version | {X.Y} |
| Approved By | {Name, Role} |

## Purpose
{One paragraph: Why does this SOP exist? What problem does it prevent?}

## Scope
{Who does this apply to? When is it used? What does it NOT cover?}

## Roles & Responsibilities
| Role | Responsibility | Person/Team |
|------|---------------|-------------|
| {Role} | {What they do in this process} | {Name or team} |

## Prerequisites
- [ ] {What must be true/ready before starting}
- [ ] {Access, permissions, tools needed}
- [ ] {Dependencies on other processes}

## Procedure

### Step 1: {Action Verb + Object}
**Owner:** {Role}
**Time estimate:** {X minutes}
**Details:**
{Detailed instructions. Be specific — include exact button names, menu paths, commands.}

**Checkpoint:** {How to verify this step is done correctly}

### Step 2: {Action Verb + Object}
...

## Exceptions & Edge Cases
| Scenario | Action |
|----------|--------|
| {What if X happens?} | {Do Y instead} |
| {What if Z is missing?} | {Escalate to / Wait for / Skip to step N} |

## Escalation Path
1. First: {Contact person/channel}
2. If unresolved in {time}: {Escalate to}
3. If critical: {Emergency contact}

## Success Criteria
- [ ] {How do you know the process completed successfully?}
- [ ] {What output/artifact should exist?}

## Revision History
| Date | Version | Change | Author |
|------|---------|--------|--------|
| {Date} | {X.Y} | {What changed} | {Name} |

2. Runbook

Purpose: Technical operations guide for executing or responding to specific technical scenarios. Emphasis on commands, rollback procedures, and escalation.

Best for: Database failover, deployment rollback, incident response, server maintenance, monitoring alert response, security incident handling.

Structure:

# {Runbook Title}

## Overview
| Field | Value |
|-------|-------|
| System/Service | {What system this covers} |
| Owner | {Team or individual} |
| Severity | {P1-Critical / P2-High / P3-Medium / P4-Low} |
| Last Tested | {Date of last drill/dry-run} |
| Last Updated | {Date} |

## When to Use This Runbook
{Specific triggers — alert names, symptoms, error messages, or scenarios that should activate this runbook.}

**Trigger conditions:**
- {Alert: "alert-name" fires in monitoring}
- {Error: "specific error message" appears in logs}
- {Symptom: Users report X behavior}
- {Scheduled: During maintenance window on {schedule}}

## Prerequisites
- [ ] {Access/permissions required — list specific IAM roles, VPN, SSH keys}
- [ ] {Tools required — list CLI tools, dashboards, access}
- [ ] {Communication — who to notify before starting}

## Procedure

### Step 1: {Assess the Situation}
**Time estimate:** {X minutes}

Check current state:

Command to check status

{command}

Expected output: `{what you should see}`
If output shows `{bad state}` → proceed to Step 2
If output shows `{good state}` → this runbook may not apply, verify the trigger

### Step 2: {Take Action}
**Time estimate:** {X minutes}

Command to execute

{command}

**Verify:**

Command to verify the action worked

{command}

Expected: `{successful output}`

### Step 3: {Confirm Resolution}
...

## Rollback Procedure

If any step fails or makes things worse, follow rollback:

### Rollback Step 1: {Undo Last Action}

Rollback command

{command}

### Rollback Step 2: {Restore Previous State}

Restore command

{command}

## Escalation

| Condition | Escalate To | Contact |
|-----------|-------------|---------|
| Step fails after retry | {Senior engineer} | {Slack/phone} |
| Data loss suspected | {Engineering lead + CTO} | {Phone immediately} |
| Customer impact > {N} minutes | {On-call manager} | {PagerDuty} |

## Post-Incident

After resolving:
1. Update the incident channel/ticket with resolution summary
2. Schedule a post-mortem within 48 hours
3. Document any deviations from this runbook
4. Update this runbook if steps were unclear or incorrect
5. File follow-up tickets for permanent fixes

## Related Runbooks
- {Link to related runbook 1}
- {Link to related runbook 2}

3. Playbook

Purpose: Strategic/tactical guide with decision points. Unlike SOPs (which are linear), playbooks branch based on scenarios.

Best for: Sales objection handling, crisis communication, competitive response, customer escalation, negotiation, marketing campaign execution.

Structure:

# {Playbook Title}

## Objective
{What winning looks like. One sentence.}

## Context
{Background: Why does this playbook exist? What situation does it address? What's at stake?}

## Decision Framework

When {situation occurs}, evaluate:

{Situation/Input} │ ├── If {Condition A} → Run Play 1 ├── If {Condition B} → Run Play 2 ├── If {Condition C} → Run Play 3 └── If unclear → {Default action / Escalation}

## Play 1: {Scenario Name}

**Trigger:** {When to run this play}
**Goal:** {What success looks like for this scenario}
**Owner:** {Who leads}

### Steps:
1. **{Action}** — {Details, talking points, or instructions}
2. **{Action}** — {Details}
3. **{Action}** — {Details}

### Key Messages:
- {What to say / key talking point}
- {What to say / key talking point}

### What NOT to Do:
- {Common mistake to avoid}
- {Common mistake to avoid}

### Measure Success:
- {Metric or outcome that shows this play worked}

## Play 2: {Scenario Name}
...

## Play 3: {Scenario Name}
...

## Escalation Matrix
| Severity | Who Decides | Response Time |
|----------|-------------|---------------|
| Low | {Role} | {Timeframe} |
| Medium | {Role} | {Timeframe} |
| High | {Role} | {Timeframe} |
| Critical | {Role} | {Timeframe} |

## Metrics & Iteration
| Metric | Target | Current | Review Frequency |
|--------|--------|---------|-----------------|
| {Metric} | {Target} | {Current or TBD} | {Weekly/Monthly} |

Review this playbook: {frequency}
Last reviewed: {date}

4. Checklist

Purpose: Pre/post verification list. Simple, fast, no ambiguity.

Best for: Launch checklists, hiring checklists, sprint review prep, deployment verification, onboarding day-1, event planning, security audit.

Structure:

# {Checklist Title}

## When to Use
{One sentence: what event or process triggers this checklist}

## Owner
{Who is responsible for completing this checklist}

## Checklist

### {Category 1}
- [ ] {Action item — specific, verifiable}
- [ ] {Action item — specific, verifiable}
- [ ] {Action item — specific, verifiable}

### {Category 2}
- [ ] {Action item}
- [ ] {Action item}
- [ ] {Action item}

### {Category 3 (if applicable)}
- [ ] {Action item}
- [ ] {Action item}

## Sign-Off
| Role | Name | Date | Signature |
|------|------|------|-----------|
| {Executor} | | | |
| {Reviewer} | | | |

## Notes
{Space for context, exceptions, or issues encountered during execution}

5. Process Map

Purpose: Visual workflow documentation with decision points. Shows the flow, not just the steps.

Best for: Customer support escalation, feature request pipeline, hiring pipeline, bug triage, content approval workflow, sales pipeline stages.

Structure:

# {Process Map Title}

## Overview
{One paragraph: What process does this map? Who are the actors? What are the possible outcomes?}

## Process Diagram

flowchart TD A[{Trigger Event}] --> B{{{Decision Point 1}}} B -->|{Condition}| C[{Action}] B -->|{Condition}| D[{Action}] C --> E{{{Decision Point 2}}} E -->|{Condition}| F[{Outcome 1}] E -->|{Condition}| G[{Outcome 2}] D --> H[{Outcome 3}]

style A fill:#3b82f6,color:#fff style F fill:#22c55e,color:#fff style G fill:#22c55e,color:#fff style H fill:#eab308,color:#000

## Step Details

### {Trigger}: {Trigger Event}
**Description:** {What initiates this process}
**Owner:** {Role}
**Input:** {What information/artifact arrives}

### {Decision}: {Decision Point 1}
**Criteria:**
| Condition | Route | Rationale |
|-----------|-------|-----------|
| {If X} | {Go to Action A} | {Why} |
| {If Y} | {Go to Action B} | {Why} |

### {Action}: {Step Name}
**Owner:** {Role}
**Time:** {Estimate}
**Details:** {What to do}
**Output:** {What this step produces}

## Owner Matrix
| Step | Owner | Backup | SLA |
|------|-------|--------|-----|
| {Step} | {Person/Role} | {Backup person} | {Time target} |

## Metrics
| Metric | Description | Target |
|--------|-------------|--------|
| End-to-end time | Total process duration | {Target} |
| Bottleneck step | Slowest step | {Target time} |
| Completion rate | % of processes completed successfully | {Target %} |

Output Formats

Markdown (Default)

• Works everywhere: GitHub, Notion, Confluence, VS Code, any text editor
• Supports checkboxes for checklists (- [ ] syntax)
• Mermaid diagrams render in GitHub, GitLab, Notion, and many editors
• Recommended for most use cases

HTML (Styled, Printable)

When the user requests HTML output or wants a printable version:

• Generate a self-contained HTML file with inline CSS
• Use brand colors if available, otherwise professional defaults
• Include print styles (@media print) for clean PDF output
• Add interactive checkboxes (JavaScript) for checklists
• Include a "Print" button in the header

Mermaid Diagrams

For process maps, always include a Mermaid flowchart:

• Use flowchart TD (top-down) for sequential processes
• Use flowchart LR (left-right) for pipelines
• Color-code: blue for triggers, green for success outcomes, yellow for warnings, red for failures
• Keep diagrams under 15 nodes — split into sub-diagrams if larger
• Include the diagram in both Markdown and HTML outputs

Brand Integration

Before generating any document, check if brand/brand.json exists.

If brand files exist:

• Read brand/tone-of-voice.md and adapt writing style:
• Formal brand → formal document language
• Casual brand → approachable but still clear instructions
• Technical brand → include more technical detail by default
• Apply brand colors to HTML output:
• Primary color → headings, table headers
• Accent color → checkboxes, highlights
• Background → page background
• Use brand terminology and vocabulary patterns
• Match the company's preferred naming conventions

If no brand files exist:

• Use clear, professional language
• Default tone: direct, specific, no jargon unless technical context requires it
• Use standard formatting without custom colors

Quality Standards

Every document generated must pass this quality checklist:

Content Quality

• [ ] Every step starts with an action verb (Configure, Deploy, Review, Send, Create, etc.)
• [ ] No ambiguous language — no "appropriately", "as needed", "if necessary" without criteria
• [ ] Decision points have explicit, measurable criteria
• [ ] Roles are assigned to every step and decision
• [ ] Time estimates are provided for each step
• [ ] Prerequisites are listed completely
• [ ] Failure/exception scenarios are handled
• [ ] Success criteria are defined and measurable

Structure Quality

• [ ] Document info section is complete (owner, date, version, review schedule)
• [ ] Logical flow — steps build on each other correctly
• [ ] No circular references — process has clear start and end
• [ ] Escalation path is defined with contacts
• [ ] Revision history is initialized

Usability Quality

• [ ] A new team member could follow this document without additional guidance
• [ ] Critical steps are clearly marked
• [ ] Rollback/recovery is documented for risky steps
• [ ] Related documents are linked
• [ ] Review schedule is set (documents must not go stale)

Writing Guidelines

Action Verbs for Steps

Use these to start every step:

Banned Phrases

Replace these vague phrases with specific instructions:

Time Estimate Guidelines