Suppose you have measured resolution from your call data rather than a survey, and you now know which topics bring customers back. The list is short — it usually is — and the next move feels obvious. Find the agents handling those topics, build some coaching around them, run it for a quarter. It is the standard response and it almost never moves the number, because it is aimed at the wrong thing. The repeat is rarely the agent's work. It is what happened after the agent's work. Repeat calls are a routing and ownership failure far more often than a skill failure.
Are your repeat calls an agent problem or a topic problem?
Before anyone designs an intervention, run the comparison that tells you where the cause actually lives.
Calculate your repeat rate two ways: grouped by agent, and grouped by topic. Callix computes both from the calls themselves, which is what makes the comparison cheap enough to run monthly. Then look at the spread within each grouping — not the averages, the variance.
If repeats are an agent capability problem, the agent grouping will be wide. Some people will be visibly worse than others, and the topic grouping will be comparatively flat because a good agent handles anything well.
What teams almost always find is the reverse. The agent grouping is tight — everyone is within a few points of everyone else — and the topic grouping is enormous, with two or three subjects producing repeat rates several times the rest. Agents with nothing in common, different tenures, different scores on your scorecard, all producing the same repeat rate on the same topic.
That pattern has one explanation. Whatever is causing the callback is downstream of the conversation and identical for everyone who touches it.
What actually causes repeat calls?
The structural causes are unglamorous and they recur across almost every operation.
- The promise nobody logged. An agent says they will get something sorted. They mean it. There is no field for it, so it lives in their memory and their memory is now handling the next call. The customer's clock starts at that promise; yours never starts at all.
- The callback nobody owned. It was assigned to a queue rather than a person, with no due time attached. A queue cannot be late, because nothing in the system knows when it was supposed to have happened. The customer finds out before you do.
- The answer that was right but incomplete. The agent correctly answered the question asked and did not address the situation behind it. The customer hangs up satisfied, discovers the second half of their problem an hour later, and calls back. Every quality check on that call passes.
- The resolution that needed someone else. The agent did everything available to them and handed off to a team whose queue depth they cannot see and whose turnaround nobody committed to. The handoff is where the case goes quiet.
Notice that in three of the four, the agent did their job correctly. There is no coaching content for doing your job correctly.
Everyone is within four points of everyone else. Two subjects are producing four times the repeat rate of the rest. The cause is downstream of the conversation, and coaching will not reach it.
Why does coaching a structural repeat make it worse?
This is the part worth being careful about, because the intervention has a cost beyond not working.
When you coach an individual for a repeat they did not cause, you teach them that repeats are attributed to them personally. People respond to that rationally. They become more reluctant to log the promise, more likely to close the case, less inclined to note the thing they were unsure about. Every one of those behaviours removes a signal you need in order to see the actual cause.
So the number improves slightly, the underlying rate does not, and your ability to diagnose it has quietly degraded. You have optimised the record rather than the operation, and you have made the next analysis harder than this one.
Fix the structure instead
- 1Make a promise a real object. If an agent commits to an action, it needs a record with an owner, a due time, and a state — created from the conversation rather than from an agent remembering to open another system afterwards. Almost everything else on this list is downstream of getting this one right.
- 2Give every callback a named person and a deadline. Not a queue. A queue distributes work and diffuses responsibility at the same time, and the second effect is stronger than the first.
- 3Route the topics that repeat to whoever can finish them. Some subjects cannot be resolved by the first person who answers, and no amount of skill will change that. Sending those to the team with the authority to complete them is worth more than any training on how to handle them gracefully.
- 4Put a clock on the internal handoff. If the case leaves the agent, the receiving team needs a committed turnaround that the agent can see and the customer can be told. Silent handoffs are the single largest source of the callbacks nobody predicted.
- 5Close the loop back to the customer. Most repeat calls are the customer chasing a status they were never given. A proactive update on the promised date removes the reason for the call entirely, which beats handling it well.
Where coaching does belong
One of the four causes is genuinely about the conversation: the answer that was right but incomplete. That one is fixable by changing what agents do on the call, so it deserves a real intervention.
But the fix is still not aimed at individuals. If a topic reliably produces incomplete answers, the gap is in what the organisation knows about that topic — the guidance is thin, the underlying process has an undocumented second step, the product genuinely is confusing at that point. Fixing it once, centrally, fixes it for everyone including the people you have not hired yet, which is the pattern in most of the operations we work with. Coaching it agent by agent fixes it temporarily for the people who attended.
Coach the topic, not the person. Repeat rate is a property of your operating model, and it responds to changes in the operating model rather than to changes in individual effort.
Where this reasoning stops: the whole argument rests on the variance test at the top, and it is possible to run it and get the other answer. A genuinely wide agent distribution with a flat topic distribution means the cause really is capability, and coaching is then the right instrument. Run the comparison before you decide which article you are reading, and re-run it after any change to routing, because a fix that works will show up as the topic spread collapsing rather than as a better average. If you want it run on your own calls first, start with a sample.