Measuring Escalations Without Blaming Anyone

The quarterly review, slide nine. The heading says "Escalation rate: 31%", under it a bar chart with one bar. The IT manager asks the room the only question a single number permits: "Is that good?" Nobody knows. After a silence, someone says that Jo escalates the most. Jo has been on the desk for five months. Jo was handed every line-of-business application ticket in that time because nobody else wanted them. Jo looks at the table. By the end of the meeting a target of fifteen percent has been agreed, written on a slide, and sent to the desk. The desk will meet it. The way the desk will meet it is by not escalating. Nobody in the room has thought about what that will do to the tickets.

The escalation rate is the share of tickets that left the first person's hands for a different skill or a higher authority before they were resolved. It is a useful number and a dangerous one. It is useful because it says where the desk's knowledge runs out, dangerous because it is easy to read as a score. This article is part of our Escalation Done Right series, and it is the last in it. Measuring is what you do after the paths, the notes and the ownership rules are in place. You want to know whether they are working.

It covers what the rate is and how to count it, with a formula you can paste into a spreadsheet. Then come what a high rate means, which is five different things, and what a low rate means, which is not automatically good. Next is the cut by kind of ticket, which comes first and explains most of the number. The cut by person comes last and is done carefully. The article then covers the other numbers that travel with the rate, and whether to set a target at all. It ends with the monthly review that improves the path instead of the people, a short war story, and the monthly escalation review sheet as a template.

What the Rate Is and How to Count It

The rate is a fraction: the number of tickets that were escalated at least once, divided by the number of tickets in the same period. Decide the period and decide whether you count tickets created or tickets resolved in it. Then never change either, because a rate that is counted differently each month tells you about the counting. Resolved-in-period is the usual choice, because a ticket is only known to be "never escalated" once it is closed. Count a ticket once however many times it was escalated; the number of hops is a separate measure, covered below.

Count the two kinds separately, because they mean different things and move for different reasons. A functional escalation, the ticket moved sideways to a different skill, says something about the desk's knowledge and access. A hierarchical escalation, a flag raised for a decision or attention, says something about the desk's authority and about how often tickets get stuck. A desk with a high functional rate needs runbooks; a desk with a high hierarchical rate needs its people trusted with more decisions. Adding the two together produces one number that cannot tell you which, which is the number on slide nine.

Most ticketing tools record each escalation and each change of assignee in the ticket's history with who did it and when. Many can report a rate directly. If yours cannot, export the period's resolved tickets to a spreadsheet. Include the kind of ticket, the first assignee, the final assignee, and the number of assignee changes. Include a column that says whether the ticket was flagged. A ticket whose final assignee differs from its first was functionally escalated, more or less; a ticket that was flagged was hierarchically escalated. Then the rate is one cell. With the yes/no answers in column E from row 2 to row 400, the formula is =COUNTIF(E2:E400,"yes")/COUNTA(E2:E400). It takes longer to read the formula sentence than to type it.

Keep the export, and keep the same columns every month, because the value of the rate is almost entirely in its movement. Thirty-one percent on its own is a weather report. Thirty-one percent after three months at twenty-four is a question. Thirty-one percent in one kind of ticket and nine in every other is an answer. The single number is where the reading starts, never where it stops. A desk that puts a single number on a slide and asks whether it is good has stopped reading at the title.

What a High Rate Means

A high rate means one of five things, and the review's job is to find which. Each has a different fix and only one of them is about the people. The first is that the desk lacks knowledge it could have. The same kind of ticket goes sideways every time because nobody on the desk has been shown how to handle it. The fix is a runbook, a knowledge article, or an afternoon with the specialist. This is the commonest cause and the cheapest to fix. It shows up as one or two kinds of ticket with a rate far above the rest.

The second is that the path is too eager. The time box is too short, or the skill-gap rows in the path table send things to a specialist that the desk could do with ten more minutes. This shows up as transfers with thin handoff notes, because the technician had not learned anything by the time the box ran out. It also shows up as specialists who send tickets back with a one-line answer. The fix is a longer box for that kind of ticket or a redrawn row. The change is made at the review and written into the table from Escalation Paths and Criteria.

