The Handful of Metrics Worth Tracking, and Why It Is Six

Monday, 09:40, at Tollgate Foods. Ravi has run the support desk for exactly one week. That is to say that last Monday somebody handed him the queue and a login and said "you'll be fine". This morning Marianne, the operations director, stops at his desk on the way to a meeting. She asks the question he has been dreading since Wednesday: "So, how is the desk doing?" Ravi opens the reporting screen. It offers him forty-one numbers in coloured tiles, several of them green. Average handle time is 1.7 of something. Utilisation is 83. There is a tile called Throughput Velocity, and it has gone up. He looks at all of it for about four seconds and says, "Busy." Marianne nods, because "busy" is what every desk has told every director since desks were invented, and goes to her meeting.

A metric is a number the desk agrees to produce the same way every period. That way, this month's can be set beside last month's and the difference means something. A good metric is a question the desk has decided to keep asking. A desk needs only a handful of good questions. It asks how much work is arriving, how long people wait for a reply, and how long they wait for a fix. It needs to ask what is piling up, whether fixed meant fixed, and how it felt. Six questions, six numbers. This article is part of our Helpdesk Metrics That Matter series. The series covers the handful worth tracking, the vanity numbers to ignore, and exact definitions. It covers gaming and its cures, reading the numbers together, and starting small.

It covers why six and not forty. It covers each of the six in turn, with the question it answers, a plain definition and what it cannot tell you. Then come the pairs the six fall into, and the numbers that did not make the cut. It ends with a short war story and the metric card set to copy, in that order.

Why Six, and Why Not Forty

Six is roughly the number of questions a desk lead should be able to answer about the desk without looking anything up. It is not an accident that it is small. Every metric costs something: an hour to define so that two people get the same number, and time each month to produce. It costs time to read, and time to defend when somebody asks why it moved. Forty-one numbers cost Tollgate's previous lead a day a month to assemble, and the only person who read them was the person assembling them. The report was not information. It was a hobby with a distribution list.

The six earn their place because each answers a question somebody acts on. Volume tells you whether the desk is keeping up, which is a staffing conversation. First response tells you whether requesters hear from a person, which is a triage conversation. Time to resolution tells you how long they wait for a fix. Backlog and its age tell you what to dig out this week. Reopen rate tells you whether closing meant fixing. Satisfaction tells you how the whole thing felt to the person on the other end. If nobody on the desk would do anything differently whichever way a number moved, it is not a metric. It is a fact, and facts are free, so you can have as many as you like without reporting them.

Six is also the number you can read together in fifteen minutes a month. Reading them together is the only way they tell the truth, for reasons the article on reading metrics together goes into. The tool will offer you more. Most tools offer a great many more, in tiles, with colours, and the tiles are not lying to you; they are answering questions you did not ask. A brand-new desk can start with three of the six. The case for starting that small, for a desk that opened last week, is made in the first metrics for a new desk. Start with three if you must. Do not stop at one.

Volume: Is Work Arriving Faster Than It Leaves?

Volume is the count of tickets created in a period, and beside it, always, the count of tickets resolved in the same period. One number on its own is a crowd size. Two numbers side by side are a direction. At Tollgate, the fictional desk this article uses for its arithmetic, a typical month runs at about 310 tickets created and about 290 resolved. That means twenty tickets a month are added to the pile that nobody is looking at. Twenty a month sounds like nothing. Over a year it is 240 tickets, and 240 tickets is a backlog with a payment plan.

The counting rules are short and every one of them matters. Every ticket counts, from every door the desk has: the web form, the mailbox, and the chat. The phone call that a technician typed up afterwards and the walk-up that was logged after the fact count too. Duplicates that were merged count once. Count by week to see the shape, with its Monday peak and its Friday afternoon slump, and by month to see the trend. The full set of rules, including what to do about tickets that were split or merged, is the subject of counting tickets properly. This article leaves them there.

What volume cannot tell you is whether any of the work was done well, and, more dangerously, whether the people who used to raise tickets still do. A falling count is the best news on the desk if a recurring problem was fixed or an article now answers the question first. Or it is the worst news, because a department gave up and started e-mailing a technician directly. The count itself has no opinion. Read volume with the backlog, which is the next pair down, and when the count falls, ask which department fell and whether anyone fixed anything there. The shadow-channel version of a falling count is one of the quiet failures described in the fundamentals series. It looks, from inside, exactly like a good quarter.

First Response: How Long Before a Person Replies?

