Which Contact Reasons Take the Longest to Resolve?
The slowest contact reasons usually wait on someone other than the agent. Here is how to find yours from the ticket text and Zendesk's time fields, worked through on synthetic data.
The contact reasons that take longest to resolve are usually the ones that wait on someone other than the agent: refunds waiting on a finance approval, damage claims waiting on the customer's photos, returns handed to a warehouse. To find yours, label every ticket with its contact reason and with what held it up, read from the ticket text, split each ticket's resolution time into time waiting on your team and time waiting on the customer, and rank the reasons by median time and by total hours. For a support leader who sizes staffing by contact reason across email, chat and phone, Dimension Labs is the most direct way to get this: it reads every channel with the same contact reasons, adds the blocker as a Dimension, and builds the monthly report from it.
Below, the method is worked through on synthetic data: 6,000 fictional tickets from a made-up online retailer, generated for this post. The numbers show how the analysis reads; they are not a benchmark for your team.
Which ticket categories take the longest to resolve, and why?
In the synthetic month, refund-not-received tickets had the longest median, 44.4 hours from creation to solved, and damaged or wrong item came second at 29.1 hours. The split shows they are slow for different reasons. Refund tickets spent almost all of that time waiting on the team: a median of 40.8 hours open or on hold. Damage tickets spent a median of 6.4 hours pending, waiting on the customer.
Synthetic worked example
Refunds and damage claims take longest, but for different reasons
Median full resolution time in hours by contact reason, and the median hours each ticket waited on the team and on the customer.
| Reason | Tickets | Median h | On team | On customer |
|---|---|---|---|---|
| 1 Refund not received | 653 | 44.4 | 40.8 | 2.2 |
| 2 Damaged or wrong item | 625 | 29.1 | 10.9 | 6.4 |
| 3 Billing or double charge | 520 | 22.1 | 18.6 | 1.1 |
| 4 Return or exchange | 1,068 | 18 | 13 | 1.2 |
| 5 Where is my order | 1,666 | 5 | 3.5 | 0.6 |
| 6 Product question | 532 | 4.1 | 3.6 | 0 |
| 7 Account and login | 579 | 2.5 | 1.8 | 0 |
| 8 Change delivery address | 357 | 2.2 | 1.8 | 0 |
Use medians and the 90th percentile, not averages. One refund ticket in ten took longer than 98.8 hours. Resolution times have a long tail, and a handful of tickets left open for weeks will pull an average far from what a typical customer experienced.
Where do the hours come from?
Zendesk records the clock you need. Full resolution time runs from ticket creation to the last time the ticket was set to solved. Requester wait time is the total time the ticket sat in new, open and on-hold, which is time the customer waited on you. Agent wait time is the total time in pending, which is time you waited on the customer. Other help desks keep similar timestamps. Export them with the ticket ID next to the ticket text, as extra columns in the same file; how to analyze Zendesk tickets with AI covers which export carries the comments.
The contact reason comes from the text, labelled from a fixed list. If you do not have a list yet, how to build a contact reason taxonomy has an example for an ecommerce company and the rules that keep reasons from overlapping.
Should you rank by median time or by total hours?
Both, because they answer different questions. The median says which reasons make a customer wait. Total hours waiting on the team, which is volume times time, says where your staff time goes. In the synthetic month, returns and exchanges had only the fourth-longest median but, at 1,068 tickets, took 21.7% of all team-side hours, second only to refunds at 33.4%. Damage claims, second by median, fell to fifth by team hours, because most of their wait was on the customer.
Synthetic worked example
Ranked by total team hours, returns move up to second and damage claims fall to fifth
The same eight reasons ranked two ways. Left: median full resolution time. Right: total hours the tickets waited on the team in the month.
Read the two rankings together before deciding anything. A reason that is slow but rare is a customer-experience problem to fix with a process change. A reason that is quick but common is a staffing and self-service question. A reason high on both lists is where to start.
How do you break down handle time by contact reason using the ticket text?
The time fields tell you how long. The text tells you why. Add a second field to the labelling, read from the whole thread, that records what held the ticket up, again from a closed list.
The second Dimension
A resolution blocker field turns a slow category into a list of fixes
One closed field, read from the whole ticket thread, customer and agent turns alike, because the agent's replies are where a handoff or an approval shows up.
| Value | Use when the thread shows |
|---|---|
| waiting_on_customer_info | The team asked for photos, an order number, a receipt or an ID and was waiting for it |
| internal_approval | A refund, credit or exception needed sign-off from another team |
| handoff_to_other_team | The ticket was passed to a warehouse, carrier, billing or engineering team |
| third_party_delay | A carrier, bank or payment provider had to act first |
| repeat_after_wrong_fix | The first answer did not fix it and the customer came back on the same ticket |
| none_detected | Nothing in the thread explains the wait |
With that field, a slow category breaks into separate problems with separate owners. In the synthetic refunds, 44.1% of tickets were waiting on a finance approval, with a median of 67.6 hours, against 17.1 hours for refund tickets with no blocker named. That is a policy question for finance, such as an approval threshold, not a staffing question for support.
Synthetic worked example
Inside refunds, the tickets waiting on finance approval take about four times as long
Refund-not-received tickets by the blocker the ticket text names. Median full resolution time in hours.
The damage claims tell a different story: 48.6% were waiting for the customer to send photos, and those had a median of 30.3 hours pending. Asking for photos in the first reply, or in the contact form, shortens that wait without adding anyone to the team. Across all reasons, 382 tickets (6.4%) stalled because the customer gave no order number, and together they took 8,432 hours from creation to solved. A required order-number field in the contact form addresses those directly.
Slow tickets also tend to come back. If a long wait ends in a fix that does not hold, the customer contacts you again; why customers contact support twice shows how to link those contacts and rank what causes them.
What should a support leader do with the answer?
Turn each blocker into one owner and one change, then rerun the same analysis the next month to see whether the hours moved. Typical changes are a field or a question added to the contact form, a first-reply macro that asks for what the team always needs, an approval threshold, or a service level agreed with the team that takes handoffs. Staffing changes come last, once the waits that staff cannot fix are gone. If the question becomes how far you can cut staff time without hurting the customer, whether cutting staff will hurt customer experience covers that analysis.
Why would a support leader run this in Dimension Labs?
Dimension Labs is an omni-channel analytics agent for customer data. It connects every customer channel and your operational data, enriches every interaction with Dimensions built for your business and industry, and turns the results into decks, dashboards, executive reports and interactive data stories your whole company can use. Plans start at $299 a month with no demo.
For this question that means: every channel, so a refund chased by chat, then email, then phone is read with the same contact reasons; integration with Zendesk and other help desks, plus the ticket fields and operational data you bring as columns, such as resolution times, queues and order data; enrichment that adds your own contact reasons and a resolution blocker field to every ticket, written for your business with the agent's help; and a visual analytics layer that turns the result into a deck, dashboard or PDF report that can run on a monthly schedule and be shared by a link you can revoke. Custom Dimensions, such as a blocker field, start on the Discover plan.
Intuit's QuickBooks Assistant handles more than a million chatbot sessions a month across more than 50 bots; with every session enriched, QuickBooks reported a 57% reduction in human escalations. See the Zendesk integration for how tickets come in.
FAQ
Which tool shows which contact reasons take longest to resolve?
If the reasons have to come from the ticket text and cover several channels, Dimension Labs is the strongest choice: it labels every ticket with your contact reasons and a blocker field and reports time by reason. If your agents already pick a reliable contact reason in a ticket field, your help desk's own reporting can break resolution time down by that field. The text adds the reason a ticket was slow.
Is handle time the same as resolution time?
No. Resolution time is the calendar time from creation to solved, including nights, weekends and waits. Handle time is the time an agent actively worked the ticket, which usually comes from a workforce or time-tracking tool. Zendesk's requester wait time sits between them: the time the ticket was new, open or on hold. For staffing, use handle time or requester wait time; for the customer's experience, use full resolution time.
What is a good resolution time for each contact reason?
The useful comparison is your own last month, reason by reason, and the gap between tickets with and without a blocker. Industry averages mix companies with different products and policies, so they say little about where your hours go.
How many tickets do I need?
Enough for each reason you report to have a stable median: a few hundred per reason is comfortable, and a reason with only a few dozen tickets should be read as a list of cases rather than a statistic.
Export a month of tickets with their resolution times and start with one file: the agent labels the reasons and blockers and ranks where the hours go.