When you use Zendesk to support customers, a question that people commonly ask is “How long does it typically take for one of my agents to respond to a ticket after it’s first created?”
Zendesk Support records the time from when a ticket was created to the first public agent response. Zendesk Explore reads this value and makes it available in a metric named First reply time.
Use this article to understand how first reply time works, and how you can use it in your reports.
This article contains the following sections:
How first reply time is calculated
The Zendesk first reply time metric measures the time between ticket creation and the first public agent comment after that.
After the first public reply, Support calculates the first reply time in calendar hours and business hours. Both metrics are stored with the ticket data, so you can use either (or both) to build reports.
First reply time works the same regardless of the channel from which the ticket originates. For example:
- A customer email creates a ticket. Timing starts when the ticket is created and ends at the first public agent comment.
- An agent creates a ticket. Timing starts when the ticket is created and ends at the agent's next public comment.
- An agent takes a phone call that creates a ticket and solves the ticket with no new comment. The customer later re-opens the ticket, and the agent then responds with a public comment. First reply time ends when that comment is posted.
- When an agent adds a public comment from another account using ticket sharing, this does not count toward your account's first reply time.
Reporting first reply time
Use the following sections to understand how to use the Zendesk reporting tools to read first reply time information.
Reporting using Explore
Explore reads first reply time information from Support. The reports:
-
Read data from Support using the Zendesk API. They do not calculate calendar hours or business hours.
-
Display information on pre-built reports in calendar hours. However, metrics for business hours are available and can be used in your own reports.
For help with metrics, see Metrics and attributes for Zendesk Support.
Reporting using External analytic tools
If you are not using any of the Zendesk reporting methods, you can still read first reply time information using the Zendesk API. The first reply time information in calendar hours is stored together with the first reply time in business hours and clearly labelled. For details, see the API metrics documentation.
Reporting using the Reporting Overview
The Reporting Overview is not available if you have Zendesk Explore. The overview can:
-
Display the first reply time metric directly from Zendesk Support
-
Display calendar hours only; business hours are not displayed
-
Displays average reply time for all tickets
For more information about built-in reports, see Using the Reporting Overview
Zendesk SLAs and first reply time
Zendesk Service Level Agreements, or SLAs, are an agreed upon measure of the response and resolution times that your support team delivers to your customers. To determine these times, SLAs also use the first reply time. However, there are important differences in the way that these metrics work with SLAs:
-
If a ticket is created with a public comment from an agent, the SLA first reply time target is not run
-
If a ticket is created with a private comment, the SLA first reply time target will not start until the ticket gets a first public comment from an end-user
-
SLA first reply time targets are fulfilled when a ticket is solved, even if the ticket never had a public comment from an agent.
-
SLA targets can be run in calendar or business hours, but not both.
-
Business hour SLA targets pause outside business hours, then restart when business hours begin.
112 Comments
If an agent's tickets are primarily auto-generated and do not warrant a response, does marking the ticket as solved count against first reply time? Or is it simply the time it takes between receiving the ticket and closing the ticket that contributes to the first reply time metric?
Hey Nathan,
If an agent does not reply to a ticket before solving then the first reply time for that ticket would be a null value. This should not count towards your overall first reply time metric.
Let me know if you see any wonkiness on your end and we can take a look.
Cheers!
Hey Brett,
One of our agents' first reply time is well over 200 hours but we can't figure out why. Can you take a look? I've enabled account assumption. His name is Travis.
Hey Nathan,
I'll create a ticket on your behalf so our Customer Advocacy team can look into this for you.
You'll receive an email shortly stating your ticket has been created.
Cheers!
What happens with merged tickets? Example: a customer sends us a ticket (A) via email and then creates a second ticket (B) 5 minutes later for the same item. Two hours later we merge B into A and then reply to A. Is the average reply time:
Hey Sy,
Since merged tickets are essentially just closed, as long as there as been no public comment, the First Reply Time would be NULL. This means it basically doesn't count against that First Reply Time metric.
Let me know if that's now what you're looking for!
Hi Brett. Not exactly what I'm looking for. I understand that the numerator would be 0 (no reply time). My question is whether the denominator would be 1 (it still counts as a ticket) or 0 (it's as if the ticket never existed). This is important for us to know as we look at average reply times across groups of tickets.
Hi Sy! Merged tickets are still counted separately for all calculations and metrics. Zendesk doesn't combine the backend data or remove the merging ticket from the API.
For your example, ticket B would be one ticket with a null first reply time (and a 115-minute full resolution time), and ticket A would be one ticket with a 2 hour first reply time. By default, ticket B would not count in an average first reply metric, because null is not a valid value for calculations. Ticket B may still count for the denominator, though, because it is a unique ticket.
You'll want to carefully consider your report and metric filters to account for edge cases like this. Perhaps you want to exclude all tickets with the closed_by_merge tag. That would keep ticket B out of your report, but it would still allow an un-merged ticket with no first reply time. Perhaps you want to limit your report to tickets with a valid first reply time, which would allow merged tickets as long as they had interaction before they were merged. The best option depends on your overall use case.
I hope this helps! Happy reporting!
How to create the formula to only consider tickets with reply time > 0 on the MED(First reply time (hrs)) metric ?
Hi Bruno, if this is for Explore, you could use a standard calculated metric like:
IF (MED(First reply time (hrs))>1) THEN [Ticket ID] ENDIF
I think that will accomplish what you want. Thanks!
We are using Zendesk for 2 different groups (Software Support and Equipment Support) and 2 different business hours. We are trying to track FRT(business hours) for our Equipment Support group.
If I set a trigger to set schedule to equipment support when ticket form is "Equipment". How will this affect FRT?
If a ticket comes in as New Support Call (Software business hours) and the form is changed to Equipment Support(Equipment business hours) 20 minutes later. An agent responds with a public reply 5 minutes later, will FRT be 25 minutes or 5 minutes?
Hi Jody! For business hours metrics, Zendesk checks the schedule at the time of the relevant update, then calculates the metric accordingly. It doesn't maintain a live timer.
For your example, it sounds like the ticket starts with the Software group and schedule for 20 minutes, then moves to the Equipment group and schedule for 5 minutes, then gets a first reply. In that case, Zendesk will record a calendar hours first reply time of 25 minutes. For business hours, Zendesk will adjust the whole 25-minute duration according to the Equipment schedule.
It doesn't matter what changes a ticket goes through on the way to its first reply. The first reply time metric will always run from creation to that first reply, and business hours will be calculated in full according to the schedule at the time of the reply.
(SLAs do display a countdown timer, but the timer is based on a fixed breach point. Zendesk recalculates the breach point when/if the policy changes, based on the schedule at the time of the change. It doesn't use the timer to measure business hours.)
I hope this helps! Happy reporting!
As part of this article in the section
"How First reply time is calculated" there was a claim "An agent creates a ticket. Timing starts when the ticket is created and ends at the agent's next public comment."
From my understanding in another article "How do i create a First Reply Time SLA for agent created tickets?" https://support.zendesk.com/hc/en-us/articles/226673228?page=1#comment_360005400374. In this article it states "Creating a FRT SLA for agent created tickets is not possible".
In practice we have found that any agent created ticket via email or web form channel will arrive without a first reply SLA. As in the system accepts the first public reply as the actual first reply. This is in direct conflict with the mentioned statement "....and ends at the agent's next public comment".
If there is any update on how we can track first reply for agent generated tickets please let me know. Also if anyone has a workaround that interfaces directly with the SLA timer in Zendesk I am open to other options.
Hi Richard! This article is primarily about the native first reply time metric. The metric is recorded with the ticket data in calendar and business hours, regardless of whether an account has SLAs or not. The native metric's behavior does not change in different workflows - it always runs from ticket creation to the first public agent comment after that.
The first reply time SLA target is slightly different. SLAs are a newer feature (when compared to native metrics), and their metrics are stored in a separate dataset.
The two first reply time measurements are usually similar, but agent-created tickets are a major difference between them. Native metrics run from creation to the agent's next public comment, while SLA first reply targets aren't activated.
The "Zendesk SLAs and first reply time" section in the article above goes over some other known differences between the two first reply time measurements.
For your reporting question - the best option for reporting depends on the use case. You can still use the native first reply time metric for agent-created tickets, although it may skew high if the agents wait for end-users to respond before commenting again.
For SLAs, you could use next reply time targets to capture the time from the end-user's message to the agent's reply (and every reply interval after that). If you have an internal workflow where agents interact with each other, you could also consider a periodic update target. Periodic update targets and reply time targets include "instance" counts in reports, so you can easily find the first reply interval for each one.
I hope this helps! Happy reporting!
Do answerbot resolved tickets count against first time reply?
Hey Krista - no, a ticket resolved by Answer Bot would have a null first reply time. First reply time only measures a first public response from an agent. Answer Bot's suggestions do not count as an agent comment. Hope that helps!
Hi,
What's the logic behind the difference between FRT metric we can report on and FRT metric in SLAs?
Is there a work around for adding FRT SLA to tickets created with a private comment?
Hi Mateusz! The native first reply time metric is designed to be universal and consistent for analytics. It always behaves the same way, so the results are predictable. That makes benchmarks and historic reporting more effective. However, it also means the metric isn't flexible for different workflows.
SLAs are designed to prioritize live workflows. They're certainly useful in analytics, but their main purpose is keeping tickets on track. SLAs try to take the workflow context into account, so the target makes sense for agents.
At this time, reply time SLA targets only apply for public comments. The only exceptions are for tickets created by light agent requesters, and for private tickets created on behalf of an end-user. We have more information in our article on Defining and using SLA policies.
I hope this helps! Happy reporting!
Hi Lou! The native first reply time metric always starts at ticket creation, and it always stops at the first public agent comment after that. It doesn't matter what the end-user does between those two events. If your schedule matches your description, then the native metric is accurate. There were 24 business hours (plus some minutes) between ticket creation and the first public agent reply.
If you want to start a business hours timer at the reopen, I recommend using a next reply time SLA target instead. Those run from a public end-user comment to the next public agent comment, and they can be set for business or calendar hours. You can report on each individual instance of the SLA as well, so you can focus on the first response after the reopen.
SLA targets aren't retroactive, so it won't change the data for your existing tickets. However, it should give you more reporting options going forward.
I hope this helps! Happy reporting!
We have the agent workspace activated in Support so that chats are dealt with through Support too. Does this metric include or exclude chat tickets? I'm thinking they would skew the data since chats are replied to more quickly than email tickets.
Hi Fiona,
Thank you for leaving a comment on our Community.
Metrics such as First reply time, Unreplied tickets, % One-touch, Two-touch solves, Comments (all user types), and Agent updates consider only email replies on the ticket. You can find more information by checking Messaging reporting in Zendesk Agent Workspace
I hope that helps!
Please sign in to leave a comment.