Zendesk Messaging Report

Messaging is the channel most likely to be measured wrong in Zendesk, and the reason is structural rather than anyone’s fault. Messaging conversations produce tickets, so they show up in the Support - Tickets dataset alongside email. Reporting there feels correct. It is quietly, systematically wrong — several headline Support metrics only count email replies, so messaging work either disappears or gets misclassified.

There is a second problem underneath that. Messaging conversations are persistent. A customer opens the widget, chats for six minutes, closes the tab, comes back the next afternoon, and continues the same conversation. Email metrics assume a request has a beginning and an end. Applied to a conversation that lives for two days with three minutes of actual work in it, resolution time becomes meaningless.

This guide covers which dataset to use, which metrics exist there, and how to read numbers produced by a channel that does not behave like a ticket.

What this report should answer

How much of our volume actually arrives through messaging?
How fast do we answer the first message, and how fast do we answer subsequent ones?
How long do customers wait mid-conversation, not just at the start?
How often is a conversation offered to agents before someone accepts it?
Are messaging conversations being handed between agents?
How much messaging arrives when nobody is working?

For definitions see first response time, requester wait time, and assignment to first reply. This report sits beside the Zendesk channel performance report and the support metrics dashboard.

Choose the dataset before anything else

Explore has three places messaging data can appear, and only one of them is right for messaging reporting.

Dataset	Contains	Use for
Support - Messaging tickets	All messaging channels — web, mobile, social	Messaging reporting. This one.
Chat - Engagement	Legacy live chat engagements only	Historical legacy chat. Excludes messaging tickets.
Support - Tickets	All tickets, including messaging	Cross-channel volume — with caveats below

On the dataset selection page the messaging dataset is grouped with the live chat datasets, which is where a lot of people go wrong: the two look interchangeable and are not. Messaging tickets are not counted in the Chat Engagements dataset at all. If you migrated from legacy chat to messaging and your chat reports flatlined, that is why — the volume moved to a different dataset rather than disappearing.

The Support dataset caveat that matters most

You can count messaging tickets in Support - Tickets, and for pure volume that is fine. But several Support metrics consider only email replies:

Unreplied tickets
% One-touch tickets
Two-touch solves
Comments (all user types)
Agent updates

Read that list again if you run a messaging-heavy team, because it invalidates a common set of dashboards. A messaging conversation with fifteen agent messages can register as unreplied. A messaging-first team can appear to have a terrible one-touch rate, or a suspiciously good one, depending on which way the classification falls. Any productivity report built on comments or agent updates is undercounting messaging labour entirely.

Rule of thumb: use Support - Tickets to count messaging tickets and compare channel mix; use Support - Messaging tickets for anything about how the conversation went.

How to build the report in Explore

1. Volume and channel split

In Explore, open Reports > New report, choose Support > Support - Messaging tickets, and click Start report.
In Metrics, add Messaging tickets.
In Rows, add Ticket channel.
Add Time - Ticket created by week to Columns.

Ticket channel here separates web widget from mobile SDK from each social channel, which is the split that actually drives decisions. WhatsApp behaves nothing like the web widget: expectations are asynchronous, sessions are long, and customers tolerate delay differently. Averaging them into one “messaging” number hides both.

Pair with Zendesk ticket volume report for the cross-channel picture and channel mix for the trend that should drive staffing.

2. First reply time — and the brackets attribute

Add First reply time (min) with a MED aggregator.

Messaging first reply time is a genuinely different metric from its email cousin, because expectations are different. A four-hour email first reply is acceptable in most B2B contexts. A four-minute wait in a live web widget is not.

Explore provides a First reply time brackets attribute for exactly this, bucketing into 0-1 mins, 1-3 mins, 3-10 mins, over 10 mins, and no replies. Use it in Rows rather than reporting a single median. The distribution is far more actionable: a median of 90 seconds looks excellent and can conceal a fifth of conversations sitting over ten minutes, and it is that tail the customer remembers.

The no replies bucket deserves its own attention. In messaging it is not always a failure — customers routinely open a conversation, find their answer, and leave — but a growing share means conversations are being started and abandoned before anyone arrives.

Business-hours variants exist for messaging first reply time, so if you offer messaging only during staffed hours, use them. See Zendesk business hours reporting.

3. Requester wait time is the metric that matters most

This is where messaging reporting earns its keep, and where email-shaped thinking fails hardest.

In the messaging dataset, requester wait time measures the time between the end user sending a message and the agent responding — not just at the start, but throughout. There is also a requester wait time average variant, calculated as total wait divided by agent replies, giving you the typical mid-conversation gap.

Use both:

Requester wait time — total time the customer spent waiting across the conversation
Requester wait time average — what each individual wait felt like

The second is closer to the experienced quality of a messaging conversation. A customer in a live chat who waits 90 seconds between every reply is having a bad experience even if first reply was instant and the whole thing resolved in ten minutes. First reply time cannot see that. This is the messaging version of the point in why fast first reply time does not always mean fast support.

One documented quirk: when Ticket ID is in Rows, changing the aggregator on these wait-time metrics does not change the displayed value. Aggregate at group or channel level rather than per ticket.

4. Routing health: offers and acceptance

Messaging routing exposes something no other channel does. Explore records:

Metric	Meaning
`Offers`	Times a conversation was offered to agents (max 20 recorded)
`Offers before first acceptance`	Offers made before someone accepted
`Messaging tickets with multiple offers`	Conversations offered, declined, and re-offered

