Zendesk Unassigned Tickets Report

An unassigned ticket is the only kind of support work that nobody is failing to do. It has no owner, so it appears in no agent’s queue, no personal view, and no performance conversation. It sits in a group inbox waiting for someone to notice — and the reason unassigned backlog is dangerous is precisely that it generates no signal until an SLA fires or a customer chases.

Most teams already track backlog and first reply time. Neither isolates this failure. Backlog counts all open work, including tickets being actively handled. First reply time only records once a reply exists, so a ticket sitting unassigned for two days contributes nothing to the metric until it finally gets touched, at which point it lands as one bad outlier rather than two days of visible risk.

This report separates “work in progress” from “work nobody has picked up”, and it is one of the few Zendesk reports that is genuinely predictive.

What this report should answer

How many unsolved tickets have no assignee right now?
How long has the oldest one been sitting there?
Which groups accumulate unassigned work, and which clear it?
How long do tickets typically spend unassigned before someone takes them?
Is unassigned time front-loading our SLA risk?

Definitions live in the glossary: unassigned ticket rate and time to first assignment. This report belongs beside the Zendesk backlog report and the support metrics dashboard.

The metrics Explore gives you

Explore ships more here than most people realise, and choosing the wrong one is the main reason these reports get rebuilt.

Metric	What it measures	Use it for
`Unassigned unsolved tickets`	Tickets with no assignee, not solved or closed	The live queue — today’s snapshot
`Unassigned tickets`	Backlog tickets where assignee was empty	Historical backlog analysis
`Unassigned time (min/hrs/days)`	Time a ticket spent without an assignee	Duration — how long triage takes

The distinction that matters: Unassigned unsolved tickets is a snapshot, Unassigned time is a duration. The first answers “what is sitting there now”, the second answers “how long does pickup normally take”. They behave completely differently over time — a snapshot cannot be summed across weeks, and a duration cannot tell you what is waiting right now. Teams that conflate them end up with a chart that means nothing.

Note that Unassigned unsolved tickets deliberately excludes solved and closed tickets. A ticket solved without ever being assigned — common with automations and merges — is not in this metric. That is usually correct: it was never a risk.

How to build the report in Zendesk Explore

1. The live snapshot

Start with the number you can act on today.

In Explore, open Reports > New report, choose Support > Support - Tickets, and click Start report.
In Metrics, add Unassigned unsolved tickets.
In Rows, add Ticket group.
Sort descending.

That is your triage queue by team. Add Ticket priority to Columns and you have the version worth reviewing daily: urgent tickets with no owner is the cell that should always be zero.

Snapshot metrics are always “as of the last data sync”, not as of right now. If the number disagrees with a Zendesk view, that is usually the explanation rather than a reporting error — see Zendesk Explore data refresh.

2. Age the unassigned queue

A count alone hides the problem. Twelve unassigned tickets created in the last hour is a healthy queue; twelve created last week is a broken process.

Add Unsolved tickets age (days) or the Unsolved tickets age brackets attribute to Rows alongside your unassigned metric. The brackets attribute buckets into 1 day, 1-7 days, 7-30 days, and over 30 days, which is enough resolution for a triage review.

Read it as a shape, not a total. A healthy unassigned queue is almost entirely in the newest bucket and empties continuously. Anything over seven days old with no owner is not waiting for capacity — it has been skipped, repeatedly, by everyone who looked at the queue. Those tickets do not resolve themselves and they rarely surface without a report like this.

3. Measure how long pickup takes

Now switch from snapshot to duration. Build a second report using Unassigned time (hrs), set the aggregator to MED, and put Ticket group in Rows.

Use the median. Assignment times are heavily skewed — most tickets get picked up in minutes and a handful sit for days — so an average tells you about the handful and hides the norm. Our reasoning is in why median beats average for support metrics.

Add Time - Ticket created by week to Columns to trend it. Rising median unassigned time is one of the earliest capacity signals available in Zendesk: it moves before first reply time, well before resolution time, and long before backlog.

One caveat on this metric. Unassigned time is derived from assignee field-change events, so it measures the gap before an assignee was set. Tickets that were never assigned at all do not contribute a duration — they only appear in the snapshot. Always read the two reports together, or you will conclude that pickup is fast while a pile of never-assigned tickets sits outside the chart.

4. Connect it to SLA risk

This is where the report earns its place. Add your unassigned metric to a report split by SLA policy or filtered to tickets with an active target, and compare unassigned time against your first reply target.

If median unassigned time is four hours and your first reply target is four hours, your entire SLA budget is being consumed before an agent has read the ticket. Nothing an agent does afterwards can recover it. That framing changes the conversation from “agents need to reply faster” to “triage needs to be owned”, which is usually the actual fix. See SLA risk before breach and Zendesk SLA risk by group report.

5. Segment to find the cause

Add one attribute at a time. Each points at a different problem:

