September 3, 2025
September 3, 2025
September 3, 2025
The 60% Drop: How We Silenced a Noisy Support Queue with Better UX
We often treat high support volume as a staffing problem, but it’s usually a design problem. Here is the story of how we fixed the product so the users stopped needing to ask for help.
We often treat high support volume as a staffing problem, but it’s usually a design problem. Here is the story of how we fixed the product so the users stopped needing to ask for help.
The slack channel for the support team was constantly pinging. It was a relentless, rhythmic drumbeat of frustration. Every ping was a user who was stuck, confused, or angry. The company thought they needed to hire three more support agents to handle the load. I told them to wait. I told them to let me look at the "Submit" button first.
Let’s look at the five most common mistakes and how to avoid them. The issue is rarely the algorithm itself—it’s how the technology is framed, introduced, and measured.
1. Starting with a tool instead of a problem
We looked at the tickets. Hundreds of them. And a pattern emerged that had nothing to do with the backend code crashing.
The pattern was anxiety.
Users were filling out a complex form—a loan application essentially—and hitting "Submit." And then... nothing. The page didn't refresh. There was no spinner. No "Success!" toast message. Just the static screen.
So what did the user do? They clicked again. And again. And then they panicked, wondering if their data was lost, and they opened a ticket: "Did you get my application? Is it working?"
We didn't rewrite the backend. We just added a loading state. We turned the button green. We added a simple animation that said, "We got it. You're good." That one change—acknowledging the user's action—wiped out 20% of the tickets overnight. Humans need validation. If your interface plays hard to get, your users will panic.
2. Killing the "Error 400"
Engineers write error messages for other engineers. They are descriptive, technical, and absolutely terrifying to a normal person.
This product was throwing generic "Bad Request" errors when a user typed a phone number with dashes instead of just digits. The system rejected it. The user saw "Error." The user assumed the site was broken.
We changed the logic.
First, we allowed dashes (because why not? Computers are smart, let them strip the formatting). But more importantly, we changed the copy. Instead of "Invalid Input," we made it say, "Looks like there's an extra dash in your phone number."
We stopped scolding the user and started coaching them. The ticket volume dropped again. It turns out, if you tell people exactly what is wrong in plain English, they can fix it themselves without emailing support.
3. We Burned the FAQ Page
I have a controversial opinion: FAQ pages are where good UX goes to die.
This company had a massive Help Center. It was well-written. It was comprehensive. And absolutely nobody looked at it. Users don't want to leave their workflow, open a new tab, search for a term, and read an article. They are in the moment. They want the answer now.
We took the top five questions from the support logs—questions like "What is my Merchant ID?" and "Where do I find my tax document?"—and we put the answers right next to the form fields.
Tooltips. Helper text. Micro-copy.
If a user pauses for two seconds on a field, a little note appears explaining what to do. We moved the solution to the problem. Suddenly, the questions stopped coming in.
The Aftermath
Three months later, the Slack channel was quiet. Not dead, just peaceful. The support team wasn't drowning anymore; they were actually able to do proactive work, like calling customers to see how they were doing, rather than just putting out fires.
The slack channel for the support team was constantly pinging. It was a relentless, rhythmic drumbeat of frustration. Every ping was a user who was stuck, confused, or angry. The company thought they needed to hire three more support agents to handle the load. I told them to wait. I told them to let me look at the "Submit" button first.
Let’s look at the five most common mistakes and how to avoid them. The issue is rarely the algorithm itself—it’s how the technology is framed, introduced, and measured.
1. Starting with a tool instead of a problem
We looked at the tickets. Hundreds of them. And a pattern emerged that had nothing to do with the backend code crashing.
The pattern was anxiety.
Users were filling out a complex form—a loan application essentially—and hitting "Submit." And then... nothing. The page didn't refresh. There was no spinner. No "Success!" toast message. Just the static screen.
So what did the user do? They clicked again. And again. And then they panicked, wondering if their data was lost, and they opened a ticket: "Did you get my application? Is it working?"
We didn't rewrite the backend. We just added a loading state. We turned the button green. We added a simple animation that said, "We got it. You're good." That one change—acknowledging the user's action—wiped out 20% of the tickets overnight. Humans need validation. If your interface plays hard to get, your users will panic.
2. Killing the "Error 400"
Engineers write error messages for other engineers. They are descriptive, technical, and absolutely terrifying to a normal person.
This product was throwing generic "Bad Request" errors when a user typed a phone number with dashes instead of just digits. The system rejected it. The user saw "Error." The user assumed the site was broken.
We changed the logic.
First, we allowed dashes (because why not? Computers are smart, let them strip the formatting). But more importantly, we changed the copy. Instead of "Invalid Input," we made it say, "Looks like there's an extra dash in your phone number."
We stopped scolding the user and started coaching them. The ticket volume dropped again. It turns out, if you tell people exactly what is wrong in plain English, they can fix it themselves without emailing support.
3. We Burned the FAQ Page
I have a controversial opinion: FAQ pages are where good UX goes to die.
This company had a massive Help Center. It was well-written. It was comprehensive. And absolutely nobody looked at it. Users don't want to leave their workflow, open a new tab, search for a term, and read an article. They are in the moment. They want the answer now.
We took the top five questions from the support logs—questions like "What is my Merchant ID?" and "Where do I find my tax document?"—and we put the answers right next to the form fields.
Tooltips. Helper text. Micro-copy.
If a user pauses for two seconds on a field, a little note appears explaining what to do. We moved the solution to the problem. Suddenly, the questions stopped coming in.
The Aftermath
Three months later, the Slack channel was quiet. Not dead, just peaceful. The support team wasn't drowning anymore; they were actually able to do proactive work, like calling customers to see how they were doing, rather than just putting out fires.
