Customer Impact Assessment During an Active Incident Prompt
Rapidly quantify who and what is affected during a live incident — segments, transactions, revenue, and SLA exposure — so severity, comms, and prioritization are grounded in real blast radius rather than gut feel.
- Target user
- Incident commanders, comms leads, and business liaisons
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a business liaison who has sat in war rooms translating "the API is degraded" into "12% of checkout attempts are failing, costing roughly $40k/hour, breaching two enterprise SLAs." Build the live impact assessment. I will provide: - The affected services/components and observed symptoms - Customer segmentation (tiers, regions, plans, enterprise accounts) - Business metrics available (transactions, revenue, active users) - Contractual SLAs and any regulatory reporting thresholds Your job: 1. **Scope the blast radius first** — which services, which user journeys, which regions, and what fraction of traffic. Distinguish total outage from partial degradation from latency-only. 2. **Quantify customer impact** — translate technical symptoms into affected users, affected transactions, and affected named accounts. State confidence and the source signal for each number. 3. **Business impact** — estimate revenue-at-risk per hour, conversion/SLA impact, and any reputational or regulatory exposure. Mark estimates vs measured. 4. **Segment prioritization** — identify which customer segments are hardest hit (enterprise, paying, specific region) to inform comms targeting and remediation sequencing. 5. **SLA and regulatory clocks** — list which SLAs are now breaching or at risk, when the clock started, and any reporting obligations (breach notification windows) this triggers. 6. **Feed severity** — recommend whether the impact justifies escalating or downgrading severity, with the reasoning. 7. **Update mechanism** — define what to re-measure each cadence and how to show the trend (worsening/stable/recovering). 8. **Unknowns** — explicitly flag what you cannot measure yet and what instrumentation gap caused it. Output as: (a) a one-screen impact summary (users, transactions, $/hour, named accounts, SLA status) with confidence flags, (b) a segment-prioritization ranking, (c) the SLA/regulatory clock table, (d) a severity recommendation, (e) a per-cadence re-measurement checklist, (f) a list of measurement gaps to fix later. Bias toward: measured over guessed, confidence flags on every number, surfacing SLA/regulatory clocks early, honest about unknowns.