Escalation Metrics Should Ask If the Escalation Was Needed

Escalation metrics are the numbers a team uses to judge how tickets move from support or operations to engineering. We think the standard set is useful but incomplete, because every one of them can look healthy on an escalation that should never have been raised.

The missing measure is necessity. Without it, support and engineering argue from anecdotes about which side is wasting the other's time, and neither can show the other a number.

This post covers what today's escalation metrics capture, why circulating percentages are weak evidence, how to measure answerability rate with a small sampled review, the three buckets the review produces and what to do when the actionable bucket is large.

The Support Queue Everyone Argues About and Nobody Measures

In most growing software companies the boundary between support and engineering is a source of friction. Support says engineering is where tickets go to wait. Engineering says the queue is full of questions that are not bugs.

We have heard both sides make good points, usually without data. Engineering remembers the three tickets last week that turned out to be configuration questions. Support remembers the five days of silence on a blocker for a large customer.

Both memories are real, and neither settles anything. Until a team has a shared definition of a necessary escalation, the argument repeats every quarter with new examples.

Standard Escalation Metrics Measure the Handoff, Not the Need

The common escalation metrics focus on logistics. Unito's guide to ticket escalation metrics lists twelve, from time to escalate and handoff delay to bounceback rate, priority mistranslation, repeat escalation rate and SLA breaches on escalated tickets. Its foundation metric is escalation rate, escalated tickets divided by total tickets.

We think that list is a good map of where handoffs break. It shows when context is lost between tools, when priorities change in transit and when tickets bounce back for missing logs.

What it cannot show is the value of the trip. A fast, fully synced handoff with every field filled in still costs an engineer an interruption if the asker could have answered the question alone.

• Escalation rate tells you how many tickets crossed the line, not how many needed to.
• Handoff delay tells you how long a ticket waited, not if it should have waited for engineering at all.
• Bounceback rate tells you the ticket was incomplete, not that the question was outside support's reach.

Google's SRE book treats tickets as one of three kinds of operational load, alongside pages and ongoing operational work, in its chapter on dealing with interrupts. The frequency of interrupts is one of the factors it lists for deciding how to handle them, and unnecessary escalations add to that frequency without adding work only engineers can do.

Unsourced Escalation Percentages Harden Into Industry Facts

Because few teams measure necessity, they borrow numbers. One AI support vendor, Zipchat, publishes a breakdown in which answerable technical questions are an estimated 50 to 60 percent of engineering escalations, and a sample distribution in which 78 percent are answerable from the codebase.

We are not saying those figures are wrong. The vendor labels them as estimates, and they appear next to a product built to reduce them. The problem is what happens after a few retellings, when the word estimated drops out and a team sets targets against a number nobody in the room measured.

Your own sample of thirty tickets is better evidence for your queue than any published average. It also tells you which questions are answerable, which a percentage never does.

Answerability Rate Is the Escalation Metric That Asks Why

We define answerability rate as the share of closed escalations in a period that reviewers judge could have been resolved with evidence the asker already had or could reasonably have been given. It is measured by review, not by a ticket field, because only a person who sees the resolution can judge what would have been enough.

The review needs to be light enough to keep doing. A team that reviews every ticket stops after two months.

• Sample Instead of Reviewing the Whole Queue

Draw a random sample of 20 to 30 closed escalations each month. Random matters, because hand-picked tickets will confirm whatever the picker already believes.

We would stratify only by severity, so that a rare high-severity escalation is not lost among routine questions.

• Review Every Ticket From Both Sides

Each sampled ticket gets two reviewers, one from engineering and one from support or operations. Each records, separately, what evidence would have been sufficient to resolve the ticket and if the asker had access to it.

Recording separately before comparing keeps the louder reviewer from setting the answer.

• Treat Disagreement as a Finding

When the engineer says the ticket was answerable and the support reviewer says the data was not available to them, the review has found something concrete. It is usually a missing article, a dashboard support cannot open or a log only engineers can query.

