Verified against ChatGPT · 2026-08-14
Write the narrative behind this week's support metrics instead of restating the numbers back in sentence form
Turns a raw metrics pull into a short weekly review narrative that explains what actually moved and why, checked against known confounders, so the writeup drives a real decision instead of narrating a dashboard.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Write the narrative for this week's support metrics review. I don't need the numbers restated in sentence form — I need the explanation of what moved and why, and what decision it points to. RAW METRICS First response time: 2.1 hrs (up from 1.4 hrs last week). CSAT: 91% (flat). Ticket volume: 340 (up from 210, +62%). Backlog: 18 tickets open >48 hrs (up from 3). COMPARISON PERIOD Previous week, a normal non-holiday week with no known incidents. KNOWN CONFOUNDERS Two of our five support agents were out on planned leave this week; a product update shipped Tuesday with a known, since-fixed bug affecting checkout. AUDIENCE FOR REVIEW The support team lead and the head of CX, in a Monday staffing review. DECISION THIS SHOULD DRIVE Whether to bring in temporary contract support for the next two weeks or absorb the backlog with current staffing. Lead with what actually changed relative to the comparison period, not a full recap of every metric — if something is flat and unremarkable, it does not need a sentence, since a review that gives equal airtime to a flat metric and a genuinely moved one buries the signal the audience actually needs. For whatever moved, check it against the known confounders given before treating it as a real trend — a metric that shifted because of a known one-off event (a holiday, a known outage, a staffing gap) is a different finding from the same shift with no such explanation, and conflating the two either overreacts to noise or misses a real pattern by explaining it away too easily. State the actual decision this points to, using the given context on what decision is needed — a metrics narrative that ends in "this is worth monitoring" without committing to what should actually happen next isn't useful to an audience that has to decide something this week. WHAT NOT TO DO Do not present a percentage change without also stating whether the underlying volume is large enough for that percentage to mean anything — a 50% jump on a metric with only 4 total instances of the underlying event should be framed very differently from a 50% jump on a metric with 400. Do not editorialize with confidence beyond what the metrics actually support. OUTPUT FORMAT 1. What actually moved, in plain language, with the confounder check applied. 2. What stayed flat (one line, not per-metric detail). 3. The recommendation for the stated decision.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Instructing the model to lead only with what actually moved, and to give flat metrics one line rather than per-metric detail, counters GPT-5.1's default reporting instinct, which is completeness — asked to write a metrics narrative, it will typically walk through every given metric in turn because that feels like thorough coverage, when a genuinely useful weekly review is supposed to compress attention onto what changed, not distribute it evenly across everything measured. Requiring the confounder check before treating any shift as a real trend is the single most important mechanism here, because raw metrics are silent about cause — a 62% jump in ticket volume and a spike in backlog look, from the numbers alone, like a genuine service breakdown, but checking it against the known context (two of five agents on planned leave, plus a since-fixed checkout bug) reframes the same numbers as a mostly explainable, temporary situation rather than a systemic capacity problem, and a model not explicitly told to check this will narrate the raw shift with alarm regardless of whether a known, mundane explanation already accounts for most of it. The instruction against reporting a percentage without its underlying volume addresses a specific, very common way metrics narratives mislead: a percentage change is scale-blind on its own, and stating "backlog up 500%" sounds dramatically different from "3 tickets became 18," even though both describe the same actual number — grounding the percentage in the raw count keeps the audience's sense of scale accurate rather than borrowing false urgency from a big-sounding ratio.
What you get back
What moved: ticket volume rose 62% (210 to 340) and backlog rose from 3 to 18 tickets over 48 hours — but two of five agents were on planned leave this week and Tuesday's product update introduced a checkout bug (since fixed) that likely drove a real chunk of this volume; this looks like a mostly explainable, temporary spike rather than a new baseline. Flat: CSAT held steady at 91% despite the volume increase, which suggests service quality didn't degrade even under the added load. Recommendation: bring in temporary contract support for one week, not two, given that the checkout bug is already fixed and one of the two absent agents returns Monday — a shorter bridge should be enough to clear the backlog without overcommitting to contract coverage the numbers don't yet justify for a full two weeks.
Verified against
ChatGPT GPT-5.1 · 2026-08-14
Changelog
- 2026-08-14 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
