📊 Quantifying Customer and Business Impact in a Postmortem With AI

The single most consequential line in a postmortem I reviewed last year read: “A number of users experienced degraded service for a period of time.” That sentence got the action items deprioritized for two quarters. When the same failure recurred—this time during a sales demo to an enterprise prospect—someone finally did the math: the original incident had cost roughly $40,000 in SLA credits and burned eighty percent of the quarter’s error budget for the API. Had that been written down the first time, the fix would have shipped in week one. Vague impact isn’t humble. It’s negligence with good manners.

The impact section is the part of a postmortem most likely to be hand-waved, because doing it properly means joining metrics, contract terms, and arithmetic that nobody wants to do at the end of a long incident. This is exactly the tedium AI should absorb—while you keep your hands firmly on the inputs and the sign-off.

The four numbers that change decisions

A serious impact section answers four questions, and “some users for a while” answers none of them.

How many users, really. Not total accounts—affected accounts during the window. If 38% of checkout requests failed for 22 minutes and you served 11,000 checkout attempts in that window, that’s roughly 4,180 failed attempts across some smaller number of distinct users. The distinction between requests and humans matters; a retry storm inflates request counts.

Error-budget burn. If your API SLO is 99.9% over 30 days, you get about 43 minutes of full-downtime budget per month. A 22-minute partial outage at 38% error rate burns roughly 22 × 0.38 ≈ 8.4 budget-minutes—about a fifth of the month’s allowance from one incident. That framing turns “minor blip” into “we cannot afford three of these.”

SLA credits owed. This is contractual, not optional. If enterprise contracts promise a 10% monthly credit when uptime dips below 99.9%, and the outage pushed three customers below that line, you owe credits whether or not anyone files. Surfacing this in the postmortem is how finance stops being blindsided.

Dollars. Lost transactions, credits, and engineering hours. Even rough bands (“$30k–$50k”) beat silence, because money is the unit leadership prioritizes in.

A prompt that does the arithmetic without inventing it

The risk with AI and numbers is hallucinated precision. The guardrail is simple: give it only real inputs, forbid it from inventing any, and make it show its work so you can check every step. Here’s the prompt I use:

You are computing the impact section of a postmortem. Use ONLY the
numbers I provide. If a number is needed but missing, write
"NEEDS INPUT: <what>" — never estimate it yourself.

Given:
- Incident window: <start> to <end> (compute duration)
- Error rate during window: <%>
- Requests served in window: <count>
- Distinct affected users (if known): <count or unknown>
- SLO target: <e.g. 99.9% over 30 days>
- SLA terms: <e.g. credit 10% if monthly uptime < 99.9%>
- Affected customers near/below SLA threshold: <list or unknown>
- Avg revenue per successful transaction: <$ or unknown>

Produce:
1. Duration in minutes (show the subtraction).
2. Failed requests = requests × error rate (show it).
3. Error-budget minutes burned vs. the monthly budget (show the formula).
4. Estimated SLA credits owed, per affected customer.
5. Revenue-at-risk band, stated as a range, with assumptions listed.
Flag every assumption explicitly. Round sensibly. No invented figures.

Notice what this does: it refuses to fabricate. If I don’t know distinct users, it returns NEEDS INPUT: distinct affected users instead of guessing 4,000. That refusal is the whole point—an impact number nobody can defend is worse than an honest gap, because the first time someone catches one invented figure, they stop trusting the entire document.

What a good AI-drafted impact section reads like

Fed real inputs, the model returns something I can drop in after a human verification pass:

Impact The checkout API returned errors for 22 minutes (14:14–14:36 UTC). At a 38% error rate against 11,000 attempted checkouts, roughly 4,180 checkout attempts failed, affecting an estimated 2,900 distinct users (after de-duplicating retries).

This burned approximately 8.4 minutes of the API’s 43-minute monthly error budget (99.9% SLO)—about 20% of the month’s allowance from a single incident.

Two enterprise customers (Northwind, Globex) dropped below their 99.9% contractual threshold for the month, triggering 10% service credits estimated at $12,400 combined. At an average of $46 per completed checkout, lost transaction revenue is in the $18k–$24k range. Total estimated impact: $30k–$36k, excluding engineering response hours.

Every figure traces to an input I supplied. The model did the joins and the multiplication; I supplied the contract terms and verified the failover math. That division of labor is the whole game.

Keep the human on the contract and the conscience

Two things the AI must never own. First, the contract interpretation—SLA language is full of carve-outs (planned maintenance windows, force majeure, measurement methodology) that a model will cheerfully ignore. Read the actual clause. Second, the honesty of the framing: it’s tempting to quietly pick the rosiest band, and a model will happily anchor wherever you nudge it. Resist. The impact section is the part of the postmortem that earns trust or destroys it, and trust is the only currency a postmortem trades in.

I keep this prompt with the rest of my incident-math snippets in the prompts library, and the broader approach to writing reviews people actually act on is in the blameless postmortem guide. For more on turning incidents into decisions instead of paperwork, the postmortems category has the rest of the series.

Put a real number on it. The number is what makes the fix get funded.