Zendesk Omnichannel Routing Queue Report

When first response time slips, most teams reach for agent-level reporting. That is often the wrong place to look. A ticket that waited two hours might have had an agent for five minutes and spent the rest of the time sitting in a queue with nobody assigned to it.

Omnichannel routing makes that distinction measurable. It puts email, messaging, and voice into the same routing model, and it exposes the moment work was offered, the moment it was accepted, and the moment the agent actually replied. This guide shows how to build a queue report on top of that, so you can tell the difference between “we are slow” and “work waited before anyone could be slow.”

What this report should answer

How long does work sit in each queue before it is assigned?
How long do agents take to accept an offered assignment once it reaches them?
Which queues, groups, and channels accumulate the most waiting work?
Where do engagements end without resolution — transfers, timeouts, status changes?
Is a first reply problem caused by routing delay or by agent delay after assignment?

Use the glossary for definitions rather than restating them on the dashboard: queue wait time, time to first assignment, agent wait time, requester wait time, and reassignment rate. Keep this report beside the support metrics dashboard.

What omnichannel routing changes about reporting

Two things become available once omnichannel routing is on, and neither exists without it.

The incoming tickets real-time dashboard. This shows live queue backlog across email, messaging, and voice, for both standard and custom queues. It can be filtered by brand, queue, primary group, secondary group, channel type, channel, tags, ticket skills, messaging conversations, SLA status, and SLA policy. If you have recently enabled omnichannel routing, the dashboard can take up to 24 hours to appear.

The omnichannel engagements dataset in Explore. An engagement is a single leg of agent interaction inside a ticket’s lifecycle. This is the dataset that lets you split routing time from handling time historically rather than only in real time.

Real-time tells you what is happening right now; the engagements dataset tells you whether it keeps happening. You need both, and they answer different questions.

How to build the report in Explore

Start a new report on the omnichannel engagements dataset. The metrics that matter most for queue health:

Metric	What it isolates
Engagement - Offer time to agent	Time from the ticket being offered to the accepting agent, to acceptance. Pure routing friction.
Engagement - Assignment to first reply	Time from assignment to the agent’s first response, excluding offer state and time outside business hours. Pure agent responsiveness.
Engagement duration	Total time from engagement start to engagement end.
Engagement - Average requester wait time	Average gap between an end-user response and the agent’s reply within the engagement.
Engagement - Longest requester wait time	The worst single gap in that engagement.
Agent messages	Number of agent messages during the engagement.

Split those by the available attributes: Channel (messaging or support), Group ID, Agent ID, Ticket status - Start, Ticket status - End, Engagement start reason, and Engagement end reason.

The four views worth building

1. Offer time vs assignment-to-first-reply. Put both on the same chart, by group and by channel. This is the report’s whole reason for existing. If offer time is the larger share, you have a routing, capacity, or availability problem. If assignment-to-first-reply dominates, you have a workload or prioritisation problem inside the team.

2. Queue depth and wait by queue. From the real-time dashboard for the live picture, and from ticket-level time to first assignment for the historical trend. Custom queues are worth reporting separately from standard queues because they usually encode your highest-priority routing rules.

3. Engagement end reasons over time. The end reason tells you how work left an agent:

Inactivity timeout — the messaging conversation went quiet for 10 minutes. Note that with messaging activity routing on, engagements no longer end on inactivity.
Agent closed conversation — the agent deliberately ended the session.
Transferred — the agent handed off to another agent or group.
Ticket status updated - Pending/On Hold — the agent parked it.
Ticket status updated - Solved — the agent finished it.

A rising transfer share is a routing accuracy problem. A rising pending share on messaging usually means live conversations are being converted into asynchronous work that nobody re-plans for.

4. Engagement start reasons. These separate routed work from manual work: Routing assignment accepted, Assigned, Manual assignment, Reopened, and Transferred. A large manual assignment share means your routing rules are being worked around, which quietly invalidates every capacity assumption built on top of them.

Two data caveats that will bite you

