| name | process-docs |
| description | When the user needs to create SOPs, playbooks, runbooks, or other operational documentation that defines how a recurring process should be executed. |
| related | ["support-docs","board-update"] |
| reads | ["startup-context"] |
| tags | ["nontechnical","startup-founder-skills","process-docs","documentation"] |
-----|------------|-----|
| [Trigger] | [Person/Role] | [Timeframe] |
Success Criteria
How to verify the process was completed correctly.
Changelog
### Template 2: Incident Runbook
[Incident Type] — Runbook
Severity: [P0-P3]
On-Call Owner: [Role]
Last Tested: [Date]
Detection
How this incident is identified (alerts, customer reports, monitoring).
Immediate Actions (First 5 Minutes)
- Triage step...
- Communication step...
Diagnosis
Decision tree for identifying root cause.
Resolution Steps
Step-by-step fix for each known root cause.
Post-Incident
Checklist for after the incident is resolved.
### Template 3: Onboarding Playbook
[Role/Process] — Onboarding Playbook
Duration: [e.g., 2 weeks]
Buddy/Owner: [Role]
Day 1-2: Orientation
Tasks, access setup, key introductions.
Day 3-5: Core Training
Hands-on exercises, shadowing, tool walkthroughs.
Week 2: Guided Practice
Supervised execution of real tasks with checkpoints.
Graduation Criteria
What the person must demonstrate to be considered onboarded.
## Frameworks & Best Practices
- **The "bus factor" test.** If the person who usually runs this process is unavailable, can someone else execute it from this document alone? If not, add more detail.
- **Imperative voice only.** Every step starts with a verb. "Click the Deploy button" not "The Deploy button should be clicked."
- **One action per step.** If a step contains "and," split it into two steps. Compound steps get skipped or half-done.
- **Decision points are explicit.** Use if/then language with clear conditions. "If the customer is on an Enterprise plan, skip to Step 7" not "Handle enterprise customers differently."
- **Time estimates matter.** Include expected duration for each major phase. This helps people plan and signals when something has gone wrong (step taking 3x longer than expected = escalate).
- **Screenshots decay fast.** Prefer text descriptions of UI paths (Settings > Integrations > Slack) over screenshots, which break every redesign. Use screenshots only for genuinely complex interfaces.
- **Version and date everything.** A process doc without a last-updated date is assumed to be wrong.
- **Progressive detail.** Lead each section with a one-line summary, then expand. Experienced operators scan; new hires read every word. Serve both.
- **Link, don't duplicate.** If another SOP covers a sub-process, link to it rather than copying steps inline. Duplication causes drift.
- **Test with a newcomer.** The best review is having someone unfamiliar with the process follow the doc and noting where they get stuck.
## Related Skills
- `support-docs` — Chain when the process being documented is customer-facing and needs a corresponding help center article or troubleshooting guide.
- `board-update` — Chain when operational processes need to be summarized for investor or board reporting (e.g., "here is our incident response maturity").
## Examples
### Example 1: Operational SOP
**User:** "Write an SOP for processing customer refunds."
**Good output excerpt:**
> ## Procedure
> 1. **Open the refund request** in Zendesk. Verify the ticket includes: order ID, reason for refund, and customer email.
> 2. **Check eligibility** in Stripe.
> - **Decision point:** If the order is older than 30 days, escalate to the Support Lead with a note explaining the customer's situation. Do not process the refund.
> - If within 30 days, continue to Step 3.
> 3. **Issue the refund** via Stripe Dashboard > Payments > [Order ID] > Refund. Select "Full refund" unless partial was approved by the Support Lead.
> 4. **Update the ticket** with the Stripe refund ID and set status to "Solved."
> 5. **Log the refund** in the Refund Tracker spreadsheet (column A: date, B: order ID, C: amount, D: reason code).
>
> **Estimated time:** 5-8 minutes per refund.
### Example 2: Incident Runbook
**User:** "We need a runbook for when our payment processing goes down."
**Good output excerpt:**
> ## Immediate Actions (First 5 Minutes)
> 1. **Acknowledge the alert** in PagerDuty to stop re-escalation.
> 2. **Check Stripe Status Page** (status.stripe.com). If Stripe reports an outage, skip to "External Provider Outage" section.
> 3. **Post in #incidents Slack channel:** "Investigating payment processing failures. Updates every 15 min. DRI: [your name]."
> 4. **Enable the maintenance banner** via Admin > Feature Flags > `payment_maintenance_mode` = true. This shows users "Payments temporarily unavailable, please retry shortly" instead of raw errors.
