"Something went wrong. Please try again later."

That sentence is responsible for more support tickets than any bug, outage, or billing error in the history of software. Because it tells the user absolutely nothing. What went wrong? When should they try again? What if trying again doesn't work?

The user has two options: try again (which usually doesn't work because the error isn't transient) or contact support. About 30% of users who see a generic error message will submit a support ticket. The other 70% will just leave.

Both outcomes are bad. The ticket costs you $5 to $15 to handle. The silent departure costs you a customer.

The Math on Bad Error Messages

Take a common scenario. Your payment form has a validation error for expired credit cards. The error says "Payment failed." No additional context.

The user doesn't know why it failed. Was it their card? Your system? A temporary glitch? They try again. It fails again. Now they're nervous (is my card compromised?) and frustrated (why won't this work?).

About 40% of these users will contact support. The agent looks up the issue, sees the expired card, and tells the customer to update their payment info. That interaction took 5 minutes of agent time.

If the error message said "Your card expired in January 2026. Please update your card details or try a different card," the user would fix it themselves. No ticket. No 5 minutes of agent time. No frustration.

If 100 users per month hit this error, and 40 submit tickets at $10 per ticket, that's $400/month in support costs caused by a single bad error message. Fixing the message takes 15 minutes of developer time. The payback period is approximately one day.

What Good Error Messages Look Like

Good error messages answer four questions:

What happened. Not "something went wrong." What specifically went wrong. "Your card was declined" is better than "payment failed." "Your file is too large (25MB max)" is better than "upload error."

Why it happened (if knowable). "Your session expired because you were inactive for 30 minutes." "This email address is already registered." The "why" gives the user context to fix the problem.

What to do next. "Please log in again." "Try a different card or contact your bank." "Choose a file under 25MB." Give the user a clear action. If there's no action they can take, tell them what you're doing: "Our team has been notified and is working on a fix."

Who can help if self-service fails. "Still seeing this error? Contact us at [email] or chat with us." Always leave a path to a human. An error message with no escape hatch traps the user.

The Worst Offenders

"Something went wrong." Universal, meaningless. Could be a network error, a server crash, a validation failure, or a cosmic ray flipping a bit. This error exists because a developer wrote a generic catch block and moved on.

"Error 500." Technical status codes mean nothing to users. Most people don't know what a 500 is. Many assume it means they did something wrong.

"Invalid input." Which input? What's invalid about it? If a form has 8 fields and one is wrong, highlight the wrong field and explain why.

"Please try again later." When? In 5 minutes? Tomorrow? Next week? And will trying again actually fix it, or will the user get the same error?

"Contact support." This is the error message admitting defeat. It's saying "we can't tell you what happened, so call someone who might know." Every instance of "contact support" in an error message is a design failure and a direct support cost.

Error Messages as Proactive Support

The best error messages don't just explain the problem. They solve it.

"Your password must be at least 8 characters." That's an error message that prevents a support ticket. The user fixes it immediately.

"This coupon code expired on March 1. Here are our current promotions: [link]." That's an error message that prevents a complaint and might save the sale.

"Your file is 32MB. Maximum size is 25MB. Try compressing it with [tool] or [alternative upload method]." That's an error message that might prevent both a support ticket and a lost upload.

The pattern: error + explanation + solution + escape hatch. If you can't provide all four, provide at least the first two.

How to Find Your Expensive Errors

Look at your support ticket data. Search for patterns:

"I got an error" or "it didn't work" or "something went wrong" in ticket descriptions. These phrases almost always mean the user saw a generic error message. Count how many tickets per month include these phrases. That's your error message tax.

Group tickets by the page or feature where the error occurred. If 50 tickets per month are about the checkout page, and 30 of them describe a vague error, fixing the checkout error messages eliminates 30 tickets per month.

If you use Supp's classification, look at the intent distribution. "Technical issue" and "bug report" intents that turn out to be user-side errors (expired card, wrong password, browser issue) are often caused by bad error messages. The user thinks the product is broken because the error message didn't tell them otherwise.

The Developer-Support Feedback Loop

The fix requires collaboration between support and engineering.

Support agents see the impact: the same confusing error message generating 20 tickets per week. Engineers see the code: the generic catch block that needs a specific message.

The best setup: a shared channel (Slack, Linear, wherever) where support agents can flag specific error messages with the ticket volume they generate. "This 'payment failed' message on checkout generates ~15 tickets/week. Customers can't tell if it's their card or our system." That's a clear, data-backed request an engineer can prioritize.

Supp's intent classification automatically identifies when technical support tickets share a common root cause. If 30 tickets this week are classified as "payment error" and they all reference the checkout page, that's a signal. The analytics dashboard shows intent spikes, and a checkout error spike is actionable data for the engineering team.

One hour of engineering time to fix an error message saves 5 to 10 hours of support time per month. It's one of the highest-impact improvements a product team can make, and it almost never makes it onto the roadmap because nobody connects "bad error UX" to "expensive support tickets."

Make the connection. The savings are real.