The system already knew, in almost every case, exactly why a request had failed. The user reading the error message on screen usually did not, and that gap was generating a support ticket for every failure the code had already correctly identified.
What the error messages actually said
We audited every user-facing error string in the product — a few hundred of them — and found the majority fell into two categories: a raw technical message passed straight through from a lower layer, or a generic "something went wrong, please try again" that was true and useless.
The week's rule
No error message ships without answering three things: what happened, why it likely happened, and what the user can do about it right now. If an error cannot honestly answer all three, that is itself a finding — usually a sign the underlying failure needed a different design, not a better sentence.
- "Something went wrong" became specific failure reasons wherever the system actually knew one.
- Raw exception text was replaced with plain language, with the technical detail kept in logs for support, not shown to the user.
- Dead ends — errors with no possible next action — were flagged back to the product owner as gaps, not papered over with friendlier wording.
What this had nothing to do with
We deliberately kept this scoped away from any AI-generated support response or chatbot. The fix was upstream of that: if the system tells the user correctly and clearly what happened, most of them never need to ask anyone, human or model, in the first place.
The cheapest support ticket is the one that never gets opened because the error message already answered the question.
The number that justified the week
Support volume for the top ten most common failure types dropped by roughly a third in the following month, against a product that had not otherwise changed. Nobody on the support team believed a week of copywriting would move that number until it did.
What we would do earlier next time
Error message review is now part of our standard QA pass on every project, not a special initiative we run once something has clearly gone wrong. It is cheap to check continuously and expensive to fix retroactively across a codebase that has grown a few hundred error strings without anyone looking at them as a set.