Open engagements are only stored for 14 days. If an engagement started more than 14 days ago and has not ended, it will not appear in engagement reports at all. Long-running messaging conversations are the usual casualty. Auto-release capacity settings are the practical fix; without them, your longest engagements silently disappear from the data rather than showing up as outliers.

Not every channel switch is detectable. Switching from messaging to voice, or email to voice, is tracked. Messaging to email is not, unless the agent ended the messaging conversation and the “transform to email” setting is enabled. Voice to email is not tracked either. In those cases the work continues counting toward the last detected engagement, which inflates that channel’s duration. Do not treat per-channel engagement duration as exact when your team routinely moves conversations between channels.

How to interpret the patterns

Offer time is high but agents look busy

Work is being offered to agents who cannot take it. Check concurrency limits, agent status hygiene, and skills configuration before adding headcount. A ticket that requires a skill only two agents hold will queue no matter how many people are online.

Offer time is low, assignment-to-first-reply is high

Routing is doing its job and the delay is after assignment. This is where agent wait time and workload reporting take over. See Zendesk Agent Wait Time Report.

One custom queue has a much worse wait than the standard queue

Usually a rule problem rather than a capacity problem: the queue’s conditions are too narrow, or its eligible group is too small. Check how many agents can actually receive from that queue.

Requester wait time inside an engagement is high on messaging

The agent accepted the conversation and then let it drift. This is a concurrency symptom more often than an effort problem — see Zendesk Agent Occupancy Report for Chat and Messaging and agent concurrency.

Transfers rise while queue wait stays flat

Routing is fast but wrong. The customer is not waiting to be picked up; they are waiting to reach the right person. Compare with Zendesk Group Reassignment Rate Report and Zendesk Auto-Assignment Accuracy Audit.

Common mistakes

Reading first reply time without splitting routing from handling. The blended number cannot tell you which half to fix, and the two fixes are completely different.
Reporting engagement duration as handle time. An engagement can end because of a timeout or a status change, not because work finished. Use handle time for effort.
Ignoring the 14-day open engagement limit. Your longest conversations are missing, not merely rare.
Comparing channel durations after channel switches. Undetected switches roll time into the previous channel.
Using the real-time dashboard as a trend source. It is a live operational view. Historical questions belong in Explore.
Forgetting business hours. Assignment-to-first-reply already excludes time outside business hours; most ticket-level metrics do not, so mixing them creates contradictions. See business hours vs calendar hours.

What to do when queue wait climbs

Confirm which half is growing: offer time or assignment-to-first-reply.
If offer time is growing, check availability, concurrency limits, and skill scarcity for the affected queue.
If assignment-to-first-reply is growing, check workload per agent and whether one channel is crowding out the others.
Review engagement end reasons for a rise in transfers or timeouts.
Check whether the interval was genuinely busier than planned — see Zendesk Forecast Accuracy Report — or whether scheduled coverage did not materialise, see Zendesk Schedule Adherence Report.
Re-measure after two weeks with the same queue and channel filters.

Where this report fits in your dashboard

Keep it beside:

Together they show how fast work reaches an agent, how fast it moves once it does, and where it leaves the queue for reasons other than being solved.

FAQ

Do I need omnichannel routing to build this report? Yes for the incoming tickets real-time dashboard and for the richest engagement data. Without it you can still report time to first assignment from the Support: Tickets dataset, but you cannot separate offer time from acceptance.

What exactly is an engagement? One leg of agent interaction within a ticket. Measurement starts when an agent interacts with a ticket, or for messaging when a conversation has had an end-user reply in the last 10 minutes. A ticket can have several engagements across its life.

Why do some long messaging conversations never appear? Open engagements are retained for 14 days. Anything still open past that window is not recorded in engagement reports.

Should I report standard and custom queues together? Report them separately first. Custom queues usually carry your priority routing logic, so blending them hides whether the rules are working.

How often should I review it? Real-time during peak periods, and weekly for the offer-time versus first-reply split. Routing problems compound quickly because unassigned work keeps arriving.

Split routing delay from agent delay across every Zendesk channel - start free