Multiple offers is a strong operational signal. A conversation offered three times before acceptance spent that whole period with a waiting customer and no owner. Rising multiple-offer counts mean agents are at capacity, unavailable, or letting offers time out — a capacity problem visible before it reaches first reply time.

Note Offers before first acceptance is null for conversations assigned directly by trigger or manually, so filter those out rather than reading nulls as zero. Pair with Zendesk omnichannel routing queue report and Zendesk agent concurrency report.

5. Handoffs and after-hours arrival

Two more metrics worth a tile each:

Reassigned messaging tickets — conversations assigned to more than one agent. In messaging, a handoff usually means the customer re-explained their problem, so this maps more directly to customer effort than it does in email. Compare with Zendesk group reassignment rate.

Messaging tickets created outside business hours — conversations arriving outside the schedule in force at creation. This is the number that tells you whether to staff messaging longer, add a bot, or set an explicit away expectation in the widget. See Zendesk after-hours ticket report.

Both have data only from July 18, 2023 onward. Any chart crossing that boundary shows a false zero before it.

Reading persistent conversations honestly

Messaging breaks resolution metrics, and it is better to accept that than to work around it.

A conversation open across two days with six minutes of agent work in it will show a full resolution time in days. Nothing is broken — the ticket genuinely was open that long — but “median resolution time: 19 hours” describes customer behaviour, not team performance. Three consequences:

Do not compare messaging and email resolution time. They measure different things. Report them separately or not at all.
Prefer wait-time metrics over duration metrics for messaging quality. Requester wait time reflects what your team controls; resolution time reflects when the customer came back.
Use session metrics where available. Session end time and Messaging tickets with session ended bound the active portion of a conversation rather than its full calendar life — but they only carry data from late September 2025, so they are not yet useful for year-over-year work.

There is also no messaging equivalent of “dropped chats”. Legacy chat had a clear drop event; a persistent conversation cannot be dropped, only left. If you migrated from chat and your abandonment reporting vanished, the closest substitutes are the no-replies bracket and missed conversations, and neither maps cleanly.

Migrating from legacy chat reporting

If you are rebuilding chat reports after moving to messaging, this mapping saves the most time:

Legacy chat metric	Messaging equivalent
Chats	Messaging tickets (tickets, not sessions)
Completed chats	Solved tickets
Transferred chats	Reassigned messaging tickets
Offline messages	Messaging tickets created outside business hours
Missed inbound chats	Missed conversations — depends on your workflow
Dropped chats	No equivalent

The first row is the one to flag to stakeholders. Chats counted sessions; messaging tickets count tickets. A returning customer continuing an old conversation is one ticket and would have been two chats, so post-migration volume looks lower even when contact is flat. Explain that before someone reports it as a win.

Explore messaging history goes back to August 2021 at the earliest, and only from when Explore was enabled on the account.

Common mistakes

Reporting messaging from Support - Tickets. Unreplied, one-touch, two-touch, comments, and agent updates count only email replies there.
Expecting the Chat Engagements dataset to include messaging. It does not, by design.
Reporting one blended “messaging” number. WhatsApp and the web widget have different expectations and need separating.
Using median first reply time alone. The brackets attribute exposes the tail that median hides.
Comparing messaging resolution time to email. Persistent conversations make the comparison meaningless.
Reading Offers before first acceptance nulls as zero. Directly assigned conversations are null.
Charting across metric start dates. July 2023 and September 2025 cut-offs produce false zeros.
Monitoring social messaging on the live dashboard. It excludes WhatsApp, Messenger, and SMS.

What to do when messaging metrics slip

Confirm you are in Support - Messaging tickets, not Support - Tickets.
Split by Ticket channel — the problem is usually one channel, not messaging overall.
Check the first reply time brackets distribution rather than the median.
Check requester wait time average — mid-conversation gaps are the most common hidden cause.
Check multiple offers for a capacity or availability signal.
Check after-hours arrival before treating it as a performance issue.
Check reassignment, since handoffs cost more in messaging than email.
Re-measure by distribution, not by median.

Where this fits in your dashboard

Zendesk channel performance report — messaging in context
Zendesk agent concurrency report — parallel conversation load
Zendesk agent occupancy report — chat and messaging utilisation
Zendesk omnichannel routing queue report — waiting before assignment
Zendesk reply time report — follow-up speed
Zendesk business hours reporting — which clock to measure on
support metrics dashboard — the hub

FAQ

Which dataset should I use for messaging? Support > Support - Messaging tickets. It covers web, mobile, and social messaging channels.

Does the Chat Engagements dataset include messaging? No. Messaging tickets are excluded from it. Use it only for legacy live chat history.

Why do my messaging tickets look unreplied in the Support dataset? Because several Support metrics — including Unreplied tickets, % One-touch, and Agent updates — consider only email replies.

How is messaging requester wait time different? It measures the gap between an end-user message and the agent’s response throughout the conversation, and it has an average variant reflecting the typical mid-conversation wait.

Why is my messaging resolution time so long? Messaging conversations are persistent. A customer returning the next day keeps the same ticket open. Use wait-time metrics for quality instead.

What replaced dropped chats? Nothing directly. Persistent conversations cannot be dropped. The no-replies bracket and missed conversations are partial substitutes.

Why does one metric show zero before 2023? Several messaging metrics only carry data from July 18, 2023 or later. Start charts after the relevant date.

See messaging, email, and voice in one support dashboard - start free