Your Ticket Queue Is a Defect Log
For years I ran support the obvious way: volume goes up, you hire. At WPML, where we answered around 5,000 support reports a month, the team reached forty people before it was clear that couldn't continue. And the more uncomfortable part: the work wasn't getting better, it was just getting absorbed.
The change that mattered wasn't a tool. It was a sentence: stop treating tickets as work to be cleared, and start treating them as a defect log.
If a human answers the same question twice, something upstream failed. A doc, an onboarding step, a confusing error message. A head of support who only measures how fast the queue clears will keep the queue clearing forever - and never make it smaller.
Three concrete things came out of that sentence.
Measurement before automation. We built an in-house analytics layer on top of our support data that classified tickets by underlying issue and ranked recurring problems by volume and by how expensive each one was to resolve. Before that, we had opinions about what we were drowning in. Afterwards we had a ranked list - and it wasn't the list anyone had predicted. I've never seen it be the predicted list, anywhere.
Ring-fenced improvement time. I stopped asking people to fix things "when the queue is quiet," because the queue is never quiet. Each week a defined share of the team's capacity came off the queue to work the top of that list: documentation, automation, or evidence handed to engineering.
Fixing things at the source. The highest-value items on the list usually weren't support problems at all. They were product problems wearing a support costume - and getting them fixed in the product needed data rather than an opinion, which is exactly what the first step had bought us.
I should be honest about the part that failed. The first version of protected improvement time quietly got eaten by the queue within a couple of months - because the team's instinct, which is a good instinct, is that a waiting customer beats an internal project. It only held once improvement work counted the same as queue work in how people were reviewed. And once I stopped being the first person to break the rule when things got busy.
We layered AI-assisted self-service on top of all this later, deliberately in that order. Automating an unclassified mess only makes the mess faster.
That's the lens I'd offer any support leader being handed an AI budget right now: your queue is already telling you what to build. The question isn't how fast you can answer it - it's how much of it should never have existed.