We log those disagreements as their own list. Over a few months it becomes the best backlog the team has for reducing interruptions.

• Compute the Rate and Keep the Notes

The rate itself is simple. Divide the escalations judged answerable by the number reviewed. The notes on which evidence was missing are worth more than the percentage, so keep them with the result.

1. Pull the random sample on the first working day of the month.
2. Give both reviewers the full ticket thread and the resolution.
3. Have each record the sufficient evidence and the asker's access independently.
4. Compare, resolve or log disagreements, and assign each ticket to a bucket.
5. Report the rate, the bucket split and the top three missing pieces of evidence.

Three Buckets Every Reviewed Escalation Falls Into

The review sorts escalations into three groups. We have found that the split matters more than the overall rate, because only one bucket responds to engineering investment.

1. Answerable With Existing Evidence

The asker had what they needed and did not find it. This is a search, documentation or training problem. Engineers often expect this bucket to be the biggest, and in our experience it is usually smaller than they think.

2. Answerable With Evidence the Asker Could Not Reach

The answer existed, but in logs, traces, deploy history or feature flag state that only engineers can query. This is the actionable bucket. Engineering can shrink it by exposing that evidence safely, and every ticket removed from it is an interruption that stops recurring.

3. Genuinely Needs Engineering

The ticket revealed a new bug or required a code change. This is the operational floor. Driving it to zero is the wrong goal, since a team with no bucket three escalations is probably hiding bugs rather than lacking them.

Make the Metric Shared So It Does Not Become a Blame Tool

Answerability rate carries a political cost. Framed badly, it looks like a scorecard engineering uses to complain about questions from support. That framing kills the review within a quarter.

We make it jointly owned from the start. The finding is never that support should try harder. A high share in bucket two is a requirement on engineering to make evidence reachable, and a high share in bucket one is a shared documentation task.

Reporting the bucket split rather than a single score helps. It is hard to read three buckets as an accusation when two of them describe gaps in tools and knowledge.

When the Latent-Evidence Bucket Is Large, Fix Access

If bucket two dominates, the fix is access, not process. Most teams withhold evidence from non-engineers by default, out of reasonable concern about production access and its side effects. We wrote about one of those side effects in read-only production access as a capacity change.

Four kinds of evidence close most bucket two tickets when they are exposed read-only.

• Error signatures with occurrence counts, so support can see if a customer's error is new or common.
• Recent deploys touching the affected service, so a regression can be named rather than guessed.
• Feature flag state for the affected account, so support can see what the customer actually sees.
• Scope of impact, showing if the problem is isolated to one account or spread across many.

The answer should also be captured once it is found. The Knowledge-Centered Service practices note that "The words and phrases we use to search are candidate content for improving existing KCS articles or creating new KCS articles," in their technique on searching is creating. A bucket two ticket that ends without an article will come back.

Some teams go further and let people ask production questions directly, using agents that answer a question from Slack with the evidence cited. Whatever the mechanism, the test is the same, which is if next month's sample has fewer tickets in bucket two.

When Answerability Rate Is Not Worth Measuring

We would not start this review everywhere. A team that receives only a few escalations a month gets more from reading all of them together than from sampling and scoring.

It also adds little when nearly every escalation is a genuine bug, as in an early product with frequent releases. And it can backfire in an organisation where support and engineering already distrust each other, since a new metric will be read as a weapon before it is read as a tool. In that case, we would fix the shared ownership first and measure later.

Add One Escalation Metric That Asks About Need

Keep the escalation metrics you have. They show where handoffs break. Add answerability rate as the one measure that asks if the handoff should have happened, and report it as a bucket split from a small, two-sided monthly sample.

The number to watch over time is bucket two as a share of buckets two and three, which falls as evidence becomes reachable without an engineer.

If an unplanned investigation load is the wider issue, our post on unplanned work as roadmap capacity covers how to size it, and the code yellow guide covers what happens when that load is ignored for too long. For the investigation itself, Operate runs dedicated AI agents that investigate production questions with cited evidence and propose fixes for engineers to review.