Fictional acceptance demo
Sample runbook
Illustrative workflow documentation with owners, approval gates, and evidence.
All records, dates, run IDs, and evidence labels on this page are fictional. They demonstrate the acceptance model and are not implementation proof.
Draft-first by default. External actions remain blocked until approved.
Runbook metadata
Runbook ID: RBK-LEAD-01
Workflow: Lead intake → follow-up pack
Risk: Low
Version: v1.0
Approval gate: Required before external release
Last updated: 15 Feb 2026
Inputs & outputs
Inputs: Lead form, inbox request, CRM entry
Outputs: Draft follow-up, task pack, CRM update
Tools & SLA
Tools: Notion, Google Workspace, Slack, CRM
SLA: Draft within 30 mins. Approval within 4 hours.
Exception handling
- If approval missing, set status to Blocked
- If data risk detected, trigger kill switch
- Escalate to owner with evidence links
- Pause conditions: missing approval, data risk, client request
- Rollback: revert last change and log incident note
Needs approval
External sends are blocked until the owner approves. Reason and evidence are recorded in the audit trail.
Steps
Step 1 — Capture request
- Owner
- Ops
- Control point
- Validate request + assign owner
- Evidence captured
- request link + run ID
- Exception path
- missing context → status Blocked
Step 2 — Generate draft output
- Owner
- Ops
- Control point
- Draft-only, no external sends
- Evidence captured
- draft link + change note
- Exception path
- low confidence → route to owner
Step 3 — Route for approval
- Owner
- Client owner
- Control point
- Approval required before execute
- Evidence captured
- approval note + timestamp
- Exception path
- approval timeout → reminder + escalate
Step 4 — Execute approved action
- Owner
- Ops
- Control point
- Execute only approved scope
- Evidence captured
- change log entry + evidence link
- Exception path
- execution error → pause + rollback path
Step 5 — Review and update runbook
- Owner
- Ops + owner
- Control point
- record changes + update runbook version
- Evidence captured
- updated runbook link + sign-off
- Exception path
- repeated exceptions → revise controls
Evidence
| Time | Run ID | Step | Owner | Control | Evidence |
|---|---|---|---|---|---|
| 09:18 | wf_20260215T0918Z | Draft created | Operaitions | Draft | Draft doc |
| 09:29 | wf_20260215T0929Z | Approval recorded | Client owner | Approved | Approval note |
| 09:33 | wf_20260215T0933Z | Executed update | Operaitions | Approved | Change log |
| 09:34 | wf_20260215T0934Z | Exception handled | Operaitions | Exception | Incident note |
Change log
| Date | Change | Approved by | Reason |
|---|---|---|---|
| 15 Feb 2026 | v1.0 created | Operations lead | Baseline runbook |
| 16 Feb 2026 | Added rollback path | Client owner | Exception readiness |
| 17 Feb 2026 | SLA clarified | Operations lead | Delivery consistency |
Current product
See how these controls apply to lead follow-up.
Lead Follow-Up Control uses the same principles: named ownership, explicit state, human-controlled sending, evidence, and a dated next action.