Verified against ChatGPT · 2026-08-09
Build a service recovery plan for a high-value account after a failure that isn't just a bigger apology
Produces a service recovery plan scoped to what actually broke trust for this specific account, distinguishing a genuine structural fix from a goodwill gesture, so a valuable relationship doesn't get patched with a discount that doesn't address why it broke.
The prompt
Ready to copy — highlighted parts are example details you can swap.
A high-value account had a real service failure and the relationship needs active recovery, not just a follow-up email. Build me a recovery plan. WHAT WENT WRONG A batch job silently failed for three days, so the customer's dashboard showed flat numbers and their exec team presented stale figures in a board meeting. ACCOUNT VALUE $340k ARR, our third-largest account, up for renewal in four months. RELATIONSHIP HISTORY Previously a reference customer; this is the first serious issue in two years, so the account team is worried about losing that goodwill. RECOVERY BUDGET Up to one month of service credit and 5 hours of a solutions engineer's time; no contract term changes without legal sign-off. NON-NEGOTIABLES Cannot commit to a specific uptime SLA number that isn't already in their contract. Start by naming, in one sentence, what specifically broke trust here — not the technical failure itself, but what it implied to the customer (that they were deprioritized, that we don't test before shipping, that nobody was watching). A recovery plan aimed at the technical failure alone will miss the actual thing that needs repairing if the customer's real objection was about being deprioritized rather than about the bug itself. Then build the plan in three parts: what gets fixed so this specific failure can't repeat, what gets communicated so the customer understands the fix is real and not just words, and what, if anything within budget, acknowledges the disruption without implying the relationship is being bought back with a discount — a gesture that isn't paired with a credible fix reads as an attempt to smooth things over rather than actually address them. WHAT NOT TO DO Do not propose anything outside the stated recovery budget or that violates a stated non-negotiable. Do not recommend a generic loyalty gesture (a public shoutout, a swag package) for an account whose complaint was about reliability, not affection — match the gesture to what was actually damaged. Do not write a plan that requires the customer to do work to receive the recovery (filling out a survey, scheduling a call) unless that step is the actual mechanism of the fix itself. OUTPUT FORMAT 1. One sentence: what actually broke trust. 2. The fix (what changes so it can't repeat). 3. The communication (what the customer is told and by whom). 4. The gesture, if any, and why it fits what was damaged. 5. A one-line risk flag if any part of this plan could backfire.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Naming what broke trust as a distinct first step, separate from the technical incident, targets a specific and common miss in recovery planning: the failure people describe (a batch job, a bug, a delay) is rarely the actual injury — the injury is almost always something relational (being deprioritized, being embarrassed in front of their own stakeholders, losing confidence that anyone is watching) that the technical description doesn't capture on its own, and a model asked to plan recovery without being told to separate these two things will default to matching the plan to the visible technical failure because that's the part stated in the most concrete language. The explicit ban on generic loyalty gestures addresses GPT-5.1's tendency to reach for a stock goodwill move (a discount, a thank-you gift, an executive check-in call) regardless of what the complaint actually was, because those are the most frequent patterns in its training data for "customer relationship repair" — forcing the gesture to be justified against what was specifically damaged prevents a mismatch that would read to a sophisticated enterprise buyer as generic and slightly insulting. Requiring the plan to stay within budget and non-negotiables rather than proposing an ideal-world plan matters because a model will otherwise produce a recommendation that sounds generous and complete but that the person running this prompt has no actual authority to execute, which just creates a second problem when it has to be walked back internally before it ever reaches the customer.
What you get back
What broke trust: the customer's exec team believes we let them look unprepared in front of their own leadership, not just that a job failed. Fix: add an automated alert on batch-job completion status visible to their account team, not just internal engineering, so a silent failure is caught within the hour next time. Communication: their solutions engineer walks the exec sponsor through the new alert live, rather than sending a written summary. Gesture: one month of service credit, framed as tied to the outage window specifically, not as a general goodwill discount. Risk flag: offering credit without the live walkthrough first could read as trying to close the issue with money before demonstrating the fix is real.
Verified against
ChatGPT GPT-5.1 · 2026-08-09
Changelog
- 2026-08-09 — 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
