Open any support queue on a Friday and you'll see it.
The same question, again. "How do I export this?" "Where do I change the billing email?" "How do I add a teammate?" The agent has answered it forty times this week. They have a saved reply. They paste it, the customer says thanks, the ticket closes, and another copy of the same question is already three rows down.
Everyone treats this as a volume problem. So the fixes are all volume fixes. Answer faster. Write a better macro. Add a person when the queue gets long. Buy a bot that answers the easy ones so humans handle the hard ones.
Every one of those makes you better at answering the question. None of them makes the question stop.
The question behind the question
Jeanne DeWitt Grosser tells a story about a C-level exec staring at a mountain of support volume. The team assumed the brief was "how do we get AI to answer all these." That wasn't the brief. The exec's actual question was sharper: "Why are they calling, and how do I make it so that fewer people call the next week?"
Sit with the difference. One question optimizes the answer. The other removes the reason for the question.
A repeat ticket is not a task to clear. It's a coordinate. It tells you the exact spot in your product where a real person, trying to do a real thing, could not figure out the next step on their own. Forty copies of "how do I export this" is not forty tasks. It's one product problem, reported forty times, in the politest possible way.
For every ticket, ten people who didn't write one
Here's the part that should change how you read the queue.
Pete Kazanjy's rule from years of building sales and support teams: for every person who hits "Contact Us," there are probably ten more with the same problem who never said a word. They hit the same wall. They didn't file a ticket. They just gave up on that part of the product, or worse, on the product.
So the ticket you're annoyed to see for the fortieth time is the visible tip of something much bigger. Behind those forty tickets are maybe four hundred users who got confused at the same step and stayed quiet. The ticket is the good case. At least that person raised a hand.
This is why answering faster feels like progress and isn't. You're getting efficient at serving the 10% who complain while the 90% who don't are quietly churning at the exact same friction point.
What to do with the queue instead
So here's the move, and it's a Friday-afternoon exercise, not a reorg.
Pull your top five repeat "how do I" questions from the last month. Not the hard, account-specific ones. The boring, identical ones that have a saved reply.
For each one, go find the precise moment in the product where the user gets stuck. Not the help article. The screen. The button that isn't where they expect, the setting buried one menu too deep, the step that assumes knowledge a new user doesn't have.
Now you have a friction backlog. Five specific places where the product is generating its own support volume. Hand it to product as exactly that: not "users are confused," but "this screen produced 120 tickets and an estimated 1,000 silent give-ups last month." That framing gets funded. "Improve onboarding" never does.
Ian McAllister's brief at Airbnb is the goal worth holding: keep support quality high, but stop letting support cost scale linearly with the business. You don't get there by answering faster. You get there by making whole categories of question disappear.
Where this is heading
The honest version of "fewer people call next week" is help that arrives before the question forms. Guidance at the moment of confusion, in the product, so the user does the thing instead of stopping to ask how. Megan Cook describes how painful it is to watch someone "really struggle with something that you thought was going to bring them so much value." The fix for that is not a faster reply to the struggle. It's removing the struggle.
That's the gap we built Deway to close, guiding users through the sticky moment in real time so the question never becomes a ticket, and when a human is genuinely needed, your team gets the full context of what the user was trying to do. In our cases that deflects something like 40 to 60% of the repetitive "how do I" volume, though the right number for you depends on your product. But you don't need us to run the exercise above this week.
Pick your top five repeat tickets. Don't ask how to answer them faster.
Ask why your product keeps generating them, and what it would take for that question to never get asked again.
Alon Binman is the co-founder of Deway (deway.ai), an AI-native autonomous adoption layer for SaaS products. Before Deway, Alon spent 15+ years at the intersection of product and customer success, including roles as a Product Manager, founder, data and product strategy consultant, and Senior Solution Architect at Mixpanel. You can reach Alon on LinkedIn.