First response time is the time from the moment a ticket is created to the moment a person writes the first reply the requester can see, measured in business hours. Business hours are the hours the desk has said it works, say half past eight to half past five on weekdays. Measuring in them means a ticket raised at five on a Friday and answered at a quarter to nine on Monday waited fifteen minutes, not sixty-four hours. The automatic acknowledgement with the ticket number in it is not a response; it is the desk clearing its throat. An internal note is not a response either, because the requester never sees it. The clock stops at the first sentence a human wrote to the human who asked.

The question it answers is how long a requester waits to learn that somebody has their problem. That moment matters more than it looks. It is the point at which the requester stops wondering whether the desk exists and starts waiting for a fix. That is a different and much more patient kind of waiting. Report it as a median and as the slowest tenth, not as an average. The median is the middle ticket when they are lined up by waiting time. The 90th percentile is the value that nine tickets out of ten beat. Between them they say what a normal requester experienced and what the unlucky ones did. Tollgate's month came out at a median of about 1.4 business hours and a 90th percentile of about nine. That is one number to be pleased with and one to look into. The reasons the average is the wrong choice are in median and percentiles, not averages. They apply to every time-based metric in this article.

What first response cannot tell you is whether the reply said anything. "We are looking into it" stops the clock and starts nothing, and a desk measured on first response alone will discover templates for saying it very quickly. It also cannot tell you whether the problem was fixed, which is the next metric's job. If your desk has promised response times by priority, as in a service level agreement, the promise lives in the service-level design series. This metric then measures whether it was kept. The two are related and not the same, and a desk with no promises at all still needs the measurement.

Time to Resolution: How Long Before It Is Fixed?

Time to resolution is the business hours from a ticket's creation to the moment a technician marks it resolved. That means they believe the problem is fixed and have told the requester so. It is not the time to closed. Closed comes later, after the requester confirms or a confirmation window runs out without a reply. The gap between the two is a feature of the workflow rather than of the technician, which is why the clock stops at resolved. The distinction, and what the window between them is for, belongs to the workflow series.

Report it the same way as first response: median and 90th percentile, never the average on its own. Tollgate's month had a median of about six business hours and a 90th percentile of about four business days. The average, had anyone computed it, was a little over two days. It was pulled there by three tickets that had waited six weeks for a supplier to send a part. The average described no ticket that had actually happened. The median described most of them. The 90th percentile described the ones that generate phone calls.

There is one edge to decide before the first number is produced: what to do about time the ticket spent waiting on the requester or a supplier. Some desks stop the clock while the ticket is in a waiting status; some let it run, on the grounds that the requester was waiting regardless of whose turn it was. Both are defensible. What is not defensible is deciding differently in different months, which is why the decision is written down once, in the way defining each metric exactly describes. Whichever you choose, the number is comparable only with itself.

What time to resolution cannot tell you is whether the fix held, whether the requester was content, or whether the speed came from skill or from marking tickets resolved a little early. A desk that watches this number alone will get faster and will not know what it paid for the speed. Its partner is the reopen rate, two sections down. The deep dive on the metric itself is the Time to Resolution series. It includes the cuts by category and priority and the monthly read of the ten slowest tickets.

Backlog and Its Age: What Is Rotting?

Backlog is every ticket that is open at one moment, and it is a photograph where volume is a film. Age is how long each of those tickets has been open. The metric is the count, cut into age bands, with the age of the oldest ticket written beside it. The bands most small desks use are under a week, one to four weeks, and over a month. The reason for bands rather than a single count is that two desks with 240 open tickets can be in entirely different trouble. One has 230 of them under a week old and is merely busy. The other has 140 of them over a month old and is quietly failing a hundred and forty people.

Take the photograph on the same day each period, at the same time, and include every status that means "the desk still owes this person something", waiting statuses included. A ticket parked as waiting on the requester for nine weeks is in the backlog whether or not the tool's default view shows it. A backlog count that excludes waiting statuses will be the most popular number on the desk for all the wrong reasons. The age of the oldest ticket goes beside the count because it is the only one of these figures that is also a person. Read it aloud in the team meeting. "Our oldest open ticket is fifty-three days" concentrates the mind in a way that a bar chart does not.

What the backlog cannot tell you is whether the open tickets matter equally. A request for a second monitor at eight weeks and a broken barcode scanner at eight days are not the same kind of old. The count treats them the same. It also cannot tell you why; that takes reading the tickets, which is what the weekly stale-ticket sweep is for. Read backlog with volume: this month's created minus this month's resolved is next month's change in the backlog. When the two disagree, one of them has been counted wrong.

Reopen Rate: Did Resolved Mean Fixed?