The third is that the specialists are holding knowledge that should have come down. Every specialist has a set of fixes they have done thirty times, each in ten minutes, each after a transfer, and none written down. Writing it down felt like extra work and the transfer felt like the system working. The sign is a specialist whose incoming tickets are resolved very fast. The fix is to ask that specialist for the ten fixes they do most and turn them into desk runbooks. The specialist's rate of incoming transfers will fall, and so will the complaints about being interrupted, which tend to come from the same person.

The fourth is that the intake is thin. Tickets arrive without the device name, the error text or the time of first failure. The technician spends the time box asking for them. The box runs out before any diagnosis begins, so the ticket goes sideways with the facts and nothing else. This shows up as escalated tickets whose handoff notes are mostly questions. The fix is at the form and the first exchange, which is triage work rather than escalation work. It moves the rate more than anything done on the escalation side.

The fifth is that the kinds are wrong. A kind of ticket called "application" is really four different applications, two of which the desk handles and two of which it never can. So the rate for "application" is a meaningless average of a hundred percent and nothing. This shows up as a kind with a middling rate that nobody can explain. The fix is to split the kind, which is a taxonomy question and a small one. Not on the list of five: the technicians are lazy. In a decade of reading these numbers I have not once found that to be the cause, and I have looked.

What a Low Rate Means

A low rate is not automatically good. A desk that celebrates one without checking has probably stopped looking at the thing the rate hides. It can mean that the desk is excellent: broad knowledge, good runbooks, the right permissions, and specialists who have taught what they know. That is the reading everyone wants, and it is sometimes true. It is confirmed by three other numbers being healthy at the same time. Resolution time is not rising, the reopen rate is not rising, and the age of the oldest open ticket is not climbing. A low escalation rate with all three of those stable is a desk doing well. A low rate with any of them moving is a desk sitting on tickets.

Sitting on tickets is the usual meaning of a rate that fell after a target was set. The technician who was told that fifteen percent is the goal stops escalating at the box and tries a sixth and seventh thing. They either fix it slowly, fix it wrong, or let it age. The escalation rate falls and the desk looks better on slide nine, while the resolution time rises. The reopen rate rises because fixes made by the wrong person come back. The aging report fills with tickets that everyone is avoiding. The two measures that catch this are the subject of Measuring Reopens Honestly and The Tickets Everyone Is Avoiding. A review that looks at escalations without looking at both of them is reading one page of a three-page report.

A low rate can also mean that escalation is happening and not being recorded, which is the shadow escalation. The technician messages the specialist directly and the specialist answers in the chat tool. The technician applies the fix, and the ticket's history shows one person doing everything. The desk's knowledge appears broad and is in fact borrowed by the minute. The sign is a specialist who is interrupted all day and has few tickets assigned. The fix is to make the advise-and-return handoff from The Handoff That Does Not Dump an internal note on the ticket rather than a message. That way, the help is recorded where the ticket is. Help that is not recorded is still help. It is just invisible to everyone trying to make the desk better.

Finally, a low rate can mean the criteria are too loose. That could be a time box of two hours, a path table that says "desk handles everything first", and tickets that reach the specialist only after a breach. That desk has a low escalation rate and an unhappy set of requesters. The breach report will say so before the escalation report does. The honest low rate and the dishonest one look identical on slide nine. The other three pages tell them apart.

By Kind of Ticket First

The first cut of the rate is by kind of ticket, and it explains most of the number before any person's name is mentioned. Use whatever your tool gives you to say what a ticket was about: a category field, a custom field on the form, or a tag. If there is nothing, use the exported subject lines sorted and labelled by hand into eight or ten piles. The pile names are the rows. For each row, count the tickets, count the escalated ones, and divide. Then sort by rate, and read the top three rows, because they are usually where the whole story is.

Here is a quarter at Acme, a desk of four supporting about two hundred and fifty people, with the rows sorted by rate. The overall rate was thirty-one percent, which is the number that reached slide nine. Cut by kind, it stops being one number and becomes a short list of things to do.

