Every ticketing system has a reports page, and most of it is noise. Tickets closed per technician rewards quick closes over correct ones. Average resolution time hides the one ticket that took three weeks. Volume goes up when the service improves, because people start reporting things.
A short set of metrics, each measured the same way every month and each tied to an action, is worth more than a dashboard. This post covers the ones we track for a managed helpdesk, how to pull them, and what to do when they move.
First response time
First response is the time from a ticket being created to a human replying with something more than an acknowledgement. It is the metric users feel most directly, because it answers the question 'does anyone know I am stuck'. Measure it by severity and by hour of day, since a critical ticket at 3am and a low ticket at 3pm are different promises.
Report the percentage that met the target for each severity and the median, not the average. A handful of missed weekend tickets can drag an average without telling you anything. When the number slips, look at the queue by hour: it is usually a staffing gap at a specific time, not a general slowness.
- Measure from ticket creation to first human reply, excluding auto-responses
- Report per severity: percentage within target and the median
- Break it down by hour and weekday to find the gaps
- Exclude tickets created by monitoring that need no reply, or count them separately
Resolution time and the paused clock
Resolution time is useful only if the clock stops while you wait on the requester, a vendor or a part. Configure the ticketing system's waiting states so that time is excluded, and report raw and adjusted figures together so nobody suspects the numbers. Then look at the distribution: the median tells you how a typical ticket goes, and the tail tells you where the process breaks.
The tail is the interesting part. Pull the ten oldest open tickets every week and ask why each one is still open. Waiting on a vendor with no follow-up, assigned to someone on leave, or a request that was really a project and should be scoped as one. Those ten tickets teach more than the average ever will.
- Configure waiting-on-customer and waiting-on-vendor states to pause the clock
- Report median resolution per category, raw and adjusted
- Review the ten oldest open tickets weekly with a reason and an action for each
- Convert anything that is really a project into a scoped project ticket
Reopen rate and first-contact resolution
Reopen rate is the share of closed tickets that the requester reopens within a set period, commonly a week or two. It is the honest counterweight to closing speed: a technician who closes fast and gets reopened often is not fast. Track it per technician and per category, and treat a rising number as a training or process signal rather than a discipline issue.
First-contact resolution is the share of tickets fixed in the first interaction without escalation or a follow-up. It rises when the front-line technicians have good documentation and the right access, and it falls when they have to hand off for routine things. If it is low, the fix is usually in the runbooks and the permissions, not the people.
- Reopen rate: reopened within the window divided by closed, per technician and category
- First-contact resolution: fixed on first interaction divided by total, per category
- Rising reopens: check whether tickets are being closed before the user confirms
- Low first-contact: check which categories get escalated and write the missing runbooks
CSAT and what to do with the comments
A one-question survey on ticket close, with an optional comment, gets enough responses to be useful if it is short. Report the score as the share of positive responses, and report the response rate beside it, because a high score from a tiny sample means little. Read every comment. The negative ones with detail are the most valuable feedback a helpdesk receives.
Close the loop on negative responses within a day: a call or a message from the account lead asking what went wrong. Then bring the themes to the monthly review with the team and to the quarterly review with the client. A metric that never changes anything is a number on a page. If you want to compare your helpdesk numbers with how a 24/7 desk runs them, RackLedge is glad to talk through it.
- One question, optional comment, sent on ticket close
- Report positive share and response rate together
- Contact every negative respondent within a business day
- Bring comment themes to the team monthly and the client quarterly
Frequently asked questions
Should technicians see their own metrics?
Yes, with context. Metrics per technician are for coaching and workload balancing, not for a leaderboard. Reopen rate and CSAT comments are the ones that help an individual improve; ticket counts mostly encourage fast closes.
How many metrics should we report to the client?
Four or five, the same ones every quarter: first response attainment, adjusted resolution median, reopen rate, CSAT, and ticket volume by category. Consistency lets them see trends; a new chart every quarter does not.
What is a good reopen rate?
Lower than last quarter. Absolute benchmarks vary too much by environment and by how strictly reopens are counted. Track your own trend and investigate the categories where it rises.
Takeaway
First response, adjusted resolution with the oldest-ten review, reopen rate, first-contact resolution and CSAT with the comments read. Measure each the same way every month, report medians and percentages rather than averages, and attach an action to every movement. Five numbers that change behavior beat fifty that decorate a dashboard.