A reopen is a ticket that was marked resolved and was then put back to open because the problem was not, in fact, fixed. The reopen rate is the number of tickets reopened within a window after resolution, divided by the number of tickets resolved in the period. The window is yours to choose; two weeks is common and a month is not unreasonable. The only rule is that it is the same window every month. Tollgate's figures were 290 resolved and 23 reopened within two weeks, which is about eight in every hundred. The honest way to write it is as "23 of 290" with the percentage after, because the count is what you will go and read.

The mechanism matters, because it decides whether the number is real. Where a requester's reply to a resolved or closed ticket reopens it, as it does in QuerySolv and in many tools, the count accrues on its own. Nobody then has to remember to record anything. Where it does not, a technician has to reopen the ticket by hand. The number will then undercount by however many times a tired technician opened a new ticket instead. Test yours by replying to a resolved ticket from a personal address and watching what the status does. If a new ticket appears, your reopen rate is a guess with a decimal point.

The question it answers is whether resolved meant fixed, and it is the quality check on every speed number in this article. A desk whose resolution time fell by a third and whose reopen rate doubled in the same month did not get faster. It got earlier at saying it had finished. What reopens cannot tell you is about the requester who did not reply because they gave up, or who raised a fresh ticket in a different department, or who fixed it themselves and never mentioned it. It also cannot distinguish a fix that failed from a new problem on the same ticket. That is a reading job rather than a counting one, and measuring reopens honestly covers both the counting and the reading.

Satisfaction: How Did It Feel?

Satisfaction is the rating a requester gives when the desk asks, usually at the moment the ticket is resolved, usually on a short scale with a space for a comment. The metric is the share of ratings that were good. It is never written without two more numbers beside it. One is how many ratings there were. The other is the response rate, which is the ratings received divided by the requests sent. Tollgate sent about 290 requests, received 41 ratings, and 36 of them were good. The honest sentence is "36 of 41 ratings were good, from about one requester in seven". The dishonest sentence is "satisfaction was 88 percent", because it is also true and it is wearing a disguise.

It is the only one of the six that comes from outside the desk, which is why it is on the list. Every other number is the desk measuring the desk, with the desk's definitions and the desk's clock. All of them can look fine while the people who use the desk have formed a different view. Satisfaction is the moment that view is allowed in. The response rate is the measure of how much of it got in. A month with nine ratings is a month with nine opinions, not a score. The small-numbers problem and who tends to answer are the subject of response bias and how to read around it.

What satisfaction cannot tell you is what the people who did not answer think, and most of them did not answer. It cannot tell you why a rating was low unless the requester wrote a comment, which is why the comment box is the most valuable field on the survey. And it cannot be read per technician without a minimum sample, a rule this article comes back to below. Read satisfaction with first response and with resolution time. A fast number next to a low rating means the speed was bought with something the requester noticed.

The Three Pairs, and the Numbers That Did Not Make the Cut

The six fall into three pairs, and each pair exists because the first number flatters on its own and the second one checks it. Volume is read with the backlog, because a fine closed count beside a growing pile means the easy tickets were done and the hard ones were left. Time to resolution is read with the reopen rate, because fast closes that come back were never fast. First response is read with satisfaction, because a quick reply that said nothing is a quick reply the requester noticed. Satisfaction, in turn, is always read with its own response rate. The monthly read that walks the three pairs in fifteen minutes, and the one-page scorecard that holds them, are in reading metrics together.

Several good numbers did not make the six, and it is worth saying why. First contact resolution, the share of tickets fixed in the first reply, is a fine seventh metric for a desk that is a year into measuring and has learned to count it honestly. It has a series of its own in this library. Escalation rate is a routing number, useful to the person who designs the tiers and not much to anyone else. Cost per ticket is derived from volume and hours, and belongs with the money. Tickets closed per technician is the number most tools show first and the one most likely to do harm. The next article, vanity metrics to ignore, spends its whole length on the reasons. None of these is wrong. They are answers to later questions, and a desk that cannot yet answer the first six has no business asking them.

One rule applies to all six the moment anyone cuts them by technician. A per-person number is for coaching, never for ranking, and it is not read at all until the sample is large enough to mean something. At Tollgate the rule is twenty resolved tickets or ten ratings in the period before a technician's figure is looked at. A desk can pick its own threshold as long as it has one. Below that, the number is a story about which tickets the person happened to draw. Above it, it is still a conversation starter and not a verdict. The technician whose resolution time is longest is very often the one who takes the tickets nobody else can. The number has no way of knowing that.