Two rows carry the number. The application row sends nearly everything sideways, which is not a desk problem but a boundary problem. The desk should have access and three runbooks. Or the application should route straight to the specialist from the form and stop counting as a desk escalation at all. The purchases row sends nearly everything up, which is not a knowledge problem but an authority one. A written spending limit the desk can approve without a flag would turn twenty-seven hierarchical escalations into none. Fix those two rows and the overall rate falls to something under fifteen percent without a single technician changing anything about how they work. That is the point of the cut. The number that looked like a verdict on the desk was two rows in a table, and neither of them was about effort.

The kind-of-ticket cut also finds the repeat offender: the kind that is escalated every time because the fault is never actually fixed, only cleared. Twelve escalations for the same wireless controller in a quarter is one problem happening twelve times. The right response is not a better path but a root cause, which is the subject of Finding the Repeat Tickets. The escalation review should hand that kind to whoever looks at repeats and take it out of its own count once the fix is in. A rate that includes a known unfixed fault is measuring the fault, not the desk.

By Person, Handled Carefully

The cut by person comes last, after the kind-of-ticket cut has taken its share. It is done against the person's own mix of tickets rather than against their colleagues. If Jo received every application ticket this quarter and application tickets escalate at eighty-five percent, Jo's personal rate will be high. In that case, it will mean nothing except that Jo was given the application tickets. The fair comparison is Jo's rate on sign-in tickets against the desk's rate on sign-in tickets. It also compares Jo's rate this quarter against Jo's rate last quarter. Anything else is comparing the person to the queue they happened to be handed.

A trainee's rate should be higher than a senior's. A desk whose trainee has the lowest rate should worry rather than celebrate. The trainee is being handed only the easy tickets, which is fine and should be known. Or the trainee is sitting on things they should have passed on. A new starter's rate falling month by month over their first year is one of the better signs a desk can see. It means the runbooks work and the specialists are teaching. The same number flat at a low level from month one means something is not being recorded.

Never publish a league table of escalation rates by person, in a meeting, on a wall, or in a dashboard everyone can see. The moment the rate is a ranking, the people at the top of the ranking stop escalating, and the tickets pay for it. Where a tool offers each agent a private view of their own numbers, that is the right level of visibility. The person sees their own trend and can ask about it. A supervisor who wants to discuss someone's rate does it in a one-to-one, with the kind-of-ticket cut in hand. The opening question is "what would have let you handle these?" rather than "why so many?". The first question produces a runbook. The second produces a lower number and a longer queue.

There is a legitimate per-person finding, and it is about the handoff rather than the rate. It concerns a technician whose transfers are regularly sent back by specialists for a thin note, or whose flags do not say what is being asked. That is coaching material, and it is coached by showing the person a good note and a thin one side by side, not by counting. The specialists can tell you who it is without a report, and will, if asked quietly. If the answer is "everyone", the problem is the template. In that case, the fix is to put the escalation note from this series into the tool as something everyone fills in.

The Numbers That Travel With It

The rate is one of six numbers, and the other five keep it honest. Measure them together, on the same sheet, every month, and read them as a set. Each one catches a way the rate can be gamed or misread. Together they describe whether escalation on the desk is a working handoff or a place tickets go to wait.

Most tools can give you the raw material for all six from the ticket history, either as a report or as an export with timestamps for each assignee change and status change. If the tool cannot show how long a ticket spent with each assignee, the export can, with a little spreadsheet work. The first month's work is the only expensive one. Two of these numbers are harder than they look. Time to acknowledgment needs the receiver's first note to be identifiable, which the escalation note template makes easy by starting with "Got it". Escalated-then-reopened needs the reopen to be counted. Many tools do this automatically when a requester replies to a closed ticket, and some need a status change by hand. Pick a definition and keep it.