Ticket group — which teams have no triage owner (Zendesk backlog by group)
Ticket channel — intake paths that bypass routing (Zendesk backlog by channel)
Ticket form — forms whose routing rules never matched (Zendesk backlog by ticket form)
Ticket priority — whether urgent work is being left unowned
Created hour and day of week — whether this is purely a coverage gap
Ticket brand — brands nobody owns (Zendesk backlog by brand)

The hour-and-day view is the one most likely to end the investigation quickly. If unassigned tickets cluster at 6pm Friday and clear by 10am Monday, you do not have a triage problem, you have out-of-hours arrival with no coverage — a different fix entirely. Pair with the Zendesk after-hours ticket report.

What the patterns mean

Unassigned count is stable but ageing

Tickets are arriving and being picked up at the same rate, but the same specific tickets are being skipped. Almost always work nobody feels qualified to take: an unclear request, a suspected bug, an account with history. These need to be assigned by a human decision, not waited on. Cap the age — anything over 48 hours unassigned gets an owner regardless of fit.

Unassigned count spikes and clears daily

Normal, if the peak matches your intake peak and the trough hits zero. Compare against the Zendesk peak hours report. Worth fixing only if the peak crosses your first reply target.

One group holds nearly all of it

Either that group has no triage rotation, or its routing rules are broken. Check whether tickets are arriving in the group at all or landing there via reassignment — Zendesk group reassignment rate will tell you which.

Median unassigned time rising while volume is flat

The clearest early capacity warning in the report. The team is at the point where nobody has slack to pick up new work. This precedes backlog growth by weeks. See why support work feels heavier even when ticket volume is flat.

Unassigned time is near zero but first reply time is slow

Assignment is not the bottleneck. Tickets are being claimed quickly and then sitting in a personal queue, which is a workload distribution problem rather than a triage one. Move to Zendesk backlog by assignee and when first assignment is fast but replies are still slow.

High unassigned count in a healthy-looking queue

Check whether your team actually uses assignment. Some teams work group views collaboratively and only assign on reply — in which case unassigned count is meaningless and unassigned time is measuring reply behaviour, not triage. Validate the workflow before you act on the number.

Common mistakes

Confusing the snapshot with the duration. Unassigned unsolved tickets cannot be trended cumulatively; Unassigned time cannot tell you what is waiting now.
Reporting a count with no age. Twelve new unassigned tickets and twelve week-old ones are different situations with the same number.
Averaging unassigned time. A few extreme tickets will dominate. Use median.
Forgetting never-assigned tickets. They have no duration and appear only in the snapshot.
Ignoring the workflow. If your team works unassigned group views by design, this report measures something else entirely.
Treating it as an agent metric. Nobody owns an unassigned ticket, so nobody can be held to it. This is a process and routing metric.
Comparing against a stale sync. Snapshot metrics reflect the last data refresh, not live state.
Only watching the total. Urgent-and-unassigned is the cell that matters, and it is invisible in the total.

What to do when unassigned work starts building

Confirm the number against a Zendesk view, accounting for sync lag.
Split by age brackets — is this new arrivals or skipped tickets?
Split by group and priority to find where it concentrates.
Check arrival timing before assuming a triage failure.
Compare median unassigned time against your first reply target and decide whether SLA budget is already gone.
Clear anything over 48 hours unassigned by explicit decision, not by rota.
Fix the routing rule or name a triage owner for the affected group.
Re-measure after a full week, comparing age distribution rather than totals.

Steps 6 and 7 are the whole point. Unassigned backlog is one of the few support problems where the intervention is cheap and the reporting is the hard part — nobody needs convincing that a two-week-old ownerless ticket is bad, they just need to be shown it exists.

Where this fits in your dashboard

Zendesk backlog report — the wider queue
Zendesk backlog aging report — ageing across all open work
Zendesk assignment time report — pickup speed as a metric
Zendesk auto-assignment accuracy audit — routing that should have prevented this
Zendesk routing and assignment metrics — the wider routing picture
Zendesk Explore calculated metrics — for custom unassigned thresholds
support metrics dashboard — the hub

FAQ

Which dataset has unassigned metrics? Support > Support - Tickets. Unassigned unsolved tickets and the Unassigned time variants are all there; the Backlog dataset carries Unassigned tickets for historical analysis.

Why does my unassigned count differ from a Zendesk view? Explore reports from the last data sync while views are live. Check refresh timing before assuming a data problem.

Does a ticket solved without an assignee appear? Not in Unassigned unsolved tickets, which excludes solved and closed. Automation-solved and merged tickets commonly fall into this gap, and usually should.

Should I use average or median unassigned time? Median. The distribution is heavily skewed by a small number of long-sitting tickets.

Can I report unassigned time by agent? No, meaningfully. Until assignment happens there is no assignee, so this is a group, channel, and form metric.

What is a good unassigned time target? Set it relative to your first reply target — a common rule is no more than a quarter of it, so triage never consumes the majority of the SLA budget.

How is this different from time to first assignment? They measure the same gap from different angles. Time to first assignment is the duration metric; this report adds the live snapshot of tickets that have not reached assignment at all.

See unassigned and ageing tickets without building a report - start free