Median resolution time in Zendesk: build a less skewed resolution report

Average resolution time is useful, but it is easy to misread. A handful of tickets that stay open for weeks can make a team look much slower than the typical customer experience.

That is why median resolution time is such a practical report for support operations. Instead of asking, “What is the mathematical average across every ticket?” it asks, “How long does a typical ticket take to resolve?” For small teams trying to monitor real service speed, that is often the more useful answer.

This guide shows how to build a median resolution time report in Zendesk, when to compare it with averages, and how to use both views together. For the metric background, see resolution time and average resolution time in the glossary.

Why median resolution time matters

Median is valuable when ticket complexity varies widely.

Imagine this week:

• 40 tickets resolve in under 10 hours
• 8 tickets resolve in 1-2 days
• 2 enterprise escalations stay open for 14 days

The average may imply that your queue is much slower than most customers actually experience. The median tells you where the middle of the distribution sits. That makes it easier to answer questions like:

• Is our normal customer experience improving or getting worse?
• Did a few unusual escalations distort the average this month?
• Which teams consistently resolve the typical ticket faster?
• Are we getting operationally healthier even if a few complex tickets stay open?

Median does not replace average. It complements it. The gap between the two is often the interesting signal.

How to build the report in Zendesk Explore

Step 1: Use the tickets dataset

Start with the tickets dataset that includes solved tickets and the time-to-resolution measure your team trusts. Make sure you know whether the metric is based on business hours or calendar hours. If your SLA targets are based on business hours, keep the reporting definition consistent.

Step 2: Choose the median metric

Create a report with:

• Metric: Median resolution time
• Filters: Solved date, group, priority, channel, and brand as needed
• Visualization: KPI, line chart, or table

If your Explore instance does not expose a ready-made median for the exact metric you want, use a calculated metric or percentile-based approach that approximates the 50th percentile.

Step 3: Put average next to median

Build a companion view that shows:

• Median resolution time
• Average resolution time
• Ticket count

Looking at all three together is what makes the report operationally useful. A high average with a stable median usually means a small number of unusually slow tickets. A rising median means the typical case is getting slower.

Step 4: Break down by segment

Review the metric by:

• Priority
• Group
• Channel
• Ticket type or tag cluster

This helps you avoid the common mistake of comparing unlike work. A billing escalation queue and a simple account-support queue should not have the same baseline.

How to read median vs average

Healthy pattern: average above median, but not dramatically

This usually means your queue has a normal long tail of more complex tickets, but the typical case is still moving at a reasonable speed.

Risk pattern: median and average both rising

This is the strongest sign that the queue itself is slowing down. The problem is no longer a few exceptions. The typical ticket is taking longer too. Pair this with ticket backlog and ticket volume to see whether demand is outrunning capacity.

Distortion pattern: average spikes, median stays flat

This often means:

• One product incident created a handful of extreme cases
• A dependency blocked a subset of tickets for days
• A specific enterprise segment is generating unusually complex work

In that situation, the average is still useful, but it is describing outliers more than the everyday queue.

What median resolution time is good for

Median resolution time is especially useful for:

• Weekly support ops reviews where you want a stable view of typical performance
• Channel comparisons where a few extreme tickets would distort averages
• Benchmarking internal improvements after staffing, routing, or automation changes
• Communicating with stakeholders who need a realistic sense of the common customer experience

It is less useful when you care specifically about the slow tail. For that, review 75th or 90th percentile resolution time as well.

What to do when median resolution time rises

1. Check volume and inflow first. A rising median often starts with queue pressure. Compare it with ticket inflow vs outflow.
2. Review aging buckets. If tickets older than 48 or 72 hours are growing, the median will usually follow. Use backlog aging.
3. Break out by priority and channel. One segment may be pulling the queue down.
4. Inspect reassignment and escalation behavior. Slow resolution often comes from bounced ownership, not just high volume. Review group reassignment rate and escalation rate.
5. Watch the gap between median and average. If both rise, fix core workflow. If only the average rises, isolate the long-tail cases separately.

Common mistakes

• Using median alone. Median is powerful, but it hides the tail. Always compare it with average or percentile views.
• Comparing unlike queues. Different ticket types have different expected resolution times.
• Ignoring the calendar-vs-business-hours definition. A business-hours median cannot be compared directly with a calendar-hours average.
• Reporting without ticket count. A median from 20 tickets is less stable than a median from 2,000 tickets.
• Treating a flat median as proof everything is fine. You may still have a damaging long tail if average and aging are worsening.

FAQ

Should median replace average resolution time on my dashboard? No. Show both if you can. Median explains the typical case; average highlights the impact of unusually slow tickets.

What is a good median resolution time? It depends on your channel mix, issue complexity, and customer expectations. Use your own last 4-8 weeks as the baseline rather than generic internet benchmarks.

Is median better for small teams? Often yes. Smaller queues are more vulnerable to distortion from a few outliers, so the median gives a steadier operational signal.

What should I pair with this report? Start with Zendesk resolution time report, support team scorecard, and the main support metrics dashboard.

---

Track typical resolution speed without spreadsheet cleanup - start free