Service Desk KPIs: FCR, CSAT, and What to Do With Them
Measure service, not activity
Most service desk scorecards are full of numbers that move without telling you anything. Tickets closed, average handle time, first-response speed — these are activity metrics. They go up when the team is busy and down when it is quiet, and a busy team is not the same as an effective one. You can close a thousand tickets a month and still have users who dread contacting IT, because the same problems keep coming back and nothing ever gets fixed at the root.
The KPIs worth reporting answer a different question: is the service actually good, and is it getting better? That means measuring resolution quality, user experience, and how work ages in the queue — then tying every number to a decision someone will make on Monday. Below are the five metrics we hold our own managed help desk to, why each one matters, and the specific ways each gets quietly gamed.
The five KPIs that reflect real service
First-contact resolution (FCR)
FCR is the share of tickets resolved in a single interaction — no callback, no escalation, no "we'll get back to you." It is the strongest single predictor of user satisfaction because it maps directly to the thing users actually want: their problem gone, now. Industry benchmarks commonly place healthy FCR in the region of 70 percent for a general corporate service desk, though the right target depends heavily on your ticket mix.
Define it precisely or the number is fiction. Decide up front whether "contact" means one phone call, one chat session, or resolution within a single business day, and whether an internally escalated ticket that never leaves the desk still counts as first contact. Two analysts computing FCR differently produce a trend line you cannot trust.
Customer satisfaction (CSAT)
CSAT is the direct voice of the user, usually a short post-ticket survey scored one to five. Its weakness is coverage: response rates are often in the low double digits, and the people who respond skew toward the delighted and the furious. Treat a single score with suspicion; treat the trend and the written comments as gold. The free-text field on a two-star response will tell you more about a broken process than any dashboard.
Watch for survey fatigue. Surveying every ticket trains users to ignore the prompt. Sampling, or surveying only on ticket closure rather than every update, keeps response rates meaningful.
Time to resolve by priority
A blended average resolution time is close to useless because it mixes a password reset with a failed server migration. Break it out by priority tier, and report against the target you actually committed to in your service level agreement. A P1 outage measured against a four-hour target and a P4 request measured against three business days are two different promises; averaging them hides both.
Report medians and a high percentile — the 90th or 95th — not just the mean. A handful of tickets that dragged on for days will pull an average far away from the typical case. The median tells you the normal experience; the 95th percentile tells you how bad your worst realistic week looks.
Reopen rate
The reopen rate is the share of resolved tickets that come back. It is the essential counterweight to every speed metric. Push resolution time down hard enough and you get premature closures — tickets marked done that were never fixed — and the reopen rate is where that shows up. A desk with a fast MTTR and a climbing reopen rate is not efficient; it is closing tickets that will cost you twice.
Backlog aging
Total open ticket count is a vanity number. What matters is how long tickets have been sitting. Age your backlog into buckets — under a day, one to three days, three to seven days, over a week — and watch the old end. Tickets that quietly rot for weeks are where users lose faith, and they are almost always the ones no single owner felt responsible for.
Figure: pair every speed metric with a quality metric — a fast resolve time next to a rising reopen rate means tickets are being closed, not solved.
How every one of these gets gamed
The moment a number becomes a target, people optimize the number instead of the outcome. This is Goodhart's law, and a service desk offers a rich menu of ways to hit a KPI while the service gets worse:
- FCR gaming: log a follow-up as a brand-new ticket so the original looks first-contact resolved. Catch it by tracking linked and repeat tickets from the same user on the same issue within a short window.
- CSAT gaming: send the survey only to the easy, cheerful tickets, or close a hard ticket and immediately reopen a fresh one to dodge a bad score. Catch it by auditing survey coverage against total closures.
- Resolve-time gaming: mark a ticket resolved the instant a workaround is offered, restarting or stopping the clock while the user is still broken. Catch it with the reopen rate and by measuring time-to-resolve from the user's perspective, not the technician's.
- Backlog gaming: mass-close aged tickets as "no response from user" to clean the queue. Catch it by tracking bulk-closure events and auditing a sample.
The defense is structural, not moral. Never report an efficiency metric without its paired quality metric: FCR next to reopen rate, resolve time next to CSAT, backlog size next to backlog age. When gaming one number visibly damages another on the same page, the incentive to game it disappears.
Metrics are a starting point, not an answer
A KPI tells you something is wrong; it does not tell you why. That is the job of problem management, and it is where most service desks stop short. The workflow that turns metrics into improvement looks like this:
- Categorize consistently. Every ticket gets a real category and subcategory, chosen from a controlled list, not free text. Sloppy categorization makes root-cause analysis impossible.
- Find the vital few. Pareto analysis almost always shows that a small number of categories generate the bulk of your volume — VPN failures, a flaky application, one confusing provisioning step.
- Open a problem record. Group the recurring incidents under a single problem and assign an owner whose job is the root cause, not the next ticket.
- Fix once, measure the drop. A permanent fix — a configuration change, automation, a knowledge-base article, a vendor escalation — should show up as a measurable fall in that category's volume the following month.
This is the difference between a desk that clears tickets and one that eliminates them. It also connects the service desk to the rest of your operation: a spike in a specific error category can be the first sign of a broader issue, which is why service desk trends should feed the same review that drives your incident response and change processes rather than living in an isolated report.
Reporting that drives action
A report nobody acts on is overhead. Make yours a control system with three habits:
- Report to two audiences differently. Leadership needs CSAT trend, SLA attainment, and the top three ticket drivers in plain language. The desk needs FCR by technician, reopen rate by category, and aging detail so they know what to fix this week.
- Review trends, not snapshots. One month is noise. A six-month trend in reopen rate or backlog age is signal. Tie every trend to a specific change you made — a new runbook, an automation, a resolved problem record — so the report shows cause and effect, not just the weather.
- Close the loop every cycle. Each review should produce at least one problem record or process change, and the next report should show whether it landed. If no number ever drives a decision, you are measuring for decoration.
Good service desk metrics are not a report card you file and forget. They are the instrument panel that tells you where users are being failed, where fast work is hiding rework, and which handful of root causes are generating most of your load.
If your service desk reports are full of green dashboards but users still complain and the same tickets keep returning, it may be time for an outside read. intSignal builds first-contact resolution, honest quality metrics, and problem management into our complete IT support service. When you want a service desk measured on outcomes rather than activity, talk to our team.