Zendesk time in status report: find work that stalls in each queue state
Backlog size tells you how much work exists. A time in status report tells you where that work stops moving.
For small support teams, that distinction matters. A queue can look stable while tickets quietly spend too long in New waiting for triage, too long in Open waiting for an agent reply, or too long in Pending because nobody followed up with the customer. If you only watch backlog, you see the quantity of work. If you also watch how long tickets sit in each status, you see the process friction that creates late replies, missed expectations, and avoidable SLA compliance problems.
This guide covers how to build a time in status report in Zendesk, which queue states are worth monitoring, and what to do when one state starts absorbing too much time. For the broader context, start with the support metrics dashboard.
What a time in status report should answer
A useful time in status report helps you answer operational questions like:
- How long do tickets stay in New before triage?
- How much time is spent in Open before the next agent action?
- How long do tickets sit in Pending waiting on the customer?
- How long do tickets remain On-hold because another team or vendor is blocking progress?
- Which groups, priorities, or channels accumulate the most stalled time?
Those questions matter because not every delay should be treated the same way. A ticket sitting in Pending usually points to customer-side delay. A ticket sitting in New usually points to an internal workflow gap.
How to build a time in status report in Zendesk
Step 1: Start with ticket update history
If you want to measure status dwell time accurately, use the dataset that captures status changes over time rather than only the current ticket state. In Zendesk Explore, this usually means working from ticket update history or a dataset that exposes status change timestamps.
The goal is simple: measure the elapsed time between one status change and the next.
Step 2: Track the core statuses separately
For most teams, the useful statuses are:
- New for untriaged work
- Open for active agent work
- Pending for customer-side waiting
- On-hold for external dependency waiting
- Solved for completion
Do not combine them into a single average. The point of this report is to see where time accumulates, not to flatten every state into one number.
Step 3: Build a table by status
Create a report that shows:
- Rows: Ticket status
- Metric: Average or median hours spent in status
- Filters: Date range, group, priority, channel, and brand as needed
If your team has outliers like a few tickets that sit Pending for weeks, use the median view in addition to the average so a handful of unusual cases do not hide the normal pattern.
Step 4: Break down by group or priority
A single global average rarely tells the full story. Break the report down by:
- Group to see where work stalls operationally
- Priority to see whether urgent work is actually moving faster
- Channel to spot workflows that slow down chat, email, or web form requests differently
This is where time in status becomes actionable. If New time is high only for one group, the issue is routing or intake for that group, not the whole team.
Step 5: Trend the metric week over week
Add a weekly or monthly time dimension so you can see whether dwell time is improving or getting worse. A one-week spike may be an incident. A four-week trend is a workflow problem.
How to interpret the report
When New time is too high
Too much time in New means triage is slow. Common causes include under-staffed intake coverage, poor auto-assignment rules, or unclear ownership for new tickets. Pair this with ticket inflow vs outflow and auto-assignment accuracy to see whether volume or routing is the bigger issue.
When Open time is too high
Long Open time usually means tickets are sitting with agents between touches. That can point to overloaded queues, weak prioritization, or unresolved dependencies hidden inside active work. Compare it with agent utilization and tickets per agent.
When Pending time is too high
High Pending time does not always mean the team is slow. It often means customers are not replying, required information is missing, or follow-up expectations are weak. That is why this report is useful: it separates customer-side waiting from agent-side waiting so teams do not treat every delay as an internal speed problem.
When On-hold time is too high
Long On-hold time usually signals dependency friction. Engineering, billing, compliance, or a third-party vendor may be blocking resolution. If On-hold time grows while resolution time grows too, the problem may sit outside the support team.
What to do when one status becomes a bottleneck
- Set review thresholds by status. For example, New should rarely exceed a few hours during staffed time, while Pending can tolerate longer waits depending on customer behavior.
- Assign the right owner. New time is usually a queue-management issue. Pending time may need better follow-up templates. On-hold time may require cross-functional escalation paths.
- Review by segment. The global average can look fine while one priority, channel, or team is struggling.
- Use time in status alongside outcome metrics. High Pending time may not matter if CSAT and resolution stay healthy. High New time almost always matters because it delays first action.
- Bring it into the weekly ops review. A stalled-state report is most useful when it drives staffing or process changes during your weekly support ops review.
Common mistakes
- Only looking at total resolution time. That tells you tickets are slow, but not where they are slow.
- Treating all status time as agent performance. Pending and On-hold often reflect customer or dependency delays, not frontline effort.
- Using only averages. A few extreme cases can distort the story. Review median or percentile views too.
- Ignoring segmentation. One group can be the source of the delay while the overall average looks acceptable.
- Reviewing the report without action thresholds. If nobody knows what counts as too much New or Open time, the report becomes interesting but not useful.
FAQ
Should I track business hours or calendar hours for time in status? Use the one that matches the decision. Business hours are better for internal workflow performance. Calendar hours are better when you want to understand total elapsed customer wait.
Which status should I focus on first? Start with New and Open. Those usually reveal the most direct support-operations issues. Pending and On-hold become important when you want to separate internal delays from external ones.
Can I use time in status to improve SLA performance? Yes. Time in status helps you find where SLA risk accumulates before a ticket actually breaches. It is especially useful alongside backlog aging and SLA breach by priority.
What if my team reopens solved tickets often? Then review this report together with reopened tickets. Reopens can make status dwell time look healthy on the first pass while hiding repeat work later.