Delivering Bad News: When You Can't Fix It (or Can't Fix It Fast)
Customer/User Communication for Support
Chapter 5 · Delivering Bad News: When You Can't Fix It (or Can't Fix It Fast)
Chapter 4 covered de-escalating someone already upset. This chapter covers a related but distinct moment: delivering news that's genuinely bad — the fix isn't coming quickly, or isn't coming at all. `backup1`'s own Chapter 9 covered the highest-stakes version of this, permanent data loss. This chapter covers the general skill underneath that specific case, for the far more common everyday version: a feature genuinely can't do what someone wants, a real fix is weeks away, a workaround is the best available answer.
Why Bad News Specifically Is Hard to Deliver Well
The instinct is to soften language until it becomes genuinely misleading — vague, hedging phrasing that lets the person believe something better is still likely, when it genuinely isn't. This is the same failure `backup1`'s own Chapter 9 warned against for data loss, generalized to every ordinary case of bad news a support technician delivers.
The Core Principle
State the bad news plainly and directly, without burying it in caveats or hedges that make the person think they misunderstood, or that more hope remains than actually does. Vague language doesn't prevent the bad news — it only delays the exact same outcome and adds confusion, or a second disappointment, on top of it.
A Structure for Delivering Bad News Well
- State what's actually true, early — not buried at the end of a long lead-up
- Explain why, briefly, if it helps — not to justify or over-explain defensively
- Offer what genuinely can be done — a real workaround, a partial fix, an actual alternative, not a hollow consolation
- Acknowledge once, sincerely — avoid over-apologizing to the point of sounding insincere or drawing out the discomfort longer than necessary
Why Delaying or Softening Backfires
The temptation to delay or soften bad news avoids an uncomfortable moment right now — but the discomfort doesn't disappear, it just gets deferred, and often compounds. This is Chapter 3's own "a stale expectation is worse than none" pattern, applied to bad news specifically: a softened message that later turns out to have been misleading adds a second injury on top of the original disappointment.
Worked Example: A Feature That Genuinely Isn't Possible
| Response | |
|---|---|
| Vague | "We'll look into what might be possible down the line..." |
| Direct | "That specific capability isn't something the system supports right now — here's what is possible instead: [genuine workaround]." |
The vague version leaves the door open to a hope that isn't real. The direct version closes that door honestly, while still offering something genuinely useful in its place.
Hands-On Exercises
Explain why vague, softened bad news is described as delaying rather than preventing the bad outcome, and why this often adds a second disappointment rather than avoiding one.
📄 View solutionExplain why this chapter connects delayed/softened bad news back to Chapter 3's own "stale expectation" reasoning, rather than treating it as an unrelated new problem.
📄 View solutionExplain why the chapter treats "we'll see what we can do" for a genuine "no" as the same category of dishonesty as backup1's own data-loss warning, rather than a harmless, lower-stakes version of a different problem.
📄 View solutionChapter 5 Quick Reference
- State bad news plainly and early — vague hedging delays the same outcome and adds confusion
- Structure: state what's true, explain briefly if it helps, offer genuine alternatives, acknowledge once sincerely
- Delaying or softening bad news defers discomfort rather than removing it — the same pattern as a stale expectation (Chapter 3)
- "We'll see what we can do" for a genuine "no" is the same category of dishonesty `backup1` warned against, just lower stakes
- Next: Chapter 6, choosing the right channel — written vs. verbal