Track first reply time in Zendesk
First response time (FRT)—the time until a customer gets their first meaningful reply from an agent—is one of the core support KPIs. In Zendesk, you can report on it with Explore, but you need to be clear on definition (including business vs calendar hours) and how to interpret the numbers. This guide covers that and links to step-by-step reporting.
Why first reply time matters in Zendesk
First reply time in Zendesk is often used for SLAs and for customer expectations. Zendesk’s own Explore “recipes” and support dashboards teach users how to report on it, so the demand is real. Getting it right means: same definition everywhere, the right time basis (business vs calendar hours), and a way to act when it spikes (e.g. drill to slow tickets). See first response time in the glossary for the formal definition.
How to report first reply time in Zendesk Explore
Zendesk Explore has built-in support for first reply time (and first response time). For a step-by-step walkthrough, see How to report on first reply time in Zendesk. In short:
- Metric — Time from ticket creation to first public agent reply (excluding automated replies if your definition requires it).
- Time basis — Business hours vs calendar hours: choose one and use it consistently. Business hours are usually better for teams that don’t work 24/7.
- Aggregation — Median is often used so a few very long tickets don’t skew the number; average is also common. Pick one for your targets.
Business hours vs calendar hours
If you report in calendar hours but only work 9–5, weekends will drag your “average” up. Use business hours for first reply time (and often for resolution) so the number reflects when your team actually works. The glossary has business hours vs calendar hours explained; your Explore report (or dashboard) should use the same setting as your SLA.
Common mistakes
- Mixing business and calendar hours — One report in business hours, another in calendar, and targets get confused. Standardize.
- Including auto-replies — If your SLA or target is “first human reply,” exclude automated acknowledgments from the first-reply timestamp.
- No trend — A single number doesn’t show whether you’re improving. Report first reply time over time (e.g. by day or week) and compare to last period.
- No drill-down — When first reply time spikes, you need to see which tickets were slow (e.g. by group, tag, or assignee). A dashboard that only shows the average limits action.
What to do when first reply time spikes
- Check volume — Did ticket volume or ticket inflow spike? Capacity may be the issue.
- Check routing — Are tickets sitting in a queue too long before assignment? Look at time to first assignment and routing rules.
- Check segments — Is the spike in one group, tag, or channel? Focus there (staffing, knowledge, or process).
- Drill to tickets — Use a view that shows slow first-reply tickets so you can fix patterns (e.g. a tag that always waits).
For a full set of metrics and a weekly cadence, see support metrics dashboard and reduce first response time.
Benchmarks and targets
Industry benchmarks vary by channel (e.g. email vs chat). What matters is that you set a target (e.g. median first reply < 4 business hours), report consistently, and act when you miss it. For more on first response time and median first reply time, see the glossary.
FAQ
What’s the difference between first reply time and first response time?
In practice they’re often the same: time to first meaningful agent response. “First reply” is common in Zendesk; “first response time” is common in SLAs. Use one term internally and align with your SLA wording. See first response time.
Should I use median or average?
Median is less skewed by a few very long tickets; many teams use median for first reply time targets. Average is easier to explain. Pick one and use it everywhere.
Where do I get step-by-step Explore instructions?
See How to report on first reply time in Zendesk for a detailed walkthrough and a simpler dashboard option for small teams.