Help desk metrics are the numbers that show whether your queue keeps its promises. They cover how fast a technician answers, how long fixes take, how many tickets meet the SLA, and whether fixes stay fixed. Start with three of the eleven below.
The guide comes from the team behind SherpaDesk, a helpdesk and professional services automation (PSA) tool a small IT team can run alone.
Key takeaways
Help desk metrics measure everyday queue operations. A key performance indicator (KPI) is different: it's tied to a specific goal and how well it's being met.
"Median P2 resolution time" is a metric; "90% of P2 tickets resolved within three business days" is a KPI.
The same numbers are also called service desk metrics; the formulas don't change. Scope differs, as our helpdesk vs service desk guide explains.
The eleven metrics below are a menu, not a checklist.
In a small team, you probably run the queue and the reporting yourself, so metrics replace guessing about hires and SLA promises. One r/msp member's warning applies: "Bad KPIs are worse than no KPIs because people work toward whatever they're measured on." SLA guidance agrees: metrics should reflect factors within the provider's reasonable control and motivate the appropriate behavior. If a technician can hit the number by doing worse work, the number is wrong.
We found no neutral benchmark with a sample behind it, so each target below comes from your own data.
The last column names the metric that exposes gaming of the first.
| Metric | Formula | Why it matters | Pair it with |
|---|---|---|---|
| First response time | First human reply − ticket logged, on the calendar for that priority and clock; median per priority | Users know someone has the ticket | Resolution time |
| Resolution time | Resolved − logged, on the calendar for that priority and clock; median and 90th percentile | How long users wait for a fix | Reopen rate |
| SLA compliance | Tickets meeting target ÷ tickets measured × 100, per priority and clock | Your promise in one number | Open tickets past target |
| Backlog | Open tickets, counted at the same time each week | Whether intake outruns capacity | Ticket aging |
| Ticket aging | Open tickets by age in full calendar days: 0–2, 3–7, 8–30, >30 | Where stuck work sits | Auto-closed tickets |
| Reopen rate | Tickets in a month's closures reopened within your window ÷ unique tickets closed × 100 | Whether fixes hold | Resolution time |
| First contact resolution | Tickets resolved on the first contact ÷ all tickets in the cohort × 100 | Fixes with no follow-up | Reopen rate |
| CSAT | Answers rated 4 or 5 of 5 ÷ all answers × 100 (this guide's rule) | How users felt about the ticket | Survey response rate |
| Tickets per technician | Tickets closed ÷ technicians, by category | Team throughput trend | Hours logged per ticket |
| Billable utilization (MSP) | Billable hours ÷ available hours × 100 | Share of the week that's billable work | Realization, reopen rate |
| Cost per ticket (internal IT) | Monthly support cost ÷ tickets closed | What a ticket costs the budget | Tickets per user |
Settle these rules before the first report.
Our rule: every clock starts when the ticket is logged. Response stops at the first human reply, not the auto-acknowledgment; resolution stops when the fix is confirmed.
If your SLA promises a P1 response at any hour, that clock runs continuously. Response and resolution for one priority can have different coverage hours; every clock that isn't 24/7 counts only its own coverage hours. A P3 logged at 7 a.m. on Saturday and answered at 8:15 a.m. on Monday waited 15 minutes if coverage starts at 8 on weekdays.
Common mistake: one calendar for every clock, which makes 24/7 promises look kept.
Use the same four priorities your SLA uses, P1 (whole company stopped) to P4 (request, nobody stopped), as in our SLA template and guide to ticket priority levels. As one r/sysadmin member put it: "I'm wary of percentages, as they become prone to dilution if there's mixed ticket classes."
The median is the value with half the data below it and half above. Extreme values distort the mean but not the median. The example shows why.
Example: eight tickets close in 2 hours and two in 40. The mean is 9.6 hours, the median 2 hours, and the 90th percentile 40 hours.
Definition. The time from ticket logged to the first reply from a person.
Formula. First human reply − ticket logged, on the calendar for that priority and clock. Report the median per priority.
How to read it. A rising median with flat volume can point to a routing or coverage gap. Check categories, clients, and hours before adding staff.
Target. Compare the median with your own last quarter. Meeting the contract is a separate number, the share of responses inside the SLA threshold (in our template's example, 30 minutes for P1): see SLA compliance.
The trap. Replies get faster but emptier: an instant "can you send more details?" stops the clock. Count only replies that move the ticket.
Definition. The time from ticket logged until the issue is resolved.
Formula. Resolved − logged, on the calendar for that priority and clock. Report the median and the 90th percentile, per priority and per category.
How to read it. The median shows a normal ticket; the 90th percentile shows the slow ones. A rising 90th percentile with a steady median can point to a few stuck tickets.
Target. Last quarter's median per priority.
The trap. Fast closes that don't hold. Report time paused on the user separately.
Definition. The share of tickets that met their SLA target, per priority and per clock. Score response and resolution separately.
Formula. Tickets meeting target ÷ tickets measured × 100.
Example. Say 40 P2 tickets close in March and 3 miss the response target. That's 37 of 40, or 92.5% on response, above a 90% goal. It's the scoring in our service level agreement template.
How to read it. Read P1 on its own. Say 5 of 100 tickets are P1s and all 5 miss: if the other 95 met target, the month can still score 95%.
Target. The goal in your SLA, per priority and clock, or one agreed with the people the desk serves.
The trap. A P2 open six business days has already missed a three-day resolution target, but a closed-ticket report won't count it yet. List open tickets past target beside the figure.
Definition. Backlog is the count of open tickets at a point in time; aging splits it by ticket age.
Formula. Count open tickets at the same time each week. Age in full calendar days: 0–2, 3–7, 8–30, and >30.
How to read it. Little's Law: the average number of items in a queue equals the average arrival rate multiplied by the average time each item spends in it. For a helpdesk, an approximation: average open tickets ≈ tickets logged per day × mean days a ticket is open.
It works over a long enough period, when tickets opened and closed roughly balance and the backlog isn't growing. Use the arithmetic mean of each ticket's full open time, on the same calendar as intake. Take the average queue from frequent counts across the working day, or from status history, not from weekly snapshots.
Example: 12 tickets a business day at a mean of 2.5 business days open is about 30 open on average. A measured average well above that suggests tickets stay open longer than you think.
Average open tickets
tickets per day × mean days open (Little's Law), an approximation when opens and closes balance. Your numbers stay in the browser.
Target. Pick the mean open time you want and multiply by intake: 12 a day at a 2-day mean is about 24 open. Review the >30 bucket weekly.
The trap. Auto-closing silent tickets. The backlog drops, the problems stay. Count auto-closes separately.
Both are rates on one sample: the unique tickets closed in one month, with a reopen window you choose, such as 14 days.
Definition. The share of closed tickets that come back for the same issue within your reopen window.
Formula. Tickets from the month's closures reopened for the same issue within the window ÷ unique tickets closed that month × 100. Report it once the window has passed for the whole cohort.
How to read it. A rising reopen rate can point to tickets closing before the fix holds; check which categories reopen.
Target. Your own last quarter, by category.
The trap. False reopens: a "thank you" reply or a new problem on an old ticket. Count only the same issue returning.
Definition. The customer's need is met the first time, with no follow-up, on any channel: chat and email count, not just calls.
Formula. Cases resolved on the first try ÷ total cases × 100. Count it on a closure cohort whose observation window has ended.
How to read it. "First try" needs a definition. One rule treats a contact as resolved if the customer doesn't come back within a window, such as 30 days; others use a follow-up survey. Our operational rule for a ticket queue: one technician reply closes the ticket, and it doesn't reopen inside the window.
Target. Your baseline per category. Network faults won't score like password resets.
The trap. Technicians hold tickets they should escalate. Pair it with reopen rate.
Definition. This guide's rule: CSAT is the share of post-close survey answers rated 4 or 5 on a 5-point scale.
Formula. Answers rated 4 or 5 ÷ all answers × 100.
How to read it. Read the response rate first: a score from a few replies speaks only for those users. With 12 responses, one unhappy user moves the score about 8 points.
Target. Your own trend over a quarter.
The trap. Surveying only tickets you expect to go well.
Definition. The team's tickets closed per technician in a period: a team trend, not one person's load.
Formula. Tickets closed ÷ technicians, split by category.
How to read it. As one r/sysadmin member put it: "That one quick password reset counts just as much as that 3 hour rebuild/reinstall." Read counts by category, next to the hours logged per ticket.
Target. None per person. Use the trend, by category, for capacity planning.
The trap. Ranking technicians by count. The technician who takes the hardest tickets may close the fewest.
Definition. The share of available hours logged as billable work. Available hours are paid working hours minus holidays and leave.
Formula. Billable hours ÷ available hours × 100, on actual minutes logged. It's the same definition as our guide to billable hours tracking.
How to read it. It shows the billable share of the week, not money; whether those hours were invoiced at full rate is realization, covered in the same guide. It fits hourly, block, and overage work. A mostly flat-fee team should use client-work load from the same guide instead: (billable hours + included client hours) ÷ available hours × 100.
Target. Your own team figure over a month. Look per person only to spot overload.
The trap. Utilization as the only KPI. One r/sysadmin member at an MSP described a team where "every minute must be spent on an active ticket and nothing on prevention or documentation."
Definition. What one closed ticket costs the support budget.
Formula. Monthly support cost (salaries, tools, outside help) ÷ tickets closed that month.
How to read it. Compare quarters with the same cost lines.
Target. Your own trend, next to tickets per user or device.
The trap. It falls when preventable tickets rise.
Start with three. Add one when a question needs it.
| Team | Start with | Add next |
|---|---|---|
| MSP | SLA compliance per client and priority, reopen rate, billable utilization (or client-work load if mostly flat-fee) | Backlog aging per client, CSAT |
| Internal IT | First response time, resolution time by category, backlog aging | CSAT, cost per ticket |
| K-12 school or district | Backlog aging, resolution time by category, first response time | Tickets per site, CSAT from staff |
Subscribe to the SherpaDesk Blog.
Get Tips for Running IT With a Small Team.
Loading form…
The form couldn’t load. Please try again.
Or start your free trial →SHERPADESK · FREE TRIAL
Resolve tickets.
Turn time into revenue.
Bring support tickets, billable time, and invoicing into one place. Built for small IT teams and MSPs.
After your trial, keep your first agent free forever.
SHERPADESK · LIVE DEMO
See tickets, time,
and billing work together.
Walk through ticketing, time tracking, and billing with a product specialist. See how SherpaDesk fits the way your team works.
A live walkthrough tailored to your team.
These numbers are easier to trust when the SLA times and the time entries sit on the ticket itself.
How this works in SherpaDesk
You want to know whether P1 and P2 tickets kept their promise this month. Give each priority an SLA response goal and a completion goal, and define your business hours and holidays. Then open Reports > SLA & Priority: the On-Time Report and the Goal vs. Actual Report cover closed tickets, by response or completion. Group or filter by priority; without that, the report uses a blended goal. A reopened ticket's completion time resets from the latest reopening, so count reopens as their own number.
Time logs carry billable and non-billable hours, and the Ticket Assignment and Transition Report shows time per assigned technician.
A helpdesk and PSA a small IT team can run alone. No contract. No implementation project. No dedicated admin. Base Camp is $45 per agent per month ($40 billed annually), the first agent is free, forever, and the trial is 14 days free with no card.
Who this isn't for
Phone-first contact centers; this guide covers ticket queues. In SherpaDesk, there's no built-in survey tool: you add your own CSAT survey link to the closed-ticket email.
Start with three. An MSP starts with SLA compliance, reopen rate, and billable utilization, or client-work load if most contracts are flat-fee. An internal team or school starts with first response time, resolution time by category, and backlog aging. Add CSAT or cost per ticket when a question needs it.
Judge it two ways: the median against your own last quarter, and the share of responses inside your SLA threshold, per priority, on that clock's calendar. If nobody covers P1 tickets after hours, don't promise an any-hour response: write the coverage hours into the SLA. Without an SLA, promise what you already hit on 90% of last quarter's tickets.
Report the median for a normal ticket and the 90th percentile for the slow ones, per priority. In a spreadsheet, that's MEDIAN() and PERCENTILE.INC() with 0.9 over one month of closed tickets. Keep the mean for one job: the backlog math in Little's Law, which needs it.
Don't set one: a per-person quota rewards easy tickets. Track tickets per technician as a team trend, by category. If team counts rise for months while resolution time worsens, that can point to a capacity gap. Check the category mix, clients, and routing before you hire.
Take every ticket closed in one month, wait until your reopen window has passed, and count the tickets closed by a single technician reply that didn't reopen. Divide by all tickets in that month's closures and multiply by 100. Write both rules down so every month counts the same way.
Patrick co-founded SherpaDesk and has led it as CEO since 2013. He has worked with IT service providers since 1998, first on network projects for schools and government offices, then on the helpdesk software their technicians use every day.