Your Ticket Queue Is a Defect Log
Want to talk about this essay? Email me: amitkvint@gmail.comcopied· or message me on LinkedIn
For a long time, the natural response to a growing support queue was to grow the team with it.
That made sense at WPML. WordPress was growing quickly, more people were using WPML, and naturally that meant more people needed support. At our peak, we were handling around 4,000 support reports a month across roughly 30 supporters in the first, second and third tiers.
The approach worked. We kept up with the growth.
But at some point, I started wondering whether keeping up was really the same as improving. If the product keeps growing, and the answer to more support work is always more people, you can end up spending a lot of time dealing with the same problems over and over again.
That led to a change in how I looked at the queue: instead of seeing tickets only as work that needed to be answered, we started treating them as a source of information about what could be improved.
If a human has to answer the same question again and again, there is probably something upstream that could be better. Maybe the documentation isn't clear enough. Maybe onboarding is confusing. Maybe an error message isn't telling the customer what they actually need to know.
Once we started looking at support this way, three things became particularly important.
Measurement before automation. We built an in-house analytics layer on top of our support data that classified tickets by the underlying issue and ranked recurring problems by both volume and the effort they took to resolve.
Before that, we had plenty of opinions about what was taking up our time. Afterwards, we had an actual ranked list.
And it wasn't the list we expected. Honestly, I don't think these lists ever are.
Protected time for improvement. I stopped asking people to work on these problems “when the queue is quiet,” because the queue is almost never quiet.
Instead, we gave the team dedicated time each week to work on the top items from the list. Sometimes that meant improving documentation or building an automation. Sometimes it meant giving engineering enough evidence to look at a product problem.
This was harder to maintain than it sounds. Our first attempt at protected improvement time gradually disappeared into the queue after a couple of months. The team's instinct was understandable: if customers are waiting, you help the customers. An internal improvement project can always wait another day.
It only really started working when improvement work became part of how we measured people's contribution, alongside their normal queue work. And, just as importantly, when I stopped being the first person to cancel it whenever things got busy.
Fixing things at the source. Some of the highest-value items on the list weren't really support problems at all. They were product problems showing up in support.
That distinction mattered. Saying “customers keep asking about this” is useful, but it isn't always enough to convince a product or engineering team that something needs to change. Having the data to show how often it happened, how much support time it consumed, and what the underlying issue was made a much stronger case.
We added AI-assisted self-service later, deliberately in that order.
By then, we had a much better understanding of the queue, our recurring issues were documented, and many of the common problems already had defined resolution paths. That gave the AI something useful to work with.
It also made the role of AI much clearer. It wasn't there simply to make the support queue disappear. It was another way of reducing the amount of repetitive work that customers and supporters had to go through.
Looking back, the biggest change wasn't really about hiring, automation or AI. It was about changing what we thought a support ticket was.
A ticket isn't only a problem for a supporter to solve.
If enough customers are asking the same question, it's also a signal that something upstream might need attention.
Your queue is already telling you what to improve. The question is whether you're listening to it — or just trying to clear it.