Your Support Queue Is a Defect Report
A tech support team escalates 20% of its tickets. Only some of them should be heading to the devs.
From what I saw, the escalation rate is the most misunderstood metric in tech operations. Every escalation is one of two things:
Someone in support could have resolved it. For example: missing access rights, missing knowledge, no written standard for what a complete answer contains. Another situation I saw was that the ticket landed with the wrong person because the routing ran on assumed specialty, instead of actual skills and workload. Those are defects in the support system, so the support manager is responsible for them.
Nobody in support could have resolved it because the software produced it. The answer lies in the code, in the data, or in a design decision made years ago. So the ticket climbs, level one to level two, then to level three. At the top of that ladder sits a maintenance team or a squad that inherited the codebase. Sometimes, it is nobody at all. Those are defects in the delivery system. You own them, and you almost never see them.
The diagnosis: 20%, filed as one team’s problem
A director looks at 20% escalation rate for his support team and reads competence. So, for him, it is time to put money into training, a tenth technician, or a better ticketing tool. But tickets from software issues keep coming in. They get answered, but they keep arriving. The critical point is that, in most of the cases, nobody upstream, in the development team, ever learns they existed.
I’ve learned this in banks, in energy, in public services. The support team absorbs a defect the builders never receive. That absorption even looks like a service. It is actually a broken feedback loop. It holds because the people who could close it are looking at a dashboard that does not contain it.
The countermeasure: two bins, then walk to the team that wrote it
Sort one month of escalations into two bins.
Bin one: fixable inside support. After a root cause analysis for each ticket, fix it with two things. First, a written standard for what a response must contain before a ticket closes. Then, within the team, ticket routing based on real skills and current workload instead of assumptions.
Bin two: what survives. Take it to the team that wrote the code. It has to land on their board as their own number; otherwise it reads as support complaining.
Do not treat bin one as the win. You clear it so you can see what is underneath. You cannot clearly read your support queue as a defect report (on your product) while that queue is still full of escalations about your support process. Clear bin one first. Then you will see that unglamorous, continuously updating list of things your software does to people. Most organizations have never produced that list once.
The case: what nine points bought, and what stayed
At an energy company, nine technicians handled billing software issues for business teams.
During the diagnostic, I found the following numbers: on-time resolution: 40%, escalation rate: 20%, client satisfaction: 7 out of 10. Looking at the actual ticket replies, I saw that 36% were unclear, incomplete, or missed the question. One client said he had explained his problem three times. Forty-four tickets sat unassigned, some for over a month. During an observation, I discovered that assignment ran on a supposed specialty, and nobody could see the queue ageing.
Everything we did was on the support side. We created quality standards for the responses. We ran a pull system instead of pushing tickets to people. We set up a visible board with every ticket, its age, and its owner. The one rule was that nothing sits unassigned for more than 24 hours (per our SLAs).
Three months later, the on-time resolution reached 68%. Escalations fell to 11%. Satisfaction moved to 8 out of 10. There was no headcount change.
Now, let me share the part I would do differently today.
Nine escalation points came out with the support-side work. So eleven points survived everything we did to that support system. Nobody sorted that residual. That was the defect report. Everyone was happy with 8 out of 10. Nobody asked what was left.
One caution before you go pull your own numbers. A support queue only shows you what customers bothered to report. It is not your whole quality picture. It is just the part that arrives already paid for by customers, in their own time.
In a tiered organization, a bin two escalation goes to a third line or a maintenance team. They didn’t build it. The builders never receive their own defects, so the behavior that produced it never changes. Tiers rebuilt the old wall between the people who write software and the ones who live with it. You build it, you run it was one answer to that wall.
Sort one month of your escalations into the two bins. If the second one is bigger than you expected, reply and tell me what you found.