If you run QuerySolv, the standard reports already produce all six: volume, backlog by age, response and resolution times, reopen rate and satisfaction. The work is then reading them rather than building them. In any tool, check which of the six the reporting can give you before you promise them to anyone. The gap between what a tool shows on its first screen and what it can produce on request is wide and usually in your favour. Whatever it cannot produce goes in a spreadsheet until it can, and the spreadsheet method is in starting metrics on a small desk.

A Short War Story: The Record Month at Redbrook Engineering

Redbrook Engineering's three-person desk reported one number to the board each month, tickets closed. In the spring it closed 412, a record, which the desk lead, Tomasz, mentioned in the all-hands. Nobody reported the backlog, so nobody noticed that 140 of the 260 open tickets were older than a month. The oldest of them was a request from the design office to fix the licence server for the drawing software. Nobody noticed that it had been waiting eleven weeks while the record was being set. The design team had spent those weeks passing a single working seat between eight engineers. Their manager later put the lost time at somewhere between fifty and seventy hours, before he escalated it. He escalated it by walking into the managing director's office with the ticket number written on his hand. The licence fix took an afternoon. Redbrook added backlog by age and the oldest ticket to the board report the following month. The closed count, which had been true throughout, was never again shown on its own. A single metric answers a single question, and the questions nobody asks are the ones that find a way to ask themselves.

The Metric Card Set

The card set below is one card per metric, six cards. It is the whole of this article in a form you can print and pin up. Each card carries the question, the plain definition, and the counting rule that stops two people getting two numbers. It carries the partner it is read with, and a line for this period's figures. Fill the blanks for the reopen window and the minimum sample with your own choices, once, and do not change them without writing down that you did. The cards are deliberately dull; the interesting part happens when you read card one and card four together and they disagree.

METRIC CARD SET — SIX CARDS, ONE PER METRIC
Desk: ______________   Period: ______________   Prepared by: ______________

CARD 1 — VOLUME
  Question:    Is work arriving faster than it leaves?
  Definition:  Tickets created in the period, and tickets resolved in the period
  Count rule:  Every channel, walk-ups included; merged duplicates count once
  Read with:   Backlog and its age (card 4)
  This period: created ____   resolved ____   difference ____

CARD 2 — FIRST RESPONSE
  Question:    How long does a requester wait for a person?
  Definition:  Business hours from creation to the first reply a person wrote
  Count rule:  Automatic acknowledgements and internal notes do not count
  Read with:   Satisfaction (card 6)
  This period: median ____ h   90th percentile ____ h   not yet replied ____

CARD 3 — TIME TO RESOLUTION
  Question:    How long does a requester wait for a fix?
  Definition:  Business hours from creation to the ticket being marked resolved
  Count rule:  Resolved, not closed; waiting time is  [ ] included  [ ] excluded
  Read with:   Reopen rate (card 5)
  This period: median ____ h   90th percentile ____ h   slowest ticket ____

CARD 4 — BACKLOG AND ITS AGE
  Question:    What is waiting, and what is rotting?
  Definition:  Open tickets on the last day of the period, by age band
  Count rule:  Same day and time each period; waiting statuses included
  Read with:   Volume (card 1)
  This period: open ____   under 7 days ____   7 to 30 days ____   over 30 ____
               oldest ticket ____ days (number ______)

CARD 5 — REOPEN RATE
  Question:    Did resolved mean fixed?
  Definition:  Tickets reopened within ____ days of resolution, over tickets resolved
  Count rule:  A requester reply that reopens counts; a technician adding a note does not
  Read with:   Time to resolution (card 3)
  This period: resolved ____   reopened ____   rate ____ in 100

CARD 6 — SATISFACTION
  Question:    How did it feel to the person who asked?
  Definition:  Ratings received on resolved tickets; the share that were good
  Count rule:  Always shown with the number of ratings and the response rate
  Read with:   Its response rate; first response (card 2)
  This period: requests sent ____   ratings ____   good ____   response rate ____

RULE FOR EVERY CARD
  Cut by technician only for coaching, never for ranking, and only above
  ____ resolved tickets or ____ ratings in the period.

Ravi filled in the six cards for Tollgate on the Wednesday, which took him most of an afternoon. He had to decide the reopen window and find out where the tool kept the age of the oldest ticket. The next Monday, Marianne stopped at his desk again and asked how the desk was doing. He said: "Three hundred and ten in, two hundred and ninety out, oldest ticket fifty-three days, and I would like to talk about the fifty-three days." She stopped walking. It was, he said later, the first conversation about the desk that had not ended with the word "busy".

Frequently Asked Questions