Blog
Stay up to date
Subscribe to the blog for the latest updates
Every IT help desk generates data. Ticket counts, response logs, satisfaction scores, escalation chains — it piles up fast. The problem is not a lack of data. The problem is knowing which numbers tell you something real.
Track too few metrics and you're flying blind. Track too many and the dashboard becomes noise. Most teams land somewhere in the middle: monitoring the same five or six numbers they always have, hoping that's enough.
It usually isn't. Especially in 2026, where hybrid work has lengthened support chains, AI tools have changed what 'resolved' actually means, and employee expectations of IT have quietly risen to match the consumer apps they use outside work.
This guide covers the 15 help desk metrics that give you a clear picture of how your support operation is actually performing — not just how busy it is. Each one is defined in plain terms, with a formula, a realistic scenario, and a benchmark where credible data exists.
Whether you're running a 5-person IT team or a 500-person service desk, these are the numbers worth your attention.
First Contact Resolution (FCR) rate is the percentage of support tickets resolved during the very first interaction — without the employee needing to follow up, call back, or reopen the ticket.
Formula: (Number of tickets resolved on first contact ÷ Total tickets) × 100
FCR is one of the strongest predictors of customer satisfaction in IT support. When someone reports a broken printer or a password lockout, they want it fixed now — not after a second round of troubleshooting next week.
According to MetricNet, one of the leading IT benchmarking firms, customer satisfaction is strongly correlated with FCR across virtually every type of service desk environment. This holds true whether support is delivered by phone, chat, or email.
There are two versions of this metric worth knowing: Gross FCR counts all incoming contacts. Net FCR excludes contacts that genuinely cannot be resolved remotely — like hardware break/fix jobs that require a physical visit. Net FCR is more meaningful for evaluating agent performance, while Gross FCR reflects total operational load.
An IT team notices their FCR rate has dropped from 71% to 63% over two quarters. Digging in, they find a spike in unresolved VPN issues — agents are logging tickets but lacking the remote access tools to diagnose and fix the problem in one session. Adding a browser-based remote support tool lets agents view and control the employee's screen in real time, and FCR climbs back up within six weeks.
Industry Benchmark: MetricNet's benchmarking data shows the average First Contact Resolution rate for IT service desks ranges from approximately 70% to 75%. High-performing desks reach 85% and above.
Mean Time to Resolve (MTTR) is the average time from when a ticket is opened to when it is fully closed. This covers the entire lifecycle: first response, diagnosis, fix, and confirmation.
Formula: Total resolution time for all tickets ÷ Number of tickets resolved
MTTR tells you how long your employees or customers are actually waiting for their problem to disappear. A low MTTR means disruptions to productivity are short. A high MTTR means people are sitting with broken tools for hours or days — which has a direct cost in lost work time.
Moveworks benchmarking data shows a notable performance gap between organizations using AI-assisted support and those relying entirely on manual resolution: AI-enabled teams resolve high-complexity tickets in roughly 20 hours on average, while those without AI take 40 hours or more for the same category of issues.
MTTR is most useful when tracked by ticket tier or category. An MTTR of 4 hours is impressive for a complex network issue; it's a red flag for a password reset.
A support manager sees that the team's average MTTR is 6.2 hours, which looks acceptable on paper. But when broken down by category, password resets are taking an average of 3.4 hours — mostly because tickets sit in queue before being picked up. Automating password resets through a self-service portal drops that category's resolution time to under 5 minutes and improves the overall MTTR significantly.
Quick Tip: Track MTTR separately for Level 1, Level 2, and Level 3 tickets. Blended MTTR across tiers can hide real bottlenecks.
First response time is the time between when a ticket is created and when a support agent first takes documented action on it. This is not the same as resolution — it's just the acknowledgement that someone has picked it up.
Formula: Timestamp of first agent action − Timestamp of ticket creation
Research consistently shows that employees are far less frustrated by long wait times when they know their issue has been seen. First response time is the metric that governs that expectation. A fast first response — even if it's just 'we're on it' — significantly improves perceived quality of support, even when the actual resolution takes longer.
For email and web-submitted tickets, MetricNet identifies responding to and, where possible, resolving tickets within one business hour of submission as the emerging industry standard for what qualifies as strong first-contact performance. Response time targets will vary by channel and priority level, but the principle holds: acknowledge fast, even if you can't fix fast.
During a major software rollout, ticket volume spikes by 40%. First response times stretch from 22 minutes to over 3 hours. By setting up auto-acknowledgment emails that set clear expectations and routing high-priority tickets to a dedicated queue, the team restores confidence among employees — even before resolution times improve.
Ticket volume is simply the total number of support requests submitted in a given period — daily, weekly, or monthly. Volume trending is watching how that number changes over time, and understanding why.
Raw ticket volume is a planning tool. It tells you whether your current staffing level is realistic for the demand you're managing. But the more important part is the trend.
A sudden spike in tickets on a Monday morning might mean a weekend update broke something. A slow climb over three months might mean your onboarding process isn't effective, or a product is generating repeat confusion. A drop in volume after you publish new knowledge base articles tells you the content is working.
Volume alone doesn't tell you if your desk is performing well or poorly. But paired with other metrics, it adds necessary context.
A support team notices ticket volume spikes every time the HR team runs a software training session. Employees open new accounts, hit permission errors, and flood IT with access requests. Coordinating a 'preparation checklist' with HR before training days cuts the associated ticket volume by roughly a third.
Ticket backlog is the number of open, unresolved tickets at any point in time. A backlog forms when new tickets arrive faster than they can be resolved.
Formula: Total open tickets − Tickets resolved in the same period
A growing backlog is a capacity warning. If your team resolves 100 tickets a day but receives 130, the unresolved 30 carry forward. Left unchecked, backlogs create compounding problems: older tickets get forgotten, employees lose trust, and catch-up mode reduces quality.
The opposite is also worth watching. A backlog that drops to near zero might sound good — but it could mean demand has fallen because employees have stopped reporting problems, which is its own issue.
Predicted backlog — estimating future backlog based on current volume and velocity trends — is a useful planning metric. It helps managers anticipate staffing shortfalls before they become crises.
During an annual systems migration, a service desk sees its backlog grow from 45 tickets to over 300 in one week. Because they track predicted backlog as a metric, the manager sees this coming four days early and reallocates three agents from project work to support coverage — preventing the backlog from doubling further.
Note: Reviewing ticket backlog trends weekly rather than monthly is standard practice — monthly reviews often catch capacity problems too late for same-period correction.
Ticket distribution shows what share of your total ticket volume belongs to each issue type — password resets, hardware failures, software installation, access requests, connectivity problems, and so on.
Formula: (Tickets in category ÷ Total tickets) × 100 = % of total volume
If 35% of your tickets are password resets, that's a self-service problem masquerading as a support problem. If 20% are related to a single business application, that's a training gap or a product quality issue that no amount of support staffing will permanently fix.
Ticket distribution is the metric that shows you where to invest outside the help desk. It tells you which knowledge base articles to write, which processes to automate, which vendors to pressure on product quality, and which departments need more user training.
An IT manager pulls a quarterly distribution report and finds that 28% of all tickets relate to VPN connectivity — the top category by volume. Rather than hiring another agent, she works with the network team to simplify the VPN client configuration and publishes a step-by-step troubleshooting guide. Within 60 days, VPN-related tickets drop to 14% of total volume.
CSAT is a score collected from a short post-resolution survey asking the employee or customer how satisfied they were with the support they received. It's typically measured on a 1–5 scale, then expressed as the percentage of respondents giving a positive rating (4 or 5).
Formula: (Positive responses ÷ Total responses) × 100
CSAT is the most direct measure of whether your support actually felt helpful to the person on the other end. Technical metrics like MTTR and FCR tell you what happened. CSAT tells you how it landed.
A ticket can be technically 'resolved' — the issue is closed, the fix was applied — and still generate a low CSAT score because the agent was dismissive, the communication was unclear, or the fix required the employee to do too much work themselves.
For internal IT desks, low CSAT has a second-order effect: employees who are frustrated with IT start working around it. They rely on workarounds, delay reporting problems, or use unauthorized tools — all of which create larger security and productivity risks.
A service desk with strong FCR and MTTR numbers notices CSAT has been hovering at 72% for two quarters. After reviewing open-text survey comments, the team finds a recurring complaint: employees feel like agents talk over them and use too much jargon. A short communication training session for the team, focused on plain language and empathy, moves CSAT to 81% within the next quarter.
Industry Benchmark: Live chat support consistently achieves higher CSAT than other channels. According to Tidio's 2024 data, live chat CSAT averages around 87%, compared to 61% for email and 44% for phone.
A Service Level Agreement (SLA) is a commitment — often formally agreed upon with internal stakeholders or documented in an IT policy — about how quickly certain types of tickets will receive a first response and be resolved. SLA compliance rate measures what percentage of tickets are handled within those agreed timeframes.
Formula: (Tickets resolved within SLA ÷ Total tickets) × 100
SLA compliance is the most visible accountability metric for IT teams. When SLAs are breached, stakeholders notice — and IT credibility takes a hit. Consistently hitting SLA targets builds trust with the business and sets a clear quality floor for support.
Different ticket priorities should have different SLA targets. A critical outage affecting all employees might have a 30-minute resolution SLA. A non-urgent software request might have 48 hours. Tracking SLA compliance by priority level gives you a more accurate picture than a single blended rate.
After a company acquisition doubles the employee base, IT finds its SLA compliance rate dropping from 94% to 79%. Rather than adjusting the SLA targets downward to appear compliant, the IT director uses the compliance data to build a business case for additional headcount — and secures two new agents within the next budget cycle.
Escalation rate is the percentage of tickets that Level 1 agents cannot resolve and must hand off to Level 2 or Level 3 support — or to an external vendor.
Formula: (Tickets escalated ÷ Total tickets) × 100
Every escalation costs more than a Level 1 resolution — in time, in agent hours, and typically in employee wait time as well. A high escalation rate often points to one of three things: Level 1 agents lack the knowledge or tools to resolve certain issue types; the issues themselves are too complex for Level 1 by design; or the triage process is sending the wrong tickets to the wrong queue.
Tracking escalation rate by category helps separate these causes. If all VPN tickets escalate, it's a knowledge gap. If only specific database error tickets escalate, that may simply be appropriate for the complexity of the issue.
A tech company launches a new internal tool. In the first month, 60% of tickets related to that tool are escalated to Level 2. The IT team runs a focused knowledge-transfer session for Level 1 agents with the product team. The following month, escalation rate for that tool drops to 22%.
First Level Resolution (FLR) rate measures how many tickets are fully resolved by Level 1 support — without escalation — regardless of whether they were resolved on first contact. Note the difference from FCR: a ticket can achieve FLR even if the agent needed a second interaction with the employee, as long as the ticket never left Level 1.
Formula: (Tickets resolved at Level 1 ÷ Total tickets) × 100
FLR directly controls support costs. Level 2 and Level 3 support involves more skilled — and typically more expensive — staff. Every ticket that escalates past Level 1 costs more to resolve. A strong FLR rate means Level 1 is doing its job and higher-tier staff can focus on genuinely complex work.
MetricNet notes that FLR is distinct from FCR and worth tracking separately. A Level 1 agent might not resolve an issue on first contact — they may research it, call the employee back, and close it at Level 1 without ever involving a more senior tier.
FLR vs. FCR: FCR = resolved in one interaction. FLR = resolved at Level 1, regardless of how many interactions it took. Both matter, but they measure different things.
Cost per ticket is the total operational cost of running your help desk divided by the number of tickets handled in a given period. It captures agent salaries, software licensing, overhead, and other operating costs relative to support output.
Formula: Total help desk operating cost ÷ Total tickets resolved
Cost per ticket is the efficiency metric that finance teams and IT leaders both care about. It lets you compare the cost of different support channels (phone vs. email vs. chat vs. self-service) and assess the return on investments like AI tools or knowledge base development.
The metric is most useful as a trend rather than an absolute number. If cost per ticket is rising while ticket volume stays flat, it means your costs are growing faster than your throughput — which warrants investigation. If it's falling because you've deflected repetitive tickets to self-service, that's a concrete efficiency gain worth documenting.
An IT director compares cost per ticket across support channels and finds email tickets cost roughly 3x more to resolve than self-service submissions, primarily because email requires more back-and-forth. Investing in a better self-service portal and promoting it internally shifts channel mix — and reduces overall cost per ticket over the following two quarters.
Agent utilization rate is the percentage of an agent's working time spent on direct support activities — handling tickets, responding to users, participating in support sessions — versus time spent on admin, training, meetings, or idle time.
Formula: (Time spent on support activities ÷ Total available working time) × 100
Utilization rate needs to be interpreted carefully. According to MetricNet's benchmarking data, once agent utilization approaches 60–70%, service desks begin experiencing elevated agent turnover — agents are being pushed too hard. A rate above 70% is a burnout and quality risk: resolution quality drops, errors increase, and agents have no capacity to handle unexpected volume spikes.
The goal is keeping utilization well below that threshold. MetricNet's benchmarking database shows the average agent utilization across service desks worldwide is approximately 48% — which leaves agents enough time to research answers properly, document solutions, and absorb surges without quality degrading.
A team of 8 agents has an average utilization rate of 74%. On the surface it looks productive, but CSAT scores have been declining for two months and ticket reopen rates are climbing. When the manager gives each agent a protected 90-minute block each week for knowledge base contributions — pulling them off the live queue — resolution quality improves and the team starts building reusable articles that reduce future ticket volume.
Self-service deflection rate measures the percentage of support issues that employees resolve on their own — through a knowledge base, FAQ, AI chatbot, or self-service portal — without ever creating a ticket for a human agent.
Formula: The most reliable formula, as defined by ServiceXRG, accounts for intent: Deflection = Self-help events by entitled users × Success rate × Intent rate × No-further-action rate. Simpler approximation: (Issues resolved via self-service ÷ Total support demand) × 100
Deflection rate is a direct measure of how much work your self-service investment is actually doing. Higher Logic's widely cited research found that 92% of consumers say they would use an online knowledge base if one were available. According to Salesforce's 2025 data, 80% of high-performing service organizations offer a self-service option, compared to 56% of lower performers.
A higher deflection rate means fewer tickets entering the queue — which reduces agent load, shortens wait times for tickets that do come in, and cuts cost per ticket. Most organizations target 20–30% deflection as a baseline; teams with strong knowledge bases and well-implemented AI tools often achieve higher.
One important note from ServiceXRG: only count a deflection when the user was entitled to assisted support but chose not to use it because self-service met their need. Counting all knowledge base visits inflates the number.
An IT team publishes guides covering their 10 most common ticket types — account lockouts, VPN setup, printer configuration, software activation, and similar repeatable issues. Over three months, they track which guides are being read and whether users who read them still open tickets. Guides that lead to ticket creation point to content that needs improvement; guides with low follow-on ticket rates show genuine deflection.
Industry Benchmark: ServiceXRG reports the average self-service case deflection rate in the technology industry is 23%. Gartner's earlier research found that virtual customer assistants can reduce call, chat, and email inquiries by up to 70% for specific request types.
Ticket reopen rate is the percentage of closed tickets that get reopened because the issue was not actually fixed — the employee comes back and says the problem has returned or was never fully resolved.
Formula: (Reopened tickets ÷ Total closed tickets) × 100
Every reopened ticket is a double cost: you paid to resolve it once, and now you have to pay again. More importantly, reopen rate is a quality signal. It tells you whether your resolutions are durable.
A spike in reopen rate after introducing a new tool — a chatbot, an automated resolver, a new triage workflow — is a warning that the tool is closing tickets prematurely rather than genuinely fixing problems.
High reopen rates on specific categories often indicate knowledge gaps. Agents are applying temporary fixes instead of root-cause solutions, or the documented resolution procedure is incomplete.
A support team introduces an automated resolver for a common error code. Ticket volume for that error drops 40% — which looks like a success. But two weeks later, the reopen rate for that error climbs sharply. The automated fix is suppressing the symptom without addressing the underlying cause. The team updates the automated resolution to include a configuration check that prevents the error from recurring.
Good target: Most well-run service desks aim for a ticket reopen rate below 5%. Anything above 10% consistently suggests a systemic quality issue in the resolution process.
Containment rate — also called automation containment rate — is the percentage of support interactions that an AI agent or chatbot handles from start to finish, without any handoff to a human agent. The interaction is 'contained' within the automated system.
Formula: (AI-resolved interactions ÷ Total interactions handled by AI) × 100
As AI tools become standard parts of IT support infrastructure, containment rate becomes the primary measure of whether the AI is actually working. A bot that hands off 90% of conversations to human agents after failing to resolve them is not saving time — it's adding friction.
High containment means users are finding resolutions through the AI channel without needing to wait for a human. Low containment means the AI is being used as a routing layer, not a resolution layer — which is a different value proposition and should be tracked differently.
When self-service genuinely resolves an issue, it tends to lift CSAT — not hurt it. The same logic applies to AI containment: a contained interaction that succeeds builds trust in the channel; a failed containment that forces a handoff erodes it.
This metric is worth tracking alongside the reopen rate. A high containment rate with a high reopen rate means the AI is 'resolving' issues that aren't actually resolved — a common pattern with first-generation chatbot implementations.
An IT team deploys an AI assistant to handle password resets, account unlocks, and software access requests. In the first month, containment rate is 34%. After reviewing the conversation logs, they identify two patterns: the AI struggles with multi-step requests and fails when the employee describes the problem with informal language. After retraining the model on real conversation logs and breaking multi-step flows into separate guided paths, containment climbs to 61% over the next two months.
Industry Benchmark: Moveworks' analysis of over 200 organizations found that teams without AI average more than 30 hours for overall MTTR. Industry-leading teams using AI achieve under 15 hours — resolving issues in less than half the time.
These metrics are not designed to be tracked in isolation. The ones that tell you the most are the ones that confirm or contradict each other.
For example: a high FCR rate combined with a high ticket reopen rate is a red flag. It suggests agents are marking tickets as resolved quickly — perhaps to hit FCR targets — without actually fixing the problem. One metric looks good; the other exposes the issue.
Similarly, a falling MTTR is positive. But if it's falling because self-service is deflecting easy tickets and agents are only handling complex ones, your MTTR improvement might actually reflect a harder workload, not a more efficient team.
A good starting point for most teams is to establish baselines for five to seven of these metrics first, then add more as you build the data infrastructure to collect them reliably. Here is a practical grouping:
Review the operational health metrics weekly. Review quality and efficiency metrics monthly. Use capability benchmarking metrics to evaluate investments and process changes quarterly.
A help desk that only tracks ticket count and response time has a partial view of its own performance. The 15 metrics in this guide fill out that picture — showing you not just how busy your team is, but how effective it actually is at solving problems, containing costs, and keeping employees productive.
None of these metrics require a large analytics team or expensive tooling to get started. Most can be tracked in any modern ITSM platform with basic reporting. What they do require is consistent collection, honest interpretation, and the willingness to act on what they show.
The help desks that perform best in 2026 are not the ones with the most data. They are the ones that pick the right metrics, understand what those metrics are actually measuring, and use them to make decisions.
1. What is a good First Contact Resolution (FCR) rate for an IT help desk?
According to MetricNet's benchmarking data, the average FCR rate for IT service desks is between 70% and 75%. High-performing desks consistently achieve 85% or above. If your FCR rate is below 65%, that usually points to a knowledge gap or a tooling problem — agents lack either the information or the access needed to resolve issues in one interaction.
2. What is a realistic MTTR benchmark for IT support?
Mean Time to Resolve varies significantly by ticket complexity. For routine issues (password resets, software access), MTTR should be measurable in minutes with self-service in place. For mid-complexity desktop issues, 2–4 hours is a common target. Moveworks benchmarking shows AI-assisted teams average under 15 hours for overall MTTR, versus 30+ hours for teams without AI. For complex high-touch issues specifically, the gap is around 20 hours (AI) versus 40+ hours (non-AI).
3. What is the difference between FCR and FLR?
First Contact Resolution (FCR) means the ticket was resolved in a single interaction — one call, one chat, one email. First Level Resolution (FLR) means the ticket was resolved by Level 1 support without escalating to Level 2 or 3, regardless of how many interactions it took. A ticket can achieve FLR without achieving FCR: the Level 1 agent might need two sessions with the employee, but never escalates the case.
4. What CSAT score should an IT help desk aim for?
Most IT help desk teams target a CSAT score of 80% or above, meaning 80% of respondents give a positive rating (4 or 5 out of 5). Channel matters significantly: live chat support averages around 87% CSAT, while email-based support averages closer to 61%, according to Tidio's 2024 data. Low CSAT despite fast resolution usually signals a communication or empathy problem, not a technical one.
5. What is a healthy ticket reopen rate?
Most well-run service desks target a ticket reopen rate below 5%. A reopen rate above 10% consistently — especially after introducing a new automated resolver or chatbot — is a strong signal that tickets are being closed prematurely rather than genuinely resolved. Reopen rate and FCR should always be reviewed together: high FCR with high reopen rate usually means agents are marking tickets resolved too quickly.
6. What is AI containment rate and why does it matter in 2026?
Containment rate is the percentage of AI or chatbot support interactions that reach a complete resolution without being handed off to a human agent. It matters because it's the primary measure of whether your AI investment is actually doing support work, or just routing. A low containment rate means the AI is adding a step to the process rather than replacing one. Containment rate should always be tracked alongside reopen rate — a bot can 'contain' an interaction and still not solve the underlying problem.
7. How is self-service deflection rate measured accurately?
ServiceXRG defines true deflection as: a user who was entitled to assisted support, used a self-service resource, and did not subsequently open a ticket. Simply counting knowledge base page views overstates deflection significantly. The reliable signal is tracking users who visit a self-help article and do not go on to create a ticket. Aiming for 20–30% deflection is a realistic baseline for most organizations; teams with mature knowledge bases often exceed this.
8. How many help desk metrics should a team actually track?
Start with five to seven that give you coverage across the main categories: at least one operational health metric (FCR or MTTR), one quality metric (CSAT or reopen rate), one efficiency metric (cost per ticket or deflection rate), and one volume metric (ticket trends or distribution). Add more metrics only when you have the tooling to collect them reliably and the bandwidth to act on what they show. Tracking 15 metrics with poor data is less useful than tracking 6 with clean, consistent data.
Ready to Replace Your Legacy Solutions?
Start Your Journey Here
Try The Guided Tour
See It In Action: Experience our comprehensive in-browser demo showcasing all core remote support capabilities and platform integrations.
Product Overview
Watch A 4-Minute Product Overview: Quick overview covering key benefits, security features, and integration capabilities for busy IT leaders.
Talk To A Specialist
Ready To Get Started? Speak with our platform experts about your specific ServiceNow, Salesforce, or Tanium integration requirements.
Book A Demo
© 2026 ScreenMeet | Privacy Policy | Terms and Conditions | Data Privacy Framework Policy | For AI Crawlers
