Case study · Customer journey · Business case · UX
One webpage,
too many support calls.
Customers kept calling with questions, most of all whether the product would work with their device. I was hired to answer those calls. I ended up building the case for making them stop.
- 1
- webpage behind the calls
- €20K
- estimated yearly cost (calls × handling time × hourly cost)
- 1
- working prototype to make the case
Summary
Problem
One dense compatibility page kept generating support calls.
Solution
Clear categories, variant-level warnings, and a working prototype to make the case.
NoteEverything described here is accurate. For confidentiality reasons, product and system names and exact figures are deliberately generalised.
Context
A substantial share of the support calls weren't problems at all. They were enquiries: customers calling just to ask questions about the product, and above all the same one: will it work with my device?
The problem
The answer lived on a single page: a dense, technical list organised around internal logic, not around someone deciding whether to buy. No hierarchy, no warnings for the edge cases, such as device variants that look supported but aren't. The product was fine. The information architecture of one page wasn't.
What I found
I mapped the customer journey end to end:
- Search, land on the list, and assume their device is compatible.
- Buy the product.
- Discover it doesn't work with their device.
- Call support, frustrated.
Then I matched the calls in that category with the average handling time and an hourly cost. The result was a number, not a feeling.
What I proposed
- Clear categories instead of one long list.
- Warnings at the variant level for the devices that look compatible but aren't.
- A visual hierarchy that stops false confidence before the purchase, not after.
To make it concrete I built a working prototype: region selector, device search and a warning banner. The operational cost was around €20K a year; the cost you can't measure, trust and first impressions, was the real argument.
The problem was upstream, in the page itself. Messaging would only change the moment customers found out, not whether they called.
Outcome
Proposal presented internally with a full business case, stakeholder mapping and an implementation timeline.
What I'd do differently
Track calls by category from day one instead of reconstructing them afterwards. A live baseline would have made the case harder to dismiss, and let me present it sooner.
“The best fix isn't always a campaign. Sometimes it's a webpage.”