Measuring Whether Your Tiers Work
The monthly report says the tiers are working. First-line resolution is at seventy-eight percent, up four points. The queue is shorter than it was in the spring, and the slide has a green arrow on it. Priya, the second-line engineer, reads the report at 15:40 on a Thursday. Priya is between a password reset somebody escalated at 15:20 and a printer that is "probably network." Priya tries to remember the last afternoon she spent on the work she was hired for. It was before the tiers.
The report is not lying. It is measuring one thing. One thing cannot show you a tier structure. A tier structure is a set of handoffs and a handoff has two ends. This article is part of our Support Tiers series. It is about the four numbers that, read together, tell you whether your tiers are doing what tiers are for. That means protecting expensive time, matching problems to skills, and giving first line something to grow into.
It covers the four numbers (resolution by tier, escalation rate, bounce-back rate, and time at each tier before the handoff). It covers what each can and cannot tell you, then healthy ranges, with the hedges they deserve. There is a table of the patterns that mean a boundary is in the wrong place. We cover how to get the numbers out of any tool, then how to read them without being fooled, including by yourself. There is a quarter worked through, then a war story about a number that was too good. We finish with a fifteen-minute quarterly review with a sheet to copy.
Four Numbers, Not One
One number lies by omission, and the first-line resolution rate is the usual liar, because it is the easiest to collect and the easiest to move. It goes up when first line gets better. It also goes up when first line closes tickets that are not fixed or when a flood of easy tickets arrives. It also goes up when second line quietly starts answering first line's questions in chat so that nothing is ever formally escalated. The number cannot tell those apart. Priya's afternoon can.
The four numbers work because each one watches a different end of the handoff. Resolution by tier says where tickets finish. The escalation rate says how many leave first line. The bounce-back rate says how many of those come back down. Time at each tier before the handoff says how long a ticket sat with one tier before moving. Each has a partner that catches it lying, which is the subject of a later section. None of them is worth much alone.
Reading all four takes about fifteen minutes a quarter once the tool gives them to you. That is less time than the monthly report takes to format. A tier structure that needs a dashboard to understand is being measured by someone with time to spare.
Resolution by Tier and the Escalation Rate
Resolution by tier is the share of resolved tickets that were finished at each tier. Here, "finished at" means the tier that applied the fix, not the last tier to touch the ticket. On a two-tier desk it is two numbers that add up to one hundred. The escalation rate is the share of all tickets that left first line at least once. On a two-tier desk it is close to the complement of the first-line number. The gap is tickets that were escalated, bounced, and finished at first line after all.
Healthy ranges, with hedges. Most small desks resolve well over half of their tickets at first line. And sixty to eighty percent is common once the known-error list exists and first line is allowed to do resets and access. Below half, first line is a routing desk and the boundary is too high. Above ninety, be suspicious before being pleased; the war story below is about a desk that hit ninety. The escalation rate is the same number seen from the other side. And its job is to tell you the load on second line in tickets, which is not the same as the load in hours.
What the pair cannot tell you is whether the right tickets are escalating. A desk can have a healthy seventy percent at first line while the thirty percent that escalates is half password resets. The number will look fine while Priya's afternoon disappears. That is what the next two numbers are for.
The Bounce-Back Rate
The bounce-back rate is the share of escalations that came back down to the tier that sent them, whether with a reason or without. It is the most useful of the four, because a bounce is a boundary test. Every one says either that the line is in the wrong place or that the handoff was empty. A bounce-back rate over one in five means the boundary is in the wrong place, or the handoff note is not being written. Either way something on the card needs changing. Below one in twenty can be good news or the other leak: second line accepting everything, including the resets, because arguing takes longer than fixing.
Count bounces with their reasons, if the desk records them, because the reasons are the diagnosis. "On first line's list" means the list is not being read or not being believed. "Handoff missing a line" means the note is not being written. "Cause found, fix is first line's" is the healthy kind. A desk where most bounces are that kind is a desk whose known-error list is growing. Escalation Boundaries That Hold sets out the three reasons and the once-only rule.
Without this number, the tiers can be leaking in both directions and every other number can look fine. The first-line rate holds, and the escalation rate holds. The same forty tickets a month take two trips up the stairs and two trips down, visiting four queues on the way to the one that fixes them.
Time at Each Tier Before the Handoff
Time at each tier is how long a ticket sat with one tier before it moved, measured from the tier taking it to the tier handing it on. Take two readings. The median is the middle value when all the times are sorted, which tells you what usually happens. The ninetieth percentile is the value nine in ten tickets sit below, which tells you what the slow tail looks like. Averages hide the tail, and the tail is where the problems are.
For first line, the readings tell you whether the time box is real. If the box is thirty minutes and the median time before escalation is four minutes, first line is routing, not trying. If the ninetieth percentile is three hours, a tail of tickets is being held long past the box, usually because somebody was nearly there. For second line, time before resolution matters less than hours per week, which is the number Priya's report never had. It is the sum of second-line effort across all tickets, including the ones that should never have arrived.
The same reading applied to the whole ticket tells you what the user felt. A ticket with fourteen minutes at first line, a two-day wait in the second-line queue and nine minutes of second-line work was slow. No tier was slow. The handoff was. Tiers add waiting at every boundary, and the time-at-tier numbers are the only ones that show where the waiting is.
The Signals That a Boundary Is Misplaced
Each pattern in the table is one number doing something odd while the others hold still, and each has a usual cause and a usual fix. The fix is always a change to the boundary card or the handoff, not a conversation with a technician. The numbers describe a system, and the system is what gets adjusted.
| The number | The pattern | Likely cause | The fix |
|---|---|---|---|
| First-line resolution | Under half | The resolve-here list is short or missing; first line lacks the access to finish | Add resets, unlocks and access to the list and grant the rights |
| First-line resolution | Over ninety and reopen rate rising | Tickets closed on "instructions sent" rather than user confirmation | Close on confirmation or on silence after a set period; count reopens |
| Escalation rate | Rising while volume is flat | New ticket types with no entry on either list | Look at twenty escalated tickets, write the entries |
| Bounce-back rate | Over one in five | Boundary in the wrong place or handoff notes empty | Make the four lines mandatory; move the line that keeps being argued about |
| Bounce-back rate | Under one in twenty, second-line hours rising | Second line accepting everything | Give second line the once-with-a-reason bounce and ask them to use it |
| Time at first line, median | Under five minutes | Escalating before the lists have been tried | The lists first, then the box; bounce reason (b) |
| Time at first line, ninetieth percentile | Several times the time box | Tickets held on "nearly there" | Escalate at the box, note the near-miss in the Found line |
| Waiting time between tiers | Longer than work time at either tier | Second-line queue not being watched | A fixed time twice a day when second line takes the queue |
The table has eight rows and most desks will recognize two. That is normal. A boundary that is wrong in two places is a boundary that was drawn once and has been working for a year. Two changes a year is about what a card needs.
Getting the Numbers From Any Tool
Any tool can give you the four numbers if it records three things. The first is the tier a ticket is at (a queue, a group, an assignee list mapped to tiers, or a custom field). The second is the assignment history (who held the ticket, and when it moved). The third is timestamps (opened, each move, resolved, reopened). If your tool records those, the rest is arithmetic. If it records only the current assignee, add a custom field called "escalated" that the handoff note sets, and a second called "bounced" that the bounce reason sets. In that case, you have three of the four numbers from next month.
The arithmetic on a spreadsheet, once a quarter: export the tickets resolved in the period with their assignment history. For each ticket, note the tier that resolved it, count the moves up, count the moves down, and take the minutes from the first assignment to the first move up. Resolution by tier is a count by the first column. The escalation rate is the share with any move up. The bounce-back rate is moves down divided by moves up. Time at first line is the median and ninetieth percentile of the last column. Fifty tickets is enough to see a pattern, so a small desk can do this by hand on a slow Friday.
A tool whose reports already include workload per agent, backlog by age and resolution time at the median and the ninetieth percentile gives you most of this without the spreadsheet. QuerySolv's reports run seven sections, including Service Performance, Team Performance and Agent Evaluation, over seven, thirty or ninety days. They export to CSV for any arithmetic the report does not do for you. Whatever the tool, the ninety-day view is the one to use for tiers, because a month is too few handoffs to trust.
Reading the Numbers Without Gaming Them
Every one of the four numbers can be moved without the desk getting better. And the way to read them honestly is to pair each with the number that catches it. First-line resolution rises if first line closes tickets that are not fixed. So pair it with the reopen rate, the share of resolved tickets the user reopened. A tool that reopens a ticket when the user replies, by any channel, and counts the reopen, is what makes that partner trustworthy. In QuerySolv a reply on a resolved or closed ticket does exactly that. If first-line resolution rises and reopens rise with it, nothing improved except the chart.
The escalation rate falls if first line holds tickets past the box rather than passing them. So pair it with time at first line at the ninetieth percentile. The bounce-back rate falls if second line keeps everything, so pair it with second-line hours per week. Time at first line looks honest if the "effort so far" line on the handoff is filled in honestly. So pair it with a glance at ten handoff notes. Four numbers, four partners, and a quarter of an hour.
I once reported a ninety-one percent first-line resolution rate to a manager and was proud of it for about a week. The reopens arrived in week two, as new tickets, with sharper subject lines. The rate had not measured resolution. It had measured how quickly we were willing to say "resolved."
The honest reading also means not using the four numbers on individuals. They describe a boundary, and a boundary is a thing the desk drew. A technician with a high escalation rate is usually a technician holding the tickets the lists never covered. Change the list, and the number changes with it.
A Quarter at Kestrel Payroll, Worked
Kestrel Payroll runs a four-person desk with two on first line, and Dana reviews the tiers each quarter. The quarter's numbers: six hundred and twelve tickets resolved. Three hundred and ninety-eight finished at first line, which is sixty-five percent. There were two hundred and fourteen escalated, thirty-five percent. Of the escalations, fifty-one bounced back, which is twenty-four percent, or roughly one in four. Time at first line before escalation: median twenty-two minutes, ninetieth percentile two hours and ten minutes, against a time box of thirty minutes. Reopen rate four percent.
Reading them in pairs: the first-line rate is fine, and the reopen rate says it is honest. The bounce-back rate is over one in five, so a boundary is wrong somewhere. The median time at first line says the lists are being tried, but the ninetieth percentile says a tail of tickets is being held four times past the box. Dana pulls the fifty-one bounced tickets. Thirty were access requests for one payroll application that first line was not allowed to grant. So each went up, was granted in two minutes, and came back. Twelve had an empty "Tried" line. Nine were the healthy kind, with a cause and an article.
One boundary change: first line gets the rights to grant access to that application, with a two-paragraph article on the checks. And the "Tried" line becomes mandatory in the transfer form. Nothing is said to anyone about the tail. Next quarter: six hundred and three tickets, sixty-eight percent at first line. There were nineteen bounces out of one hundred and ninety-three escalations, which is just under one in ten. The ninetieth percentile at first line was down to fifty minutes. That was because the held tickets had mostly been access requests first line knew it could not finish. The second-line engineer at Kestrel got about three hours a week back, which is what thirty two-minute tickets and their handoffs cost.
A Short War Story: Northgate Retail
Sam ran the Northgate Retail desk. The quarterly review showed first-line resolution at ninety percent, up from seventy-four. That went on a slide with a green arrow. The reopen rate on the same report had doubled, which went nowhere, because nobody had thought to read the two together. When Sam did, the cause took one afternoon to find. First line had started closing tickets when instructions were sent rather than when the user confirmed. That was because the weekly review had been praising the resolution number and the closing habit had followed the praise. The boundary was fine; the habit was not. Sam changed the resolution reply to ask for confirmation, and set tickets to close on confirmation or on three days of silence. Sam stopped reading the first-line number without the reopen number beside it. The rate settled at seventy-six and stayed there, and the reopens went back to where they had been.
Nobody had done anything wrong at Northgate. A number had been asked for, and the number had been delivered.
The Quarterly Tier Review
The review is fifteen minutes, four numbers, and one boundary change. Three people attend: whoever owns the boundary card, one person from first line and one from second. The agenda is fixed. Read the four numbers next to last quarter's. Pick the one that moved most or sits outside its range. Pull ten tickets from behind it and read them. Change one thing on the boundary card or the handoff. Write the date. Only one change, because two changes in a quarter means you cannot tell which one did what.
Why quarterly: a month is too few handoffs on a small desk to separate a pattern from a bad week. A year is long enough for a misplaced boundary to cost someone a project. A three-person team using a rotating lane reviews the same four numbers, with the other two people's interruption count as a fifth. Tiers for a Three-Person Team has the operating sheet that pairs with this one.
QUARTERLY TIER REVIEW Quarter: ________ Date: ________ Attending: boundary owner ________ first line ________ second line ________ THE FOUR NUMBERS last qtr this qtr partner number Resolved at first line (%) ______ ______ reopen rate ____ Escalation rate (%) ______ ______ time at L1 p90 ____ Bounce-back rate (% of escalations) ______ ______ L2 hours/week ____ Time at first line: median / p90 __/__ __/__ 10 handoff notes read? [ ] Which number moved most, or sits outside its range? ____________________ Ten tickets behind it, read. What they had in common: ___________________ ________________________________________________________________________ ONE CHANGE to the boundary card or the handoff (one only): ________________________________________________________________________ Owner of the change: ________ Check again on: ________ Not changed this quarter, noted for next: ______________________________
Keep the filled sheets. After four of them you have the only history of the boundary that exists, and the pattern across a year is usually clearer than any single quarter.
Where the Numbers Stop Helping
Under about fifty tickets a month, the rates are noise, and a quarter of them is still noise. Read the tickets themselves and skip the percentages. In the first quarter after tiers are introduced, everything moves at once and none of it means anything yet. Take the numbers as a baseline and wait. On a desk that swarms instead of tiering, there are no escalation events to count. On that desk, the useful numbers are owner changes per ticket and interruptions per person per week, which When Tierless Swarming Beats Tiers covers.
The numbers also stop helping the moment they become targets. A first-line rate that is a goal will be met. A bounce-back rate that is a goal will go to zero, by the simple method of second line never sending anything back. The four numbers are instruments, and an instrument that is also a target reads whatever you need it to.
Priya's afternoon is the fifth number, and it is the one the report never had. Second-line hours spent on tickets that first line's list should have covered is the cost of a misplaced boundary in a unit everyone understands. Once it is on the sheet, next to the green arrow, it tends to come back.
Frequently Asked Questions
What is a good first-line resolution rate?
How do I measure time at a tier if the tool does not track effort?
Is a bounce-back always bad?
How often should we look at these numbers?
Should these numbers be used to evaluate individual technicians?
We have no tiers. Should we still measure this?
From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.
