Customer-Impact Quantifier Prompt
Turn raw incident signals into a defensible estimate of how many users, which segments, and how much revenue are affected — so severity, comms, and prioritization are sized on impact instead of gut feel, and the response matches the real blast radius.
- Target user
- Incident commanders and on-call SREs sizing an active incident
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are an incident analyst estimating customer impact during a live incident. The team needs a fast, honest sizing of who and how much is affected, so severity and comms are proportional — not over-reactions and not dangerous under-reactions. Paste what you have: - The failing signal: [ERROR RATE / LATENCY / AFFECTED ENDPOINTS OR REGIONS] - Traffic and user context: [REQUESTS/SEC, ACTIVE USERS, TENANT/SEGMENT BREAKDOWN IF KNOWN] - What the failure blocks: [WHICH USER JOURNEYS OR FEATURES ARE DOWN OR DEGRADED] - Business context, if available: [REVENUE PER TRANSACTION, KEY CUSTOMERS ON AFFECTED PATH] Work through this: 1. **Define the affected population.** From the signals, state who is plausibly impacted — all users, one region, one tenant tier, users on a specific journey. Separate "confirmed affected" from "at risk downstream." 2. **Quantify with a stated method.** Estimate the number or percentage of affected users and, if data allows, affected transactions or revenue per unit time. Show the arithmetic and every assumption. Give a range, not a false-precise point value. 3. **Attach a confidence level.** Say how much to trust the estimate and what the biggest source of uncertainty is (e.g. "we don't know if retries mask the true failure count"). 4. **Translate impact into severity.** Map the quantified impact to the team's severity rubric (or a standard SEV1-4 scale) and state the severity this impact justifies — flagging if it is higher or lower than the current declared level. 5. **List the cheapest confirming queries.** Two or three read-only queries or dashboard checks that would tighten the estimate or refute it fastest. Output format: an "IMPACT CARD" with fields AFFECTED POPULATION, ESTIMATE (+range +method), CONFIDENCE, BIGGEST UNKNOWN, SEVERITY THIS JUSTIFIES, CONFIRMING QUERIES. Show your working for the estimate. Present the number as a hypothesis to verify, not a fact.
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
Why this prompt works
Half of a slow incident response is arguing about how bad it is. Without a shared impact number, teams either panic-escalate a minor blip or shrug off a major outage as “probably just a few users” — both of which cost MTTR, one by burning senior responders on nothing and the other by under-resourcing a real fire. The bottleneck is that turning scattered signals into a defensible impact figure is genuinely hard to do under pressure.
This prompt does that translation with its work shown. It forces a stated method and explicit arithmetic instead of a hand-waved percentage, separates confirmed impact from downstream risk, and gives a range with a confidence level so the number carries its own uncertainty. That honesty is what makes the estimate usable for a severity call: the team can see exactly which assumption to attack if the number feels wrong.
The guardrails guard against the specific danger of a quantified answer — false precision. A crisp “2% affected” is dangerously persuasive even when it is wrong, so the prompt labels every figure a hypothesis, surfaces the biggest unknown, and ends with the cheapest queries to confirm it. Impact sized honestly and verified fast is what lets the response match the blast radius, and a right-sized response is a faster one.
Related prompts
-
Game-Day Scenario Generator Prompt
Generate realistic failure-injection scenarios and a facilitation script to rehearse incident response on your actual stack — so the team's detection, triage, and mitigation muscles are warm before a real outage, cutting MTTR when it counts.
-
Recovery Validation Prompt: Gradual, Verified Restore After Mitigation
Turn 'the fix is in' into a staged, verified traffic-restoration plan with explicit health gates and abort criteria — so service comes back cleanly the first time instead of a premature all-clear that reopens the incident and doubles MTTR.
-
Mitigate-Now vs. Keep-Diagnosing Decision Prompt
In the middle of a live incident, decide whether to apply an available mitigation immediately or keep diagnosing for root cause — so you stop the customer bleeding at the earliest safe moment instead of chasing 'why' while the clock runs, cutting time-to-restore.
-
War-Room Role Assignment Prompt
When a major incident pulls a crowd into the bridge, assign clear roles — commander, comms, scribe, ops leads — from who is actually present, so coordination overhead stops eating MTTR and every workstream has a named owner instead of five people debugging the same thing.
More Reduce MTTR with AI prompts & error guides
Browse every Reduce MTTR with AI prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.