Zendesk Reply Time Report: Track Follow-Up Speed After First Response
Most support teams watch first reply time closely. Far fewer teams track what happens after the first response. That is where reply time comes in.
Reply time measures how quickly agents respond throughout the rest of the conversation, not just at the beginning. If your first reply is fast but later replies take six hours, customers still experience slow support. This guide shows how to build a reply time report in Zendesk, how to interpret it, and what to do when it drifts.
What reply time actually measures
Reply time captures the gap between a customer message and the next public agent response during an active conversation.
That makes it useful for questions like:
- Are later replies much slower than first replies?
- Do some groups keep momentum better than others?
- Does queue pressure show up in follow-up speed before it shows up in backlog?
For the formal definition, see the reply time glossary entry.
Why reply time matters
First reply time sets the first impression. Reply time determines whether the ticket actually moves.
Poor reply time usually shows up as:
- Longer requester wait time
- Lower CSAT
- Higher reopen rate
- More frustrated customers sending “any update?” follow-ups
If you only track first reply time, you can miss the slow middle of the ticket lifecycle.
How to build the report in Zendesk Explore
The practical approach
Zendesk does not package reply time as neatly as first reply time on every plan, so most teams build it from ticket updates or use a support analytics layer that already models conversation gaps.
A workable approach in Explore:
- Use the dataset that contains ticket update events so you can identify customer comments and agent public replies.
- Filter to public conversation activity only. Internal notes should not count.
- Measure the time between the previous customer message and the next agent reply.
- Aggregate by median to avoid a few abandoned or long-tail tickets skewing the result.
- Trend by week and break down by:
- Group
- Assignee
- Priority
- Channel
- Conversation position if available
If your team does not want to model this in Explore, a purpose-built reporting tool is usually faster than maintaining a custom event calculation.
The most useful report cuts
By queue or group
This shows whether slow follow-up is localized to one workflow. A billing queue may have acceptable first reply time but poor reply time because agents wait too long between touches.
By channel
Chat and email often behave very differently. If email reply time is much worse, review ownership rules and notification design.
By conversation stage
Many teams are fast on reply one and slow on reply three. That pattern usually means ticket ownership is unclear or agents are juggling too many concurrent tickets.
Business hours vs calendar hours
Use business hours for internal operations reviews. Use calendar hours when you want to describe the customer journey end to end.
If you mix the two, trend lines become hard to interpret. Pick one primary view and stay consistent.
What bad reply time usually means
1. Ownership is weak
Tickets bounce between people, or nobody feels responsible for the next reply. Check group reassignment rate and assignment workflows.
2. The queue is overloaded
When agents are holding too many active conversations, later replies slip first. Compare reply time with tickets per agent and agent utilization.
3. The team lacks fast response tools
Macros, saved replies, triage rules, and context-rich views all reduce reply delays.
4. The queue is hiding complexity
Complex tickets naturally need longer pauses. Segment by ticket type or tag before deciding the team is slow.
Common mistakes
Treating reply time as the same as first reply time
They solve different problems. First reply time is about acknowledgment. Reply time is about ongoing responsiveness.
Benchmarking without complexity context
A bug investigation queue should not be compared directly to a password reset queue.
Ignoring later-stage drag
Averages can hide the fact that the third or fourth reply is where conversations stall. If possible, look at reply time by conversation depth.
How to improve reply time
- Reduce concurrent load - If agents are stretched, follow-up speed collapses before anything else.
- Prioritize waiting-customer views - Build a queue that surfaces tickets waiting on an agent response right now.
- Tighten handoffs - Reassignments slow every next reply.
- Use macros for common asks - Save typing time for the repetitive middle of the conversation.
- Review old-open tickets weekly - Many slow-reply tickets are not urgent individually, but they drag the average and the customer experience.
Add reply time to your dashboard
Reply time belongs next to first reply time, requester wait time, and resolution time in your support metrics dashboard. That combination tells you:
- how quickly you start work
- how consistently you continue work
- how long the customer waits
- how long the ticket lasts overall
FAQ
What is a good reply time target? It depends on channel and complexity. For email support, many small teams aim for same-business-day follow-up on active tickets. More important than the exact number is consistency by queue.
Should reply time be tracked per agent? Yes, but carefully. Use it for coaching and workload balancing, not as a standalone performance score.
Why not just use requester wait time? Requester wait time is broader. Reply time isolates in-conversation responsiveness, which is often the part you can improve fastest.
Track follow-up speed without building custom Zendesk formulas - start free