Help desk metrics become useful when they point to a specific part of the ticket workflow. More tickets may call for a better intake process; unanswered requests may reveal a routing gap; repeat contacts may show that a proposed solution did not work.
This guide covers eleven core help desk measures and shows how to set them up and use them to investigate intake, first response, handling, handoffs, resolution, customer feedback, self-service, and cost. The aim is to identify a change you can evaluate, not to improve a number by hiding difficult cases.
All worked values and scenarios are illustrative. They are not benchmarks, company outcomes, or promises about any support tool.
Map the ticket workflow before reading the numbers
Start with the actual steps: request received, categorized, assigned, first reply sent, work in progress, waiting on a dependency, proposed solution, and verified completion. A ticketing system’s status labels may not correspond exactly to these steps.
Define the event used for each measure. Keep issue IDs separate from ticket IDs and contact/message events. Preserve timestamps and documented merge rules so duplicate tickets do not look like new problems. Treat missing events as unknown, not zero-duration work.
Before reporting, choose the service or team, included channels, reporting period, time zone, and cutoff. Establish ticket and customer identifiers, documented status mappings, and a category dictionary, and keep customer requests separate from internal tasks, spam, and merged duplicates according to stated rules. Begin with measures whose records you can verify, and show gaps explicitly instead of producing an apparently precise score from incomplete data.
Use this diagnostic map to connect the measures with records to inspect. Patterns suggest questions; they do not establish causes on their own.
| Pattern | Workflow check | Possible change to evaluate |
|---|---|---|
| Volume rises in a recurring category | Taxonomy, affected users, product changes, duplicate tickets | Clarify intake or fix a recurring product/documentation issue |
| First response slows | Unassigned work, queue coverage, priority and routing rules | Adjust ownership or coverage for the affected queue |
| Resolution slows after a handoff | Dependency owner, required information, escalation path | Improve the handoff and identify the next responsible team |
| AHT falls while repeat contacts rise | Solution completeness and after-contact records | Restore validation or simplify unnecessary administrative work |
| Self-service use rises but negative feedback persists | Task completion, failed searches, handoff accessibility | Update the specific instructions and preserve assisted help |
1. First contact resolution: check whether the first solution worked
For outcome-based FCR, rate = eligible issues resolved during the first contact and validated through the chosen repeat window ÷ all eligible first-contact issues whose window is complete × 100.
Define a contact for each channel, same-issue matching, transfers, resolution evidence, and exclusions. Keep unresolved eligible cases in the denominator. New cases with incomplete windows remain pending validation rather than being counted as successes.
ICMI’s measurement guidance combines a repeat-contact window with monitoring and customer feedback. A native one-touch ticket measure may be a useful proxy, but one agent reply does not prove a working outcome.
Workflow check: inspect cases that returned. Did the first answer miss an important detail, require an unavailable permission, or fail when the customer tested it? Necessary specialist work may legitimately require another contact. Use the FCR improvement guide for category-specific changes.
2. Average resolution time: locate the waiting stage
Mean full resolution time = sum of creation-to-final-resolution durations for included resolved issues ÷ count of those issues. State the included period and clock. Calendar time, business-hours time, and a paused SLA clock are distinct measures.
Use the intended endpoint. The Zendesk metrics catalog distinguishes first from full/latest resolution. Closing the record is not automatically evidence that the customer reached the intended outcome.
Show median and a tail measure beside the mean. Durations of 3, 4, 5, 6, and 42 hours have a mean of 12 hours and a median of 5. Inspect the 42-hour case; removing it without a declared rule would hide a real experience.
Choose the report cohort deliberately. A created-in-period cohort can still contain unresolved cases at the cutoff; a resolved-in-period cohort can include old cases while omitting new outstanding work. Label response and resolution separately rather than using one unexplained acronym such as “ART” for both. The time-to-resolution guide explains these choices in detail.
Workflow check: split the journey into assignment, investigation, customer information, approval, and specialist waits where records allow. Show open-ticket age and blockers because unresolved work is absent from completed-case averages. A shorter resolution interval that comes with more reopenings warrants review, not celebration.
3. Customer satisfaction: connect feedback with the case
For a five-point question, CSAT = valid ratings of 4 or 5 ÷ all valid responses × 100. This is the top-two approach described by Qualtrics. A mean rating or binary question needs a separate label.
Display the response count, delivered invitations, question, and survey timing. If 24 of 30 responses are satisfied, CSAT is 80%. With 150 delivered invitations, response coverage is 20%. The responding subset does not establish how all invited customers felt.
Workflow check: read comments and case histories. Look for incomplete answers, poor expectation setting, policy constraints, or a product problem. Share relevant feedback for coaching while accounting for case mix and what the agent could control. Do not pressure customers for scores or use a small respondent sample as the sole basis for a performance decision. Use the satisfaction metrics guide for survey design.
4. Ticket volume and categorization: make recurring work identifiable
Volume = distinct eligible tickets created during the period. State whether spam, tests, merged duplicates, proactive outbound cases, and reopened tickets count. Issue volume is different when multiple tickets concern the same problem.
Use a small, understandable taxonomy. Separate the service or product, issue category, priority/impact, channel, and customer segment. A category such as “billing” should not also serve as a priority. Provide examples and a route for cases that do not fit.
Keep one primary category for a mutually exclusive summary and use secondary tags where needed; totals across overlapping tags can exceed the ticket count. Zendesk’s custom-field reporting records the latest field value in standard metrics and attributes, while field changes can be tracked in the Updates history dataset. Decide whether the report describes original intake labels or later corrected ones.
Keep unknown or unclassified records visible. With 90 categorized tickets among 100 eligible tickets, classification coverage is 90%; it does not prove those 90 labels are accurate. Sample records to check classification quality, and version the taxonomy when definitions change.
Compare demand against the relevant population. If tickets rise from 160 to 200 while active accounts rise from 1,000 to 1,250, both periods have 160 tickets per 1,000 active accounts. Raw demand rose 25%, but the normalized contact burden did not. Complexity can still change the workload.
Workflow check: inspect recurring categories against releases, incidents, confusing setup steps, and failed searches. Choose product fixes or targeted documentation based on the records rather than assuming every spike requires more staff.
5. Average first response time: include the unserved queue
Mean first response time = total eligible first-response durations ÷ requests with a qualifying first response. Define the request event, qualifying reply, channel, clock, timezone, and period. A human-reply policy should not silently count an automatic receipt acknowledgment.
Zendesk documents native reply measurements, calendar/business clocks, channel behavior, and differences from SLA metrics. Check your actual field and configuration.
Report unanswered counts and age separately. If 40 of 50 incoming requests have qualifying replies, the replied-only average does not describe the ten still waiting. Show the median and tail rather than relying on one mean. For voice, an answer-wait measure and a public helpdesk reply interval are different measures; for chat, distinguish the live session from the ticket it creates.
Workflow check: look for unassigned cases, failed routing, coverage gaps, or unclear priority rules. Use acknowledgments to set accurate expectations, then evaluate the first substantive reply’s usefulness. See response-time improvement for practical queue changes.
6. Net promoter score: distinguish the relationship from the ticket
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. The Bain definition yields a score from −100 to +100.
Define the product or service being recommended. Keep periodic relationship surveys separate from post-support surveys. For mandatory internal help, consider whether recommendation is a meaningful question; an alternative question about usefulness should not be called NPS.
Workflow check: ask why the score was chosen and route themes to the team responsible. Product, price, reliability, and support can all contribute. Do not infer that a ticket workflow change caused an NPS movement or a particular retention result without stronger evidence.
7. Average handle time: separate work from elapsed time
For voice, AHT = total included talk, hold, and after-contact work time ÷ included handled calls. Amazon Connect documents these components, with task-specific pause rules. Confirm the provider’s included records and fields.
For asynchronous work, define measured active work separately from the ticket’s calendar duration. Concurrent chat elapsed time is not automatically additive labor time. Compare similar issue types and channels.
Workflow check: break handling work into diagnosis, lookup, repetitive entry, and necessary documentation. Evaluate changes that remove unnecessary work while retaining solution verification. Pair AHT with FCR, quality review, and feedback so shorter handling does not reward incomplete answers.
8. Agent utilization: check the staffing assumptions
A local direct-work view is utilization = included direct service-work minutes ÷ scheduled on-duty minutes × 100. Define which handling and documentation activities count and how breaks, training, meetings, and unavailable time affect the denominator.
The HDI utilization discussion shows why work/capacity definitions matter. Its historical ranges should not be copied as universal targets. A measured 450 minutes of included work across 600 on-duty minutes is 75%; it is a result under that definition, not a recommendation.
Workflow check: compare arrivals, scheduled skills, task distribution, and non-ticket responsibilities. Reserve time for coaching, collaboration, and knowledge upkeep. Utilization alone cannot prove that an agent is productive, overstaffed, or experiencing burnout.
9. Self-service adoption: measure use, then investigate outcomes
For a customer-level adoption view, adoption = eligible users who used the defined self-service route during the period ÷ eligible users with access during that period × 100. Define users, access, route, and use. A session-based measure answers a different question.
Assess task success separately. A view, helpfulness vote, or no subsequent ticket cannot independently prove resolution. KCS guidance recommends triangulating activity, feedback, and observation rather than mapping visits directly to solved issues.
Workflow check: examine searches without useful results, repeated attempts, confusing steps, and assisted handoffs. Validate representative tasks and update instructions when products change. Keep unknown outcomes visible and make human support reachable. Lower observed ticket volume is not a measured counterfactual deflection rate.
10. SLA attainment: follow the configured goal
For a chosen completed-cycle report, attainment = eligible completed goal cycles that met their target ÷ all eligible goal cycles completed during the period × 100. Separate response and resolution goals, and report open breached cycles and approaching deadlines alongside it.
Some tools count target instances instead. Zendesk’s SLA metrics calculate achievement = achieved targets ÷ (achieved + breached targets) × 100, with active breached targets in the breached population and pending unbreached targets shown separately. Because a ticket can have several targets, a target achievement percentage is not the percentage of tickets meeting every commitment. Define the unit before reporting either.
Document the start, pause, stop, and calendar rules. Jira Service Management’s conditions can pause an SLA while awaiting a customer; its calendars define working periods, timezone, and holidays. A configured pause does not remove calendar waiting from the customer’s experience.
Atlassian treats completed goal cycles separately when configurations change. Track definition versions and avoid comparing unlike policies as if performance alone changed.
Workflow check: inspect missed goals for assignment delays, priority mismatches, dependency waits, or insufficient coverage. Do not redefine goals or close tickets prematurely to make the score improve. Financial consequences depend on the actual agreement, not the label “SLA.”
11. Cost per ticket: agree on costs and the denominator
Jeff Rumburg’s HDI article defines cost per ticket = monthly service-desk operating expense ÷ monthly ticket volume, with labor, indirect personnel, technology, facilities, and other operating costs included. Benchmark use requires a compatible scope; do not copy its historical cost ranges as targets.
A resolved-ticket version is a separate, explicitly named measure: cost per resolved ticket = included period operating costs ÷ included resolved tickets during that period. Agree with finance on direct and allocated costs, currency, and period. Document how shared overhead is allocated, and include tooling, training, and implementation costs when evaluating a change.
In an illustrative month, $12,000 of included costs and 800 received requests give $15 per received request. If 600 eligible tickets were resolved that month, the resolved-ticket ratio is $20. Those are different denominators, not conflicting arithmetic.
Workflow check: period costs include some unresolved work, and resolved tickets can include work performed earlier, so the ratio is not the traced cost of each case or the cash saved by avoiding one more contact. Compare channels and issue types only under a defensible allocation, keep quality alongside cost, and treat knowledge, self-service, or routing changes as options to evaluate rather than guaranteed savings.
Run a focused workflow investigation
- Choose one pattern: identify the affected queue, category, and period, including counts and missing data.
- Check the measure: reconcile events and exclusions to source cases before changing the process.
- Inspect the work: review relevant histories, customer comments, and handoff records. Label any targeted sample; it is not automatically representative.
- Make one traceable change: clarify an intake question, routing rule, ownership handoff, template, or knowledge article. Record the owner and change date.
- Evaluate comparable cohorts: allow required observation windows to complete, retain quality/feedback checks, and account for case mix or coverage changes.
Before using a report to manage performance, trace a small set of real cases through it without changing their records. Include an unanswered request, a reopened ticket, a duplicate, a waiting case, a missing category, and an active SLA target where such cases exist. Give each measure a data owner and a decision owner.
Choose helpdesk software based on the events and reporting access you actually need: stable IDs, reproducible filters, documented clocks, useful segmentation, and a way to inspect source records. Verify capabilities in your configuration rather than assuming every tool records active work or validated outcomes. For screen-based cases, Screendesk’s recording links and video calls integrate with helpdesks and can supply relevant visual context; evaluate any resulting workflow change in your reporting rather than assuming a guaranteed FCR, cost, or resolution improvement.
For formal targets and accountable actions, use the customer support KPI guide. The purpose of this help desk workflow review is to connect a reliable measurement with the specific step you can investigate and improve.
