The First Three Helpdesk Metrics
It is day three of the new help desk, and the screen on the wall is already lit. Somebody built a dashboard on day zero, when the queue was empty and configuration was the only thing left to do. There are eleven gauges, including average handle time, customer satisfaction, first-contact resolution, cost per ticket, and mean time to resolve by priority. Then there are six more whose names took longer to type than the data they will ever hold. Every gauge reads "no data". They are gray, which is the dashboard's way of asking you to stop looking at it.
Nobody built it out of vanity. They built it because every article about help desks has a metrics section. The section always has a long list, and a long list looks like diligence. This article is part of our Helpdesk From Scratch series, and it argues for a short list. In the first month of a new desk, three numbers change decisions. The rest decorate.
It covers why three and not eleven. We look at what volume, age and reopen rate each tell you and what they do not. Then we cover how to get each one out of any tool, including a spreadsheet. We explain how to read them in month one, with a healthy range and the question to ask when you are outside it. Next comes what not to measure yet and why, followed by the one-line monthly note and a month-one metrics sheet to copy.
Why Three Numbers and Not Eleven
A metric is a number that changes a decision. That is the whole definition, and it rules out most of the dashboard. If the number went up or down next month and you would do nothing differently, it is not a metric. It is a fact with a gauge around it.
Attention is the constraint, not data. A person running a new desk can hold about three numbers in their head and act on them. Eleven numbers get glanced at. Three get argued with, and the argument is where decisions come from.
In month one, three questions decide everything, and each has one number behind it. How much work is arriving, and from where? That is volume. Is anything being forgotten? That is age. Are we fixing things or closing them? That is the reopen rate. Everything else on the dashboard refines one of those three, and a refinement needs a baseline that does not exist yet.
The eleven gauges are not wrong. They are early. Most become useful around month four, once there is a baseline to compare against and a process to change when the number moves. Measuring satisfaction before there is a close process is weighing yourself before breakfast to see whether the diet is working.
Volume: How Many, Per Week, By Category
Volume is the count of tickets created, per week, split by category. Per week rather than per day, because days are noisy and a Monday is not a Wednesday. The split is by category because a total of forty tells you nothing. A total of forty with twenty-two in "accounts and passwords" tells you what to fix first.
Volume answers two questions. The first is staffing: how much work arrives in a week, so you can say whether one person can do it. The second is hotspots: which category is biggest and which department sends the most. Both answers are only as good as the categories. That is why day zero starts with three categories and grows them from evidence rather than imagination.
Volume does not tell you whether the desk is fast, whether the fixes were good, or whether users are happy. It is a count. Forty tickets could be forty five-minute password resets or forty broken laptops, and the number looks the same. Volume is the desk's heart rate, not its temperature.
Rising volume in month one is good news, and it is often read as the opposite. More tickets in week three than week one means more people have found the desk and fewer are walking up or writing to the old address. The desk is not getting worse. It is getting found.
Age: The Oldest Open Ticket and the Count Over a Week Old
Age is two numbers that behave as one. They are the age of the oldest open ticket, in days, and the count of open tickets older than a week. The first has a ticket number and a story attached. The second tells you whether the first is a fluke or a habit.
Age tells you whether tickets are hiding. A ticket hides when it has an owner who is busy, a status that sounds like progress, and nobody asking about it. The queue does not sort by shame. The oldest open ticket is the one the desk has most completely forgotten. Naming it out loud in the weekly review is the cheapest way to un-forget it.
Age beats average resolution time in month one, and the reason is arithmetic. An average is pulled toward the many fast tickets; one ticket open for forty days disappears inside an average of two. The oldest open ticket cannot hide inside anything. It is the number a requester would quote if you asked how the desk was doing.
Age has an honest exception. Some tickets are old because they are waiting on a vendor, a part, or a decision from outside the desk. Give those a status that says so and a date you expect to hear back. They still count. They are just not a mystery, and the point of the age number is to find mysteries.
Reopen Rate: Reopens Per Closed Ticket
The reopen rate is the number of closed tickets that came back, divided by the number closed, in the same period. A reopen is a ticket the desk said was done and the requester disagreed with. The requester might reply to it, call about it, or open another one with the same subject line and a sharper tone.
Reopens tell you one of two things, and you have to read the tickets to know which. The first is the closing habit: technicians closing on their own judgment. They close without the resolution note and the confirmation that the close process asks for. The second is fix quality: the fix fixed the symptom and left the cause, so the printer that "works now" stops working on Thursday. The closing habit is the more common cause and the easier fix, which is a pleasant combination and a rare one.
Reopens have a way of not being counted. A requester's reply to a closed ticket might land in a mailbox instead of reopening the ticket. Or the requester might open a fresh ticket because the old one looks finished. In either case, the reopen is recorded as new volume and the rate stays at a flattering zero. A reopen rate of zero in month one is almost never good news. It is usually a counting problem wearing a medal.
The first desk I ran reported a zero reopen rate for two months, and I was briefly proud of it. The requesters, it turned out, were replying to the receipt e-mail, which went to an address nobody read. Then they were opening new tickets with the word "still" in the subject. The real rate was about nine percent. Fixing the counting came first; fixing the fixes came after, which is the right order.
Getting the Three From Any Tool
Each of the three numbers needs a handful of fields that every ticket tool has, and a spreadsheet has if you add the columns. List them now so you can check, before the first real ticket, whether your tool records them. Switch on whatever is missing while switching it on costs nothing.
| Number | Fields needed | How to count it |
|---|---|---|
| Volume | Created date; category | Count tickets by the week they were created, then by category within the week |
| Age | Status (open or closed); created date; a "waiting on" status with an expected date helps | Sort open tickets by created date; the top one is the oldest; count those created more than seven days ago |
| Reopen rate | Closed date; a reopen counter, or a status change from closed back to open; a close that a requester's reply can undo | Count tickets that went from closed to open in the period, divided by tickets closed in the period |
The one that trips people is the reopen. A tool that lets a requester's reply reopen the ticket and keeps a count makes the number free. On a spreadsheet, add a column called "reopened" and a rule that a reply after close ticks it. The rule matters more than the column.
Export once a week and keep the export. Month one's numbers are the baseline every later number is compared with, and a baseline you cannot reproduce is an opinion. One file per week, named by the week, in a folder that is backed up. The folder will outlive the dashboard.
Reading the Three in Month One
The three numbers in month one are read against a range, not a target. A target is a number you promise. A range is a number you expect. The difference matters when the desk is five weeks old. Outside the range is not failure. It is a question, and the table gives you the question.
| Number | A healthy month-one range | If it is below | If it is above |
|---|---|---|---|
| Volume per week | Over a month, between roughly one ticket per three people and one ticket per person across the organization; rising week on week | Who is still walking up or writing to the old address? Which department is missing from the count? | Is one category swallowing the desk, and can it be fixed at the source rather than one ticket at a time? |
| Oldest open ticket; count over a week old | Oldest under ten working days; fewer than one in ten open tickets older than a week | Fine; check that nothing is being closed early to keep it so | Who owns it, what is it waiting on, and does the status say so? Is there a second one like it? |
| Reopen rate | Between two and eight percent of closed tickets | Are reopens being counted, or arriving as new tickets? | Is it the closing habit (no note, no confirmation) or the fix itself? Which category are they in? |
The ranges are wide on purpose, because organizations generate different desks. A hundred people who each have a laptop and six applications send more tickets than a hundred who share four terminals in a warehouse. Treat the range as a sanity check in month one and replace it with your own baseline in month two. Your own baseline is the only range that was ever going to fit you.
A Worked Example: Dana's First Month at Northgate Retail
Dana launched the Northgate Retail help desk for two hundred and forty staff across a head office and two warehouses. She launched on a Tuesday, with three categories and one address. She exported the queue every Friday at 16:30. Here is what the three numbers said at the end of week four, and what she did about each.
Volume: thirty-one tickets in week one, forty-four in week two, thirty-eight in week three, forty-one in week four. One hundred and fifty-four in total, a little under forty a week. By category, fifty-two were accounts and passwords, thirty-eight hardware, twenty-seven printing, twenty-two applications, and fifteen other. The two warehouses had sent eleven tickets between them for ninety staff, which Dana noticed first and asked about first. They had been phoning the head office receptionist. From week three the receptionist opened tickets on their behalf, and the warehouse count was nine in week four alone.
Age: on day thirty the oldest open ticket was 1087, nineteen days old, a laptop waiting on a replacement screen from the supplier. Six tickets were over a week old. Four were waiting on the same supplier, and two were waiting on Dana, who had not noticed. She created a "waiting on vendor" status with an expected date, and moved the four into it. She did the other two on the Friday afternoon. Each took under twenty minutes. Each had been open for twelve days.
Reopen rate: seven reopens on one hundred and thirty-nine closed, which is five percent. Five of the seven were the same shared printer on the second floor, "fixed" five times by restarting the print spooler. Dana wrote a one-paragraph article on the real cause, a driver mismatch on the print server. Printing went from twenty-seven tickets in month one to nine in month two.
Her month-one note to her manager was one line long and ended with the three decisions: reception logs warehouse calls, vendor-wait status with dates, printer article. Nothing about staffing. The numbers had not asked for it yet.
What Not to Measure Yet
Four numbers appear on every dashboard template and should wait until about month three: satisfaction, first-contact resolution, time to resolution by priority, and agent productivity. They are not bad numbers. They need two things a new desk does not have: a baseline to compare against, and a process whose change they would drive.
Satisfaction, usually called CSAT, is the average rating requesters give after a ticket closes, on a short scale with a comment box. It needs a close process that sends the rating request and enough closes for an average to mean something. In month one you might have thirty ratings and an average that moves a full point when one person has a bad morning. Switch the question on in month one if your tool has it. Read every comment, and do not chart the average until month three.
First-contact resolution is the share of tickets resolved in the first reply, without a hand-off. It is a tier metric, and it needs tiers to mean anything. A one-person desk resolves everything on first contact by definition, including the things it should have escalated. It belongs to the tiers pillar, and to a desk that has some.
Time to resolution by priority needs priorities that mean something, which means a priority rule that triage applies the same way every time. Measured before that, it reports resolution speed sorted by what the requester typed in the priority box, which is a number about optimism. It becomes real alongside an SLA, and SLAs have their own pillar.
Agent productivity, tickets closed per technician, is the one to handle with gloves, because it changes behavior the moment it is measured. Technicians measured on closes close faster. Some closes come back, and you have spent your reopen rate to buy a productivity number. On a desk of one or two people it tells you nothing you could not learn by looking up from your chair. Leave it until workload per agent is a real question, and even then read it next to the reopen rate.
The One-Line Monthly Note
At the end of month one, write one line and send it to whoever asked for the desk. The line carries the three numbers, one clause each, and the decisions taken because of them. It replaces the dashboard for everyone who is not running the desk, which is everyone except you.
MONTH ONE: 154 tickets (about 40 a week; top category accounts, 52). Oldest open: 19 days (vendor part, dated). Reopens: 5% (printing). Changes: reception logs warehouse calls; vendor-wait status; printer article.
One line, because a line gets read and a page gets filed. Writing it also forces the decisions out. If you cannot fill in the "changes" clause, the numbers were looked at and not used, and that is the month's real finding. Send the line on the same day each month. Managers forgive a desk a great deal if it reports on time in a format that fits on a phone.
What happens without it is the request for a dashboard. A manager who does not get a short, regular number will ask for a long, live one. And you will spend week six rebuilding the eleven gauges, this time with data, for someone who will look at them twice. The note is cheaper than the dashboard and read more often.
A Short War Story: Twelve Numbers at Bluewater Bank
Bluewater Bank's branch support desk went live with a dashboard of twelve numbers, built by Tomas before the first ticket. The bank was used to dashboards, and it seemed rude not to have one. The desk ran well. At the end of month three, Tomas went back through the weekly review notes. He wanted to see which of the twelve had ever caused anyone to do anything. Three had. Volume by category had moved the branch printers onto one driver. The oldest open ticket had found a vendor case nobody was chasing. The reopen rate had rewritten the resolution reply. The other nine had been looked at, nodded at, and left alone. Tomas kept the twelve on the screen, because the bank liked them. He moved the three to the top of the weekly review, where the decisions had been coming from all along.
I have built that dashboard too, more than once. It is restful to look at. It never told me anything in eight weeks that the three numbers would not have told me in one.
The Month-One Metrics Sheet
The sheet below is the whole of month-one reporting, and the last column is the reason it exists. Fill it in at the weekly review, on the same day each week, and carry the "decision taken" column into the monthly note. A row with four weeks of numbers and nothing in the last column is a number you are watching rather than using.
| Number | How it is counted | This week | Last week | Question it answers | Decision taken |
|---|---|---|---|---|---|
| Volume per week, by category | Tickets created this week; the top three categories named with their counts | How much is arriving, and from where? | |||
| Age: oldest open ticket, and count over a week old | Open tickets sorted by created date; the oldest named by number and owner; count of those older than seven days | Is anything hiding? | |||
| Reopen rate | Reopens this week divided by closes this week, as a percentage; the category with the most reopens named | Are we fixing or closing? |
A tool that keeps the counts live saves the export step. A dashboard can show how many tickets are waiting on you, how many have an overdue response and how many were recently reopened. That is the three numbers in a different coat. QuerySolv's dashboard counts exactly those, with a backlog-by-age report behind it for the oldest-ticket question. Whatever the tool, the "decision taken" column is still a human's job, and no dashboard has a gauge for it.
Turn the wall screen off in month one, or leave it on and stop looking at it; either works. Keep the sheet. In month four, when there is a baseline, a close process and a priority rule, switch the gauges on one at a time. Do so only when you can name the decision each would change. The eleven gauges will still be there. They are patient, which is the one thing a gauge is good at.
Frequently Asked Questions
Why count volume per week rather than per day or per month?
Our tool has no reopen counter. How do we measure reopens?
Should tickets waiting on a vendor count toward the age number?
When should we add customer satisfaction?
What is a normal ticket volume for an organization our size?
Who should see the three numbers?
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.
