The Bad News Messenger: Draft Unwelcome Updates That Keep Trust Intact
Why this prompt matters
How a setback is communicated changes customer and employee retention more than the severity of the setback itself. A vague, hedge-filled message about a delay reads as a signal that something worse is being hidden, which is what actually pushes clients to start quietly evaluating alternatives — even when the underlying relationship was healthy going in. Internally, a rambling, defensive layoff or cancellation announcement is the version of the message that gets forwarded, screenshotted, and remembered for years after the actual decision is forgotten.
What we use it for
You are a product manager who just learned that the client-facing integration promised for Q1 is being pushed to Q3, because the two engineers who were building it got reassigned last week to an urgent security patch. You have to tell the client's VP of Operations today, by email, before she hears about the delay secondhand from your account executive during tomorrow's renewal call.
Prompt
You are a seasoned [SENIOR MANAGER / INTERNAL COMMUNICATIONS LEAD / TEAM LEAD] who has delivered hundreds of difficult updates — project delays, budget cuts, canceled initiatives, negative decisions — without losing the trust of the people receiving them. CONTEXT: - What happened: [DESCRIBE THE SITUATION PLAINLY — what changed, why, what you already tried before it got to this point] - Who is affected: [DESCRIBE THE AUDIENCE, e.g., "my 6-person engineering team," "an enterprise client who pays for priority support," "the whole company, ~200 people"] - Relationship context: [DESCRIBE THE CURRENT STATE OF TRUST, e.g., "generally strong, this is our first real setback together" or "already strained from a missed deadline last quarter"] TASK — complete all three steps, in order, without skipping the self-critique: Step 1 — DRAFT. Write the message delivering this news. Lead with the actual news in the first two sentences — do not bury it under context or preamble. State the concrete impact on the reader before explaining the cause. Include one specific, concrete next step or remedy, even if the remedy is only partial. Step 2 — SELF-CRITIQUE. Now switch roles. Read your own Step 1 draft as the most skeptical, least charitable person who could receive it. List every sentence that could read as evasive, overly corporate, defensive, or like it is minimizing the problem. Flag any place where the lede was buried or excuses were front-loaded before the actual news. Be specific about which words or phrases trigger each flag — do not just say "tone could be better." Step 3 — REVISE. Produce a final version that fixes every issue flagged in Step 2. Do not introduce new hedging while fixing the old hedging. CONSTRAINTS: - No corporate hedge language: ban phrases like "due to unforeseen circumstances," "moving forward," "we take this seriously," "at this time" - Name the actual cause plainly, even if it is an internal mistake - Apologize at most once, and only if someone on our side is actually at fault - Maximum 2 sentences before the core news is stated - Match this tone/formality: [E.G., "casual Slack message to my own team" OR "formal email to an enterprise client's VP"] - Target length: [E.G., "under 150 words" OR "under 300 words"] OUTPUT FORMAT: 1. Draft v1 (the message) 2. Self-Critique (bulleted list, each bullet quoting the exact flawed phrase and naming the specific problem) 3. Final Revised Version (ready to send as-is)
Result
Draft v1:
Subject: Integration Delay — Moving From Q1 to Q3
Hi Sarah,
I need to tell you that the client integration we committed to for Q1 is now going to ship in Q3 instead. Due to an unexpected shift in our engineering priorities, the two engineers assigned to your integration were moved onto a critical security patch last week, and we don't expect to have resources back on your project until April.
We understand this is frustrating and we take this delay seriously. We want to assure you that we remain fully committed to delivering a high-quality integration, and we will keep you updated as things progress. Please let us know if you have any questions, and thank you for your continued patience and partnership.
Best,
[Name]
Self-Critique:
- «Due to an unexpected shift in our engineering priorities» — this is a vague corporate hedge. It never names the actual cause (a security patch pulled the engineers away). Reads as evasive.
- «we take this delay seriously» — banned boilerplate phrase. Adds zero information and signals a template response.
- «We want to assure you that we remain fully committed» — generic reassurance with no concrete action attached. Sounds defensive rather than helpful.
- «we will keep you updated as things progress» — no specific date or mechanism given. Reads as a brush-off, not a commitment.
- «thank you for your continued patience and partnership» — the message closes by asking the client for patience instead of ending on a concrete remedy. This minimizes the real inconvenience to her Q1 plans.
- The actual news (Q1 to Q3) is stated but delayed by «I need to tell you that» throat-clearing — tighten the opening.
- No interim remedy is offered anywhere — the message describes the problem but gives Sarah nothing she can use in the meantime.
Final Revised Version:
Subject: Integration Delay — Moving From Q1 to Q3
Hi Sarah,
Your integration is moving from Q1 to Q3. The two engineers assigned to it were pulled last week onto an urgent security patch for existing customers, and that patch takes priority through April.
I know this affects your own Q1 commitments to your team, so here's what we can do in the meantime: I can get you a working sandbox build of the current integration state by January 15, so your team can start testing against it even though the full release waits until Q3. I'll also set up a bi-weekly 15-minute check-in starting next week so you're not waiting until Q3 to hear anything.
I'm sorry for the disruption this causes on your side — happy to get on a call today if that's more useful than email.
[Name]
Most advice about delivering bad news focuses on tone — be empathetic, be clear, be kind. That advice is correct and also useless on its own, because the people writing these messages already know they should sound empathetic and clear. What actually derails a difficult message is specific, nameable language: the hedge phrase that slips in because it feels safer, the excuse that gets front-loaded before the actual news, the vague promise to "keep you updated" that commits to nothing. This prompt is built around catching those specific failures rather than giving generic tone advice.
Why the self-critique step exists
Most AI writing prompts stop after producing a draft. This one forces a second pass where the model has to read its own output as the most skeptical possible recipient and name, in writing, every phrase that would make that recipient trust the message less. This works because an AI model drafting a message and an AI model critiquing a message are, functionally, running different evaluation criteria — the draft pass optimizes for "sounds professional and complete," while the critique pass optimizes for "would a skeptical reader believe this." Those two criteria often conflict, and corporate hedge language is exactly what satisfies the first while failing the second.
Why the constraints ban specific phrases instead of giving general guidance
"Due to unforeseen circumstances," "we take this seriously," and "moving forward" are banned by name rather than by category, because models (and humans) reliably reach for these exact phrases when asked to write something difficult — they are the load-bearing clichés of corporate bad news. Banning them by name forces the model to find the actual words for what happened, which is usually both more honest and more specific than the hedge it replaces.
Why useCase and whyItMatters are kept separate
The use case describes a single concrete scenario — a specific delay, a specific stakeholder, a specific deadline pressure. The "why it matters" argument is about the downstream cost of getting this wrong in general: damaged trust compounds silently, and a badly handled setback often causes more attrition than the setback itself. Keeping these separate is deliberate — a reader should be able to recognize their own situation in the use case while understanding the stakes from the second field, without the two repeating each other.
How to adapt it
The three bracketed fields — role, context, and audience — are enough to run this for almost any difficult professional message: a missed deadline, a budget cut, a canceled project, a negative performance review, even a personal apology that needs to stay specific rather than generic. The structure (draft, then skeptical self-critique, then revision) is the reusable part; the content is whatever difficult thing you actually need to say this week.