The agent who left was one of the strongest on the team. Not the fastest typist or the one with the highest daily ticket count. The one who would write the reply that made a frustrated customer email back to say thank you. Eighteen months in, they handed in their notice. Not for a better salary. Not for a competitor. They were bored. Specifically, they were spending roughly sixty percent of every shift answering the same four questions, questions that a decent knowledge base article could have resolved before the customer ever opened a ticket.
I did not see it coming because I was tracking the wrong thing. I was watching ticket volume, first response time, and CSAT. Every number looked fine. The metric I was not tracking was the one that would have told me, months earlier, that I was quietly wasting my best people.
Why Good Agents Leave (and It Is Not Usually Pay)
A support role with a high proportion of genuinely complex tickets feels different from one dominated by repeat questions. In the first, agents make judgment calls, handle emotionally charged conversations, and solve problems nobody has documented a clean answer for. That is hard work, but it is meaningful work. It uses the skills that made someone good at the job in the first place.
In the second kind, the tickets keep arriving but the thinking mostly stops. An agent who has written the "how to reset your password" reply four hundred times is not getting better at support. They are getting practiced at copying text. The ones who thrive in that environment are often not the same people who are exceptional at the empathy and judgment work you actually need. The exceptional ones get bored, and then they start looking.
This is not a complaint about simple tickets. Tier-1 volume is real and necessary to handle. The problem is when simple tickets consume too large a share of the queue and there is no mechanism to catch it happening.
The Problem with Tracking Volume Alone
Eighty tickets closed in a day sounds the same whether those eighty tickets were genuinely hard or eighty were password resets and "where is my invoice." The number does not tell you anything about what kind of day your agents just had.
Average handle time makes it worse. A team that gets fast at repetitive tickets looks, on paper, like a high-performing team. In practice, they are a team that has optimized for volume at the expense of work quality. When you reward speed on simple tickets, you accidentally train agents to avoid the complex conversations they should be learning from.
The metric I was missing measures a different thing entirely: not how many tickets were handled, but how many of those tickets should never have needed a human at all.
The Repeat Question Rate: What to Measure and Why
I call it the repeat question rate, though some teams frame it as the KB deflection gap. The definition is simple: of the tickets closed this month, what percentage were questions your team had already written a documented answer to somewhere?
A ticket falls into this bucket if a KB article, a FAQ page, or an in-product tooltip already existed that a customer could reasonably have found and used to resolve the issue themselves. If it does not exist yet but the question has come in more than twice in the past 30 days, that counts too, as a signal of a coverage gap rather than a genuine complexity.
This is different from your self-service rate, which measures how many customers found the KB on their own. The repeat question rate measures the inverse: how much of your human agent capacity is being consumed by answered questions that nobody directed customers toward.
When the repeat question rate is high, your agents are writing the same knowledge base entry from scratch, in every individual reply, every single day. That is not support work. It is invisible documentation labor that burns out the people doing it.
- Roughly half of all tickets are repeat questions
- Agents write the same answers daily, from scratch
- Complex tickets wait behind high-volume simple ones
- Best agents feel underutilized and start looking around
- KB deflects simple questions before they become tickets
- Agents handle work that genuinely needs human judgment
- Repeat question rate tracked and reviewed monthly
- Experienced agents stay longer, morale improves
How to Calculate It Without Any New Software
You do not need a new tool for the first audit. Pull your last 60 days of closed tickets from whatever platform you use (Help Scout, Zendesk, Intercom, it does not matter). Export or review them in batches of 30 to 40.
For each ticket, ask one question: Did a documented answer already exist for this, or should one have? Mark it yes or no. You are looking for:
- Questions with an existing KB article that the customer clearly did not find
- Questions your team has answered the same way, in the same words, three or more times in the past month
- Anything your agents resolve by copying a paragraph they have memorized from memory rather than thinking through
Tally the yes count, divide by total tickets, and you have your repeat question rate. A rough baseline: if you're above roughly 40 to 50 percent, you have meaningful deflection work to do. Below around 20 percent is a reasonable steady-state, meaning most of what reaches your agents is genuinely worth their time.
For ongoing tracking: once a month, take a sample of 30 tickets from the previous period and run the same exercise. Track it in a spreadsheet. Watch the trend, not just the number.
What a High Rate Is Actually Telling You
A repeat question rate above roughly 40 percent tells you one or more of three things:
Your KB has coverage gaps. The questions are coming in because there is no written answer. This is the most actionable diagnosis because it has a direct fix: write the articles. Start with your top ten repeat question types, write a clear article for each, and re-measure in 30 days.
Your KB exists but is hard to find. The articles are written, but customers are not discovering them before they write in. This is a discoverability problem. The fix is getting the KB in front of customers at the moment they have the question, not after. Help Scout's Beacon, Zendesk Guide's widget, and Intercom's Fin all surface KB articles in context, before a customer clicks "contact support." That pre-contact moment is where the deflection actually happens.
Your KB exists and is findable but is not trusted. Some customers have tried the KB, it gave them an incomplete or wrong answer, and now they go straight to a human. This is a quality and maintenance problem. The audit in this post on KB rot covers exactly how to clean that up.
Three Things I Changed After Running This Audit
The first change was simple: I pulled every ticket tagged with our five most common repeat question types and assigned each one a paired KB article. If the article did not exist, someone on the team owned writing it that week. Within about 60 days, those five question types had dropped noticeably in volume.
The second change was surfacing the KB before customers could write in. We connected our Help Scout Beacon to show relevant articles based on the subject line and page context. It is not perfect, but a meaningful share of customers who would have submitted a ticket now close the conversation after reading the article instead. That is a direct reduction in the repeat question rate, and it is time the agent would have spent on something they had already answered dozens of times before.
The third change was adding the repeat question rate to my monthly metrics review alongside CSAT and response time. It sits next to the agent satisfaction pulse I now run quarterly. Both numbers tell you something about the health of the team, not just the health of the customer experience. They belong together.
The agent who left had been absorbing a 55 to 60 percent repeat question rate for the better part of a year. On paper, the team was doing fine. In practice, one of the best people on it was spending every day answering questions that had already been answered, with no signal to me that anything needed to change.
Track the metric. Your best people are telling you something with the tickets they close. Make sure you are actually listening to what those numbers say.
If you run this audit and want to compare numbers or talk through what you find, reach out here. I am happy to look at what you are working with.
Comments