The number most desks forget is time to acknowledgment. It is the one that most directly measures whether escalation is working as a handoff. A desk can have a reasonable rate and a reasonable time in escalated state and still be a desk where every transfer sits unread for a day. The requester experiences that as a day of silence. One working hour is the usual agreed window. Measure how often it is met. When it is not, look at which receiver and which time of day. The answer is usually "the one specialist who covers two sites" or "anything transferred after four", and both are staffing facts rather than character ones.

Setting a Target, or Not

Do not set a target on the escalation rate. Not for the desk, not per person, not "just as a guide". A rate target is met by not escalating, which is the one behaviour the whole of this series exists to prevent. The desk will meet it within a month because the people on it are intelligent and know what they are being measured on. The target produces a lower number and a longer queue. The manager who set it will find out from the aging report, three months later, that the number they were pleased with had been bought with the tickets everyone was avoiding.

Set targets on the things that make escalation work instead. Acknowledgment within one working hour, met nine times in ten. A handoff note on every transfer, with the five elements present. Hops per ticket at one for most kinds. Escalated-then-reopened no higher than the desk's overall reopen rate. Each of those is met by doing escalation well rather than by doing less of it. Each of them, when met, tends to bring the rate down anyway. The review of good notes and fast acknowledgments is where the runbooks come from.

If someone above you insists on a rate target, offer them a direction and a reason instead of a number. Say: "we expect the application row to fall from eighty-five percent to under forty once the desk has access and the three runbooks, by the end of next quarter. We will show you the row". That is a target on a fix, not on a behaviour, and it can be checked. Then put the aging and reopen numbers on the same slide, so that the rate is never again shown alone. A number shown with the two numbers that keep it honest is a measurement. The same number shown alone is a slide.

The Monthly Review That Improves the Path

The review is twenty minutes, monthly, with the sheet below, the export, and the current path table on the desk. The output is three small things: one change to the path table, one piece of knowledge written down, and one criterion adjusted or confirmed. Not a target, not a conversation with a named person, not a presentation. The review is maintenance on the path, done by the people who use it. It is boring by month four, which is the goal.

Minutes one to five: the headline, which is the functional and hierarchical rates, the acknowledgment figure and the hops figure, each against the previous two months. Six to twelve: the kind-of-ticket cut, sorted by rate, with the top three rows read aloud and a probable cause written beside each. Thirteen to fifteen: the other numbers, looking only for anything that moved. Sixteen to eighteen: the one change, the one article, the one criterion, each with a name and a date. Nineteen and twenty: file the sheet beside the last one, and book the next review.

The change to the path table is the thing that compounds. A row might have a wrong name or a time box that is too short for one kind of ticket. It might have a transfer destination that is really a vendor, or a decision that the desk should be allowed to make alone. One of those is fixed every month. After a year the table describes the desk rather than the desk's first guess at itself. The knowledge article is the thing that moves the rate: the specialist's ten-minute fix becomes the desk's ten-minute fix. That kind of ticket stops appearing in the table at all. The criterion adjusted is the thing that keeps the box honest, in either direction.

Read the review's own history every third month. Three sheets side by side show whether the one change each month actually changed the row it was aimed at. They also show whether anything moved that nobody changed, which is a new question. A sheet that says "no change, see note" three months running for a given row means that row is right. A desk whose rows are mostly right should say so somewhere. The people on it will otherwise assume the review exists to find fault. It exists to find rows.

A Short War Story: The Fifteen Percent Target at Stonebridge Insurance

Stonebridge Insurance's desk of five was given an escalation rate target of fifteen percent after a quarterly review showed thirty-one. It met the target within six weeks. Jo had been handed every claims-system ticket for a year and had escalated most of them to the one engineer with access. He stopped at the time box, kept going, and started closing claims tickets with workarounds he had found himself. Those took three times as long and came back as reopens often enough that the desk's reopen rate doubled over the quarter. A claims director's ticket about a report that would not run sat with Jo for four working days. During that time, he tried to avoid an escalation that would have taken the engineer twenty minutes. The director's complaint reached the IT manager through the finance director. The manager pulled the aging report and found eleven claims tickets over ten days old, all with Jo. All were of a kind that had been escalated and resolved in a day the quarter before. The manager understood what the fifteen percent had cost. The target was withdrawn and Jo was given the access the engineer had. The claims row in the path table was rewritten with three runbooks. The rate fell to nineteen percent over the next quarter without anyone being asked to escalate less. The lesson Stonebridge put at the top of its review sheet was that a rate target measures fear, and the queue pays for it.

