IT service desk metrics help managers understand whether users can get back to work, where incidents and requests become stuck, and whether the desk has the capacity and knowledge to meet its commitments. Useful service desk reporting combines outcomes, demand, waiting time, staffing, and cost.
This guide covers eight core measures, plus two supplementary measures for queue access and recommendation, with explicit formulas, reporting boundaries, and illustrative examples. It also includes a tradeoff review and a report template. The goal is to support decisions about IT services rather than rank analysts by ticket speed alone.
Define the service desk report before selecting targets
Separate incidents, routine service requests, major incidents, and problem investigations where their workflows differ. A widespread outage and an individual software-installation request should not share an undifferentiated resolution-time average.
Atlassian describes incident resolution around restoring the affected service’s intended functioning. That restoration milestone may occur before a root-cause investigation or permanent preventive change is complete. Report those milestones separately, and distinguish incident records from the many user tickets linked to the same outage.
For every measure, record the reporting dates, time zone, eligible records, numerator, denominator, exclusions, and source fields. State whether the period selects tickets by creation, resolution, or a snapshot date. These selections answer different questions.
| Metric | Decision it supports | Essential context |
|---|---|---|
| First contact resolution | Which issues need avoidable additional help? | Contact boundary and completed validation window |
| Average resolution time | Where does completion or restoration take longer? | Severity, clock, reopening, and open-ticket age |
| CSAT | How do responding users judge the service? | Survey response coverage and reasons |
| Ticket volume trends | What demand must the desk handle? | Type, source, affected service, and workload |
| SLA compliance | Were defined service-time commitments met? | Goal, clock, cycle selection, and open breaches |
| Agent utilization | How is staffed capacity being used? | Included work and available-hour definition |
| Cost per ticket | How do operating costs relate to ticket output? | Cost scope, volume definition, and service quality |
| Knowledge effectiveness | Can users and analysts find usable guidance? | Outcome feedback and search or reuse evidence |
1. First Contact Resolution Rate
FCR measures resolution during the first support contact. First call resolution is the phone-specific version; first contact resolution can cover the other included channels.
FCR = eligible issues resolved at their first contact and validated through the defined follow-up window ÷ all eligible issues whose first-contact follow-up window is complete × 100.
Illustrative example: 80 eligible access issues have completed their selected observation window. Fifty-six were resolved during the first contact without further same-issue assistance, so FCR is 56 ÷ 80 × 100 = 70%. The denominator includes eligible issues that remained unresolved. Cases with insufficient evidence should remain visible as an unknown group, with a documented calculation policy.
Specify the first-contact boundary for calls, sessions, and email exchanges. Document transfer and specialist-consultation rules, the repeat-contact window, and exclusions. Link same-issue tickets so a second request cannot appear to be a new first-contact success. Appropriate escalation for an issue that requires specialist access should not be treated as careless service. A continuous interaction with an internal transfer may still count as first-contact resolution under your policy; track no-transfer resolution separately if that matters.
Investigate recurring first-contact failures by cause: missing information, knowledge gaps, permission limits, dependencies, or genuinely complex work. Do not force every issue into first-contact resolution, and pair the rate with sampled solution accuracy.
ICMI’s FCR guidance emphasizes allowing time to test the solution and combining repeat contacts with quality and user feedback. Do not adopt its historical reported performance as a current target. For improvement methods, use the first contact resolution guide.
2. Average Resolution Time
Choose the milestone: service restoration, request fulfillment, first resolution, or latest resolution after reopening. Avoid using administrative closure as a substitute without explaining its meaning.
Mean resolution time = sum of included ticket resolution durations ÷ included resolved-ticket count. For example, 120 total resolution hours across 30 completed requests gives a mean of four hours. The example uses elapsed durations, not analyst labor hours.
State when the clock starts, whether it runs continuously or only within service hours, and which waiting states pause it. Business time is not automatically active handling time: analysts can be working on other cases while a business-time clock runs.
Zendesk’s metric definitions, for example, distinguish first resolution from latest resolution. Reconcile the source field with the question in your report rather than treating all resolution measures as identical.
Show the median and an explicitly defined upper percentile when useful, and split by request type, priority, affected service, and escalation path. Add open-ticket counts, age bands, the oldest high-impact cases, and their blockers: a completed-ticket average excludes work that remains unresolved, and faster completion of simple cases can coexist with a growing specialist backlog. Reducing response time does not automatically reduce restoration time when the next step depends on an external vendor or change window.
3. Customer Satisfaction Score
For an internal IT desk, CSAT measures responding users’ satisfaction with the specified service experience. Ask separately about the support interaction and the outcome if both matter.
On a five-point satisfaction scale where four and five are satisfied, CSAT = valid satisfied responses ÷ all valid responses to the question × 100. This method is documented in Qualtrics’ CSAT guide.
Illustrative example: 72 satisfied ratings among 90 valid responses produce 80% CSAT. If 300 delivered invitations generated those 90 responses, response coverage is 30%. The satisfaction percentage describes respondents, not every user served.
Use consistent invitation triggers and timing, allow an optional comment, and deduplicate repeated submissions. Compare similar services and request types, and avoid suppressing invitations from difficult cases. A difficult major incident may affect satisfaction even when the analyst follows the correct process. Read the reasons before assigning responsibility. The customer satisfaction metrics guide covers survey selection and interpretation.
4. Ticket Volume Trends
Count unique tickets created during the reporting period, using consistent spam, test, duplicate, and merge rules. Break demand down by service, category, channel, location or user group where relevant, and time of arrival.
Compare volumes over equivalent working periods. Where the supported population changes, add a defined demand rate, such as monthly tickets created ÷ average daily supported-user count for that month × 100. Use the same supported-user eligibility each day; do not use only users who opened tickets as the denominator.
Illustrative example: 500 created tickets and an average supported population of 1,000 users give 50 tickets per 100 supported users that month. This rate measures ticket demand, not the percentage of users who experienced a problem: one person can open several tickets.
Reconcile demand with completions and backlog. With no other status, merge, or transfer changes, a starting backlog of 120 plus 500 new tickets minus 450 resolved tickets leaves 170. In a real report, account for reopened, merged, removed, and transferred records.
Volume alone is not workload. An outage can generate many linked reports while one specialist investigation consumes substantial time. Inspect effort, dependencies, and arrival peaks before changing staffing. A fall in tickets can reflect successful prevention, reduced usage, or difficulty reaching the desk; verify the explanation.
Annotate the trend with incidents, releases, holidays, campaigns, and logging changes. If you forecast demand, review forecast error against actual arrivals; a forecast is a planning assumption, not a guaranteed future volume.
5. SLA Compliance Rate
An SLA defines a service commitment, such as a response or resolution goal for a particular priority. Report each goal separately. One ticket may generate multiple SLA cycles or targets, so ticket counts and target-instance counts are not interchangeable.
One clearly defined historical report is completed-cycle SLA attainment = eligible target cycles completed within their goal during the month ÷ all eligible target cycles completed during the month × 100. Specify the SLA type, priority, and completion-date selection.
Illustrative example: 90 of 100 completed resolution-target cycles met their goal, giving 90%. This says nothing about additional cycles still open. Report open breached cycles, unbreached cycles approaching their deadline, and paused cycles separately. Never classify an unfinished cycle as met merely because its deadline has not arrived.
This completed-cycle measure is a chosen report definition, not a claim that every platform’s default SLA dashboard uses that denominator. Reconcile the platform’s period and cycle rules.
Jira Service Management documents configurable start, pause, and stop conditions, plus calendars with working periods, time zones, and holidays. A paused SLA clock can coexist with continued user disruption. Keep user-visible elapsed time beside the contractual or operational clock where that distinction matters.
Record changes in goals or calendars and review breaches by cause. Atlassian also distinguishes completed cycles from ongoing ones when configurations change, so keep definition versions rather than presenting a changed goal as an improved result. Meeting a time goal does not establish that the resolution was correct.
6. Agent Utilization Rate
Utilization relates work to staffed capacity. HDI’s explanation illustrates the work-produced-to-capacity relationship; its historical benchmark ranges are not universal targets for today’s desk.
Define your own numerator and denominator consistently. For a direct-ticket-work measure, utilization = non-overlapping hours spent on included ticket work ÷ included scheduled on-duty hours × 100. Specify how leave, breaks, after-contact documentation, mentoring, training, and project work are handled.
Illustrative example: six hours of ticket work in eight included on-duty hours gives 75% direct-ticket utilization. If training is outside the numerator, the other two hours are not automatically wasted. Show important indirect work separately.
Do not sum overlapping chat sessions as though each minute were separate analyst labor. If another tool reports occupancy or utilization, reconcile its availability states and work definitions before comparing percentages.
Use utilization with arrival peaks, coverage requirements, backlog, quality, and staff feedback. Targeting 100% leaves no room within that definition for tasks outside the numerator or unexpected demand. Set capacity expectations around the desk’s actual services and commitments rather than importing a generic 70–80% rule. Utilization alone cannot diagnose burnout or prove overstaffing; use workload distribution and staff feedback to investigate pressure.
7. Cost per Ticket
HDI defines cost per ticket as monthly operating expense divided by monthly ticket volume. Its cost scope includes direct and indirect personnel, technology, facilities, and training.
Publish what “ticket volume” means in your report: received, handled, or resolved tickets. For a resolved-ticket period ratio, cost per resolved ticket = allocated desk operating expense for the month ÷ unique tickets resolved during that month.
Illustrative example: $30,000 allocated monthly expense divided by 1,000 resolved tickets gives $30 per resolved ticket. This is a period-level average. Some work on those tickets occurred earlier, and some current expense supports tickets still open; it is not a measured cost for each particular ticket.
Document allocation rules for shared staff, software, and facilities. Avoid double-counting costs passed between tiers, and label currency and period. If you need the cost of a particular request type, use a defensible effort and cost-allocation method rather than assigning the whole-desk average indiscriminately.
Keep satisfaction, verified resolution, and backlog beside the cost result. Lower unit cost can accompany deteriorating service, while an effective knowledge program can leave a smaller, more complex assisted workload. A tool purchase or ticket decline does not by itself establish savings; compare total cost and comparable outcomes. Conversely, more avoidable tickets can spread fixed costs across a larger denominator and make the ratio look better. When evaluating an investment, separate modeled capacity savings, measured staff time, and actual financial savings: fewer contacts do not automatically reduce the operating budget.
8. Knowledge Base Effectiveness
Assess whether users and analysts can find accurate guidance and complete the intended task. Page views and article counts describe activity; they do not directly count issues resolved.
The KCS self-service measurement guidance recommends combining behavioral data, direct feedback, and observation because searches, views, and sessions do not map one-to-one to successful resolutions.
- Adoption: eligible users who used the defined self-service route during the period ÷ eligible users who had access to it × 100. State whether the unit is users, accounts, or sessions. Adoption measures use, not successful help.
- Findability: inspect common search terms, zero-result searches, and failed navigation paths using a defined search-event denominator.
- Reported task success: ask whether the user completed the task. Calculate positive valid answers divided by all valid answers to that question, and show response coverage.
- Assisted reuse: track eligible cases linked to a relevant article and review whether the guidance helped resolve them.
- Content health: record confusing or inaccurate articles, assigned owners, and whether reported defects were corrected.
Illustrative example: 60 of 80 valid task-success responses report completion, giving 75% among respondents. If 100 users were invited, response coverage is 80%. These figures do not establish that 75% of all visitors avoided a ticket.
A visit without a subsequent tracked ticket might reflect successful self-service, abandonment, or contact through another route. Test important journeys, inspect comments and related contacts, and compare the same task before and after a content change. When reporting automated tools, distinguish confirmed from assumed resolution under the tool’s documented definition. See the ticket-reduction guide for prevention and self-service improvements.
Supplementary measures for access and recommendation
Average Speed to Answer
For a defined real-time queue, ASA = total included queue wait before agent answer ÷ included answered contacts. State the starting event and whether routing, introductory messages, whispers, callbacks, and transfers affect the measurement.
Amazon Connect’s average queue answer time is also called ASA and includes the documented whisper period; its calculation skips records without the required agent connection or queue data. It is a queue measure, not an asynchronous email first-reply measure.
ASA covers answered contacts only. Report contacts that abandoned, remain waiting, or took a callback route separately, and examine peak intervals as well as the whole-day average. Review routing, coverage by skill, and arrival patterns before shortening conversations. If you offer callbacks, track whether and when the callback reaches the user.
Net Promoter Score
NPS = percentage of 9–10 recommendation ratings − percentage of 0–6 ratings among all valid 0–10 responses. Passives at 7–8 remain in the denominator, and the Bain definition produces a score from −100 to +100.
Define what respondents are recommending and why that question matters. A mandatory internal service desk is different from a service users can choose. Where recommendation is not meaningful, a clearly labeled question about usefulness or experience may be more actionable; do not present it as NPS. If you use NPS, keep timing and populations consistent and ask for reasons. The score is not a causal estimate of the desk’s effect on business growth.
Review tradeoffs across access, outcomes, capacity, and cost
No single efficiency number shows whether people can reach support, get a working outcome, and receive the promised service within available resources. Review the measures as four connected views:
| View | Core question | Measures to connect |
|---|---|---|
| Access | Can people reach help when they need it? | Answer speed, unanswered and abandoned demand, response commitments |
| Outcomes | Did the desk provide a working solution? | FCR, full resolution, CSAT, repeat issues |
| Capacity and demand | What work arrives, and can the team handle it sustainably? | Volume trends, workload, utilization, backlog, staff feedback |
| Economics and reach | What does the service cost, and do alternative routes work? | Cost per ticket, self-service adoption and success |
Illustrative access tradeoff: four answered calls waited 10, 20, 30, and 100 seconds, so ASA is 40 seconds and the median is 25. Two more calls abandoned before answer. The 40-second answered average does not describe all six attempts to get help, so report the abandoned calls beside it.
Illustrative cost tradeoff: $24,000 of monthly expense and 1,200 eligible new tickets give $20 per new ticket. If expense stays at $24,000 while new demand falls to 900, the ratio becomes $26.67. That increase does not establish worse service; check whether recurring issues were prevented and whether fixed resources now support other valuable work.
These examples do not describe the same cohort. To turn a pattern into a change, start with the combination that moved, such as answer waits plus abandonment, resolution time plus aging backlog, or adoption plus unsuccessful tasks. Review case and event records to separate a measurement problem from a process or capacity problem, then choose a targeted change, such as routing by the needed skill, clarifying specialist ownership, updating a common solution, or scheduling coverage around observed arrivals. Compare later periods with compatible definitions, keeping quality and access visible.
A practical IT service desk reporting template
Use an operational view for work needing attention and a periodic review for service and capacity decisions. The same report can contain these elements:
- Scope: services, user population, channels, dates, clock definitions, and exclusions.
- Demand and backlog: created and resolved counts, reconciled open work, age bands, arrival peaks, and major-incident-linked demand.
- Outcomes: FCR with mature cohort counts, resolution distributions, CSAT with coverage, and critical quality findings.
- Access: ASA for real-time queues with abandoned, waiting, and callback counts.
- Commitments: attainment for each defined SLA goal plus currently breached and approaching-deadline work.
- Resources: utilization definition, important indirect work, allocated expense, and labeled cost denominator.
- Knowledge: failed searches, task-success feedback, article defects, and reuse findings.
- Action: observed problem, supporting cases, owner, planned change, quality safeguard, and review date.
Select targets using service commitments, a comparable baseline, and the desk’s risk and capacity constraints. The benchmarking guide explains how to check external comparisons. Keep definitions stable so a change in the dashboard can be investigated as a change in service, rather than an unnoticed change in counting.
