Verified against ChatGPT · 2026-08-11
Escalate a customer bug report to engineering in the shape they can actually act on, without support's guesses passed off as findings
Converts a messy customer bug report into a clean escalation for engineering that clearly separates what's confirmed from what's assumed, so engineering doesn't waste a cycle chasing a guess dressed up as a fact.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Write an escalation of a customer bug report to engineering. Engineering needs to be able to act on this without a back-and-forth to figure out what's actually known versus assumed.
SYMPTOM DESCRIPTION
Users report that clicking 'Save Draft' on the invoice editor sometimes returns a success message but the draft doesn't appear in their list afterward.
REPRODUCTION STEPS KNOWN
Support reproduced it twice out of five attempts, only on accounts with more than 200 existing invoices; couldn't reproduce on a fresh test account.
AFFECTED CUSTOMERS
4 confirmed reports in the past week, all on accounts with high invoice volume; unknown how many unreported cases might exist.
SEVERITY SIGNAL
Customers are losing drafted work they believe was saved, which they only discover later — not a full outage, but a silent data-loss risk.
ENGINEERING TEAM CONTEXT
This will go to the invoicing team's on-call channel, who prefer a short summary up top before any detail.
Write the escalation with a hard separation between confirmed facts and support's working theory. Confirmed facts are only things directly observed — what the customer reported, what support was able to reproduce, what logs actually show if any were checked. Everything else — a guess about which system is involved, a suspicion about what changed recently, a theory about why it's happening — goes in a clearly separate section labeled as unconfirmed, so engineering can weigh it accordingly instead of chasing it as if support had already verified it.
State the reproduction steps exactly as known, including any gaps — if support could only reproduce it inconsistently or not at all, say so plainly rather than writing steps that imply more certainty than actually exists. State severity based on actual impact (data loss, blocked workflow, cosmetic) rather than how upset the reporting customer sounded, since escalation urgency should track what's actually broken, not how the ticket read emotionally.
WHAT NOT TO DO
Do not phrase an unconfirmed theory using language that reads as a confirmed finding ("the issue is caused by X" when X hasn't been checked — write "support suspects X, unconfirmed" instead). Do not pad the report with restated customer frustration that doesn't add technical information engineering can use.
OUTPUT FORMAT
1. Confirmed facts (symptom, affected scope, reproduction status).
2. Unconfirmed theories, clearly labeled as such.
3. Severity assessment with the reasoning behind it.
4. What engineering needs from support next, if anything, to move this forward.Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
The hard separation between confirmed facts and unconfirmed theory is the load-bearing instruction here because it counters a specific and costly failure mode in support-to-engineering handoffs: a support agent's working theory about the cause, once written in confident declarative language, gets treated by an engineer under time pressure as an established finding rather than a guess, and an engineering cycle gets spent chasing a lead that was never actually verified. GPT-5.1 will naturally smooth a bug report into confident, declarative prose because that reads as more competent and complete than hedged language — the explicit instruction to write unconfirmed theories as "support suspects X, unconfirmed" fights that smoothing tendency directly rather than hoping the model hedges on its own. Grounding severity in actual impact rather than how upset the reporting customer sounded matters because ticket language is a noisy signal for real severity — an emotionally heated ticket about a cosmetic issue and a calmly worded ticket about silent data loss carry very different real urgency, and a model asked to gauge severity from the raw ticket text alone will tend to weight tone over substance, since tone is the more salient textual feature. Stating reproduction gaps honestly, including inconsistent or failed attempts, prevents an escalation from implying a reliable repro exists when it doesn't, which would otherwise send engineering looking for a bug using steps that won't actually surface it.
What you get back
Confirmed: Save Draft occasionally returns success but the draft doesn't appear afterward; reproduced 2/5 attempts, only on accounts with 200+ existing invoices, not reproducible on a fresh test account; 4 confirmed reports in the past week. Unconfirmed (support suspects, not verified): a pagination limit on the drafts list query may be silently dropping results on large accounts — not checked against logs. Severity: high despite low report count — this is silent data loss customers discover later, not a visible outage. Needed from support: nothing further until engineering can check server logs for failed writes correlated with account invoice count.
Verified against
ChatGPT GPT-5.1 · 2026-08-11
Changelog
- 2026-08-11 — 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