The Monthly Escalation Review Sheet

The sheet below is the twenty minutes on one page. Fill it in from the export in the order shown. Keep the completed sheets together, and read the last three at every third review. It is plain text so that it can live in the knowledge base, in a shared folder, or beside the path table on the wall. The cells are sized for a small desk with eight to twelve kinds of ticket.

ESCALATION REVIEW — ONE PAGE
Desk: __________________  Month: ______________  Reviewer: ____________

HEADLINE (against the previous two months)
  Tickets resolved: ____    Escalated (any kind): ____    Rate: ____%  (____%, ____%)
  Functional rate: ____%  (____%, ____%)    Hierarchical rate: ____%  (____%, ____%)
  Acknowledged within ____ working hour(s): ____%  (____%, ____%)
  Hops per escalated ticket (median): ____    Tickets with 3+ hops: ____

BY KIND OF TICKET (sorted by rate; top rows first)
  Kind                      Tickets  Escalated  Rate   F / H   Probable cause
  ______________________    ____     ____       ___%   __/__   ______________________
  ______________________    ____     ____       ___%   __/__   ______________________
  ______________________    ____     ____       ___%   __/__   ______________________
  ______________________    ____     ____       ___%   __/__   ______________________
  Cause for each top row:  [ ] knowledge gap  [ ] path too eager  [ ] specialist holds the fix
                           [ ] thin intake    [ ] kind is wrong   [ ] repeat fault (hand to problem review)

THE OTHER NUMBERS (only note what moved)
  Time in escalated state (median, working hours): ____  vs desk median for same kinds: ____
  Escalated-then-reopened: ____%   Desk reopen rate: ____%
  Resolution time, escalated vs not (median): ____ vs ____
  Oldest open escalated ticket: ____ days   Owner named?  [ ] yes  [ ] no

BY PERSON (only after the kind cut; own mix, own trend; never published)
  Anyone whose rate on a kind differs from the desk's rate on that kind by more
  than the kind's own swing?  [ ] no  [ ] yes: ________  Question to ask: "what would have let you handle these?"
  Notes sent back for thinness this month: ____   Pattern?  [ ] no  [ ] yes: __________

THE THREE OUTPUTS
  1. One change to the path table:  row ____________  change ______________________
     Owner: ________  Done by: ________
  2. One piece of knowledge written down:  ____________________________  Owner: ________
  3. One criterion adjusted or confirmed:  ____________________________  (box / threshold / decision list)

PATTERN TEST (against the previous three sheets)
  Same kind in the top three, three months running?  [ ] no  [ ] yes: ____________
  Did last month's change move its row?  [ ] yes  [ ] no  [ ] too early
  Verdict for the month:  [ ] weather  [ ] a row to fix  [ ] a boundary question  [ ] a staffing fact

The sheet changes a little with the desk. A desk of two strikes the by-person section entirely, because the comparison is between two people who were handed different queues. Nothing useful can come of it. A desk with departments that run their own paths fills in one sheet per department, because the application row in one is not the application row in another. A desk that routes some kinds of ticket straight to a specialist from the form should mark those kinds on the sheet. It should exclude them from the rate. A ticket that was never meant to be worked by the desk was never escalated from it.

Slide nine, from the opening, said thirty-one percent and asked whether that was good. Read with this sheet, it would have said that two rows carried the number. It would have said that one of them was a boundary and the other was a spending limit. It would have said that Jo had been handed the boundary row for a year and had done well with it. It would also have said that the fix was access, three runbooks and a signature, none of which involved a target. The desk would have met that fix in a quarter. The number would have fallen to something under fifteen, which is the same number the meeting wrote on the slide. It would have arrived by a different road, with the queue intact at the end of it.

Frequently Asked Questions