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.
This article describes how first reply time works and how you can use it in your reports.
This article contains the following sections:
Related article:
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, the system 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 essentially the same way regardless of the channel from which the ticket originated. 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 doesn't count toward your account's first reply time.
Additional details for messaging and live chat first reply time
First reply time is calculated exclusively based on agent replies. That means automated or bot-related actions in conversations aren’t considered when calculating the first reply time. Across all channels, ticket creation starts the first reply timer. Live conversation channels are no exception. However, because public replies aren’t an agent response option for live chat and messaging tickets, the actions that stop the timer are different:
-
On messaging tickets, the timer stops
when the agent clicks Send on their first
Messaging reply to the conversation.
-
On live chat tickets with reply-time SLAs
turned on, the timer stops when the agent
clicks Send on their first comment in the
conversation.
Messaging and live chat tickets also have an additional metric: First reply time (sec). This metric is often a more accurate measure of first reply times for tickets from live conversations, which tend to move more quickly than tickets from other channels. Unlike the standard First reply time metrics, the First reply time (sec) metric ignores your messaging business hours and live chat operating hours settings.
Reporting first reply time
The following sections describe 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.
See Metrics and attributes for Zendesk Support, Metrics and attributes for Zendesk messaging, and Metrics and attributes for live chat.
Reporting using External analytic tools
If you're not using any 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. See API metrics documentation.
Reporting using the legacy Reporting Overview
The legacy Reporting Overview is not available if your plan includes Zendesk Explore.
The reporting overview can:
- Display the first reply time metric directly from Zendesk Support
- Display calendar hours only; business hours are not displayed
- Display average reply time for all tickets
Zendesk SLAs and first reply time
A service level agreement, or SLA, is a policy you define that specifies and measures the response and resolution times that your support team delivers to your customers. To determine these times, your SLA policies may also use the first reply time metric.
However, there are differences in the way that the first reply time metric 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.
An exception to this rule is that if the requester is a light agent, the first reply time SLA target starts at creation even without a public comment.
- 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.
For more information, see Defining SLA policies.
66 comments
Fiona Witham
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.
0
Cheeny Aban
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!
0
Olli
Hello @... et al. I didn't read all 112 comments (sorry) but we have several tickets, sourced from chat, calls or API created tickets, where an SLA was assigned (including first/next reply/periodic update metrics), but *no* metric is in effect. i. e. there is no "Next SLA breach" indicator, even though you explained clearly that for the 'first reply time' the start point is the ticket creation.
What's wrong with our tickets?
Best regards
Oliver
0
Chandra Robrock
@... I'm not 100% sure this is the answer in your case, but would you mind double checking to see if this non-SLA tickets have a Priority selected?
If they don't have a Priority selected, this would explain why they technically match one of your SLA policies but no SLA target is being assigned. More info here.
0
Amy Dee
Hi Oliver! The first reply time metric always starts at ticket creation and always stops at the first public agent comment after that. However, SLAs are different.
If a ticket is created with a private comment, the first reply time SLA target is deferred. It doesn't start until the first public end-user comment. If the first comment is private, you can leave any number of public agent comments without doing anything to reply time SLA targets. The SLAs won't start until the first end-user comment.
If a ticket is created with a public agent comment, the first reply time SLA target does not run. It doesn't count as an achievement or breach. Meanwhile, the first reply time metric starts as normal and runs until the next public agent comment.
Periodic and pausable update targets start at the first public agent comment. (For pausable targets, it's the first public agent comment not in pending status.) If the ticket starts with a private comment, those targets aren't active yet either.
Channels like Talk and Chat start with private comments, then get their recordings/transcripts added later, often in more private comments. Those channels don't usually activate SLA targets until later, after the initial conversation is complete.
For API tickets, it depends on how they're created and what the initial workflow looks like. The most important detail is whether the first comment is public or private. If the first comment is public, what is the commenter's role?
I hope this helps!
0
Olli
Thank you @... for the clarification. For our API tickets we get tickets added by an 'Agent' API User but with the submitter ID of an Enduser. Even tho triggers recognize the 'current user' to be an Agent, the tickets have the proper SLA + metric + target assigned.
For call + chat tickets I see the functionality definitely missing consistency. Do I understand you right that the metric will be measured (in the reporting) always correctly, even though there is no 'SLA breach/achieved' event?
Example:
12:00 Creating a chat ticket
12:05 Ending the chat (transcript goes to the ticket)
12:15 Followup message from Agent to User + PENDING
13:00 Reply from User to Agent
13:30 Response from Agent to User + SOLVED
Will this report as 'First reply time = 15 Minutes' but 'SLA (First reply time) unknown' and also 'Next reply time = 30 Minutes' with 'SLA (Next reply time) = achieved (100%)'?
And will the agent see NO 'reply' target in the ticket until 13:00 (and potentially a 'periodic update' target already from 12:15 on)?
I understand that the sense of 'First reply' is questionable with chats, but if there would be a value for 'First reply time' in the reporting, IMHO it should also be in the SLA/in the ticket to be consistent.
The use case is "if the ticket needs a further response" (i. e. user asks a question in chat that can't be answered immediately), the ticket will stay open and needs to compete with a million other tickets having SLA goals. Missing the SLA goal makes the ticket disappear at the end of the list, i. e. in nowhere if the list is long.
Would the 'end user wait time' target be the solution for chat + call tickets that need further processing. As these could be 'pending' (target paused) I guess we'd need some nudge/automation to be fully covered,
Anything I miss?
Thanks
Oliver
0
Amy Dee
Hi Oliver! You described a lot of moving parts there, and a lot of them depend on the specifics of the workflow.
For reply and update targets, SLAs look at the comment author to determine the role. If the comment is created by an API call with agent credentials, but the author is set to an end-user, it should count as an end-user comment for SLA targets. That's likely why your API script worked in some workflows; it was probably setting the first comment's author.
For your Chat ticket example, the native first reply time metric will start at 12:00 and end at 12:15 with the agent's response (assuming the agent left a public comment). That's the native ticket metric, separate from SLAs, and it has no variations.
For SLAs, it would depend on how the ticket was created and whether the transcript is public. Chat tickets are often started with a private comment and end-user requester. If that's the case, and the transcript is private as well, then the first reply time SLA target would start at the end user's 13:00 reply and fulfill at the 13:30 solve. There would be no next reply time targets for that ticket. Periodic update targets would start at the agent's 12:15 reply and fulfill at the 13:30 solve.
If the ticket is created with a private comment and end-user requester, and the transcript is public with an end-user author, then the first reply time SLA target would start at the 12:05 transcript comment and fulfill with the agent's 12:15 reply. The customer's reply at 13:00 would start a next reply time target.
SLAs are based on ticket events in Support, and they operate in whole minutes. Chats often move much faster, with tighter targets. Chat also runs through a different system on the backend, with its own metrics and data sources. SLAs and Chat don't work together in their current iterations. Our developers are always working on improvements, though, so the two may align better in the future.
For specific use cases or workflows, I recommend reaching out to our support team directly. Tiny details can have a big impact, so it's better to confirm those details in the context of your account.
I hope this helps!
0
Olli
Thank you for these very deep and also very clear insights.
I consider them very helpful (much more than the documentation I found) and I'd like to encourage you to put the disctinction between 'native reply metric' and 'SLA functionality' in a prominent place ;)
Thank you very much!
Oliver
0
Joanna Walkowiak
Hi!
We want to turn on Ticket Sharing but we are facing some difficulties with FRT.
When we create a ticket and share it through ticket sharing channel, FRT is not measured as the agent on the second Zendesk account is treated as an agent, not as an end-user.
Is there any option to solve it? Can an agent be treated as end user on the Support account with which thickets are shared?
We need to measure FRT and we are struggling to do it with ticket sharing feature turned on.
Thanks!
1
Bogdan Vintilescu
Hello Zendesk!
Is the first reply time metric included in the first resolution or full resolution metric or will the first reply time remain a separate metric in its own?
0
Amy Dee
Hi Bogdan! The first reply, first resolution, and full resolution time metrics are all measured and recorded separately. You can report on any of them for any ticket, in business and/or calendar hours.
The durations do overlap, but it's already accounted for in the metrics. For example, if a ticket is first set to solved after 12 hours, then reopened and solved again 4 hours later, first resolution time will be 12 hours and full resolution time will be 16 hours. Technically, that means the first reply and resolution times are "included" in the full resolution time, but you don't need to take any extra steps to report on them.
I hope this helps! Happy reporting!
1
Bogdan Vintilescu
Hi Amy,
Thank you so much for following up on this. I would like some clarification on these metrics overlapping: I have a query with multiple entries and two of them yielded results differing from that expectation One of the results was:
First Reply Time = 141 minutes
First Resolution Time = 50 minutes
Full resolution Time =88 minutes.
I should note that the other 20 entries metrics (assignees on the query) seem to follow the formula:
First Reply Time < First Resolution Time < Full resolution Time, but this one does not. Any idea what may trigger this?
1
Amy Dee
Hi Bogdan! There are a couple things to check for a report like this.
Up front, I can't see how this report is aggregated. You're using the median, but it's not clear how many or which tickets are in each row. If there are a number of tickets with long first reply times that have not yet been solved, they'll add to the reply metric but not the resolution metrics. That could skew the results.
Assuming these are all solved tickets, the next consideration is the schedule. I see you're using business hours metrics in your report. That adds some complexity to the metric calculations.
Zendesk does not maintain a live counter for ticket durations. Instead, it calculates durations at the time of the relevant ticket event, based on the schedule at that time. Zendesk applies the schedule to the whole metric duration, regardless of when the schedule was added/updated.
That can lead to situations like the one you see here. If a ticket was on Schedule A at the time of the first reply and changed to Schedule B before solving, then the first reply metric will use Schedule A and both resolution metrics will use Schedule B. The resolution metrics will apply Schedule B to the whole duration, from creation to solve, ignoring the fact that Schedule A was in effect earlier in the ticket. If Schedule A has longer hours than Schedule B, it could lead to the business hours first reply time being notably longer than the business hours resolution times.
The same thing happens if you change the hours on an existing schedule. You don't need to have multiple schedules in your account for this to occur.
If you see a bunch of results like this around the same time and nowhere else, check for updates to your primary schedule. If you see tickets in one workflow doing this frequently while others don't, check for schedule changes within that workflow. And, just to confirm the actual timeline, set up a query in calendar hours for reference. That should help you fit values like this into context.
I hope this helps! Happy reporting!
0
Bogdan Vintilescu
Hi Amy!
This is very helpful! I am using a median of these metrics and the query is for ~2,000 tickets on average for each assignee. These are all solved tickets, but there were some with long first reply times. We did not change the schedule during this query, but there was another team involved in working on some tickets and their schedule may be different than ours. Will look further into it. Thank you!
0
Vladimir P
Hi Experts :)
I was wondering if someone would be able to help me to build a query with the following criteria:
- time a ticket spent in Open status between First and Second reply.
We've introduced a new way how our team operates, so I wanted to check what impact it did have on time tickets spend in open status between first and second reply.
Thanks for your help
0
Darenne
Hi Vladimir,
Thank you for patiently waiting. Unfortunately, what you want to happen needs to be done in a custom way which is already out of scope at our end at Zendesk. We have a default metric for time spent by ticket in open status using ticket updates dataset - the name of the metric is "Open status time". However, based on what you want to happen with “time a ticket spent in Open status between First and Second reply”, you need a custom formula to achieve this. If you already have a formula for this, we're happy to check it out.
Thanks for your kind understanding.
0
Mariana Bellino
Hi team! Maybe you can help me with this, I'm using first reply time to understand how my team is working. But now we are using Whatsapp channel and in ZD Explore the field first time reply is empty for this channel, do you have any ideas about how can I controle the time to response for Whatsapp Channel if this metric doesn't work?
I tried to create a calculated field that gets public comment from end user timestamp and public comment from agent to make the datediff between both timestamps but ZD Explore fails :(
Thanks in advance!
0
Dane
As Messaging is fairly new, FRT is currently one of its limitations. However, it is currently being worked on and is already near fruition. We don't have an exact date yet so please keep an eye for any updates on our page.
Hope this helps.
Cheers,
Dane
0
Amanda Gunn
Hello,
I have a question regarding the following:
Does this mean for Chat tickets where we have the chat transcript getting added/appended to the Support ticket as a Public comment from the End User that if the Agent goes to that support ticket and fills in remaining Agent only required form fields and marks ticket as solved without a public reply, as no further communication is needed, the SLA will be considered met or breached based on the time the Agent marks the ticket as solved?
I do see in the ticket events that the SLA policy is being applied, hard to tell what the specific event line that shows if its met or breached, if that can even be seen.
Thank you
Amanda
1
Dane
Yes you are correct, as long as a ticket is set to Solved even without public comments it will automatically be fulfilled. On your example, the chat transcript will not be counted for a reply as it's a system generated response. However, as long as the ticket was set to Solved during the First Reply time window, even without agent's public comment, it will be marked as "met".
Hope this helps.
Cheers,
Dane
Zendesk | Customer Advocate
0
shelley
Hi,
Reading through this article, I have a question about the below statement...
"An agent creates a ticket. Timing starts when the ticket is created and ends at the agent's next public comment."
An agent creates a ticket. Timing starts when the ticket is created and ends at the agent's next public comment. So is the FRT median applied to the date the agent created the ticket or the date the agent made the first public reply?
Example -
03Feb - agent created ticket and sent to customer
06Feb - agent receives reply back from customer, Agent replies back to customer on same day
In reporting, is the FRT accounted for on the 03Feb (ticket creation) or 06Feb (first agent public comment)?
I was wondering because the FRT median in the ZD Explore / Support / Efficiency default report changes retrospectively. So for example, if I ran a report for the 03Feb on the 15Feb and then ran it again on the 17Feb, the FRT changes. Why is that?
0
Amy Dee
Hi Shelley! The answer depends a bit on which date attribute you're using. The same date range can easily return different sets of tickets as you switch between created, updated, and solved dates.
The default Efficiency dashboard in Explore uses created dates. That means tickets will appear based on the date they were created, regardless of what happens later in the ticket events. This can make your results appear to change if you run the same report on different days.
For your example, imagine a ticket was created on February 3rd and finally got a first reply on February 16th. When you run the report on February 15th, that ticket doesn't yet have a first reply, so it doesn't contribute to the metric. When you run the report again on February 17th, the first reply has happened, so it counts in the metric. It has a long first reply time as well, so it's more likely to skew the results up.
When you use created dates in reports, it's common for metric values to change -- especially in the first week or two. This is because the tickets are still active and generating new data. It's not a problem with the reports themselves. (The only way to guarantee the results won't change is to limit your reports to closed tickets.)
Zendesk doesn't have a native "date of first reply" attribute, but we do have a recipe to create a custom version. If you'd rather report on first reply times based on when the replies occurred, this is the best place to start: Explore recipe: Creating a ticket first reply date attribute.
I hope this helps! Happy reporting!
1
Nelson Garcia Borrego
What happens if we put the ticket on "solved" and it does not have any public comment/reply? which will be the "first reply time" on that ticket?
0
Amy Dee
Hi Nelson! This will be different depending on which first reply time you're using.
For the native Zendesk ticket metric, which appears in the Tickets dataset in Explore, first reply time will be null in your example. The native metric always starts at ticket creation and always ends at the first public agent comment after that. If there are no public agent comments, it remains null and does not contribute to your metrics.
For SLAs, it depends on whether you activated a first reply time target for that ticket. SLA first reply time targets have some variation: if the ticket is started with a public agent comment, they don't run; if the ticket is started with a public end-user comment, they start at creation; if the ticket is started with a private comment, they start at the first public end-user comment, whenever it occurs.
If you activate an SLA first reply time target, it will be fulfilled when you solve the ticket. This happens regardless of whether you included a public agent comment. SLAs are fulfilled by a ticket solve.
I hope this helps! Happy reporting!
-1
Bogdan Vintilescu
Hi ZD team!
One of the people on my team had an outstandingly low First Resolution Time, Full Resolution, and Requester Wait time in March's round of tickets (data set for the full month of March). I just can't explain this unless that team member is so much faster than the others. I wonder if you could share your thoughts.
This was their February metrics![](/hc/user_images/iFaD9Fk-rN5g8h08UrNe-Q.png)
0
Gab Guinto
I suggest that you drill into the values down to the ticket ID level to get a clearer picture of the agent's activity within that period. You can create a query with the metric First resolution time, Full resolution time and Requester wait time; filter the data by Assignee name (that particular agent) and by the same date range; and then slice the data by Ticket ID under Rows. You can sort the results by descending/ascending order so that you can easily see how the values look when you scroll through the table.
0
Sarah Wasvick
Hello! I am trying to set SLA's for each group of support agents. Is there a way to get a first reply clock running for our Tier II and Tier III level agents, essentially? So if it escalates up, there is a fresh first response from the time it is new to that tier.
Thanks so much for your help!
0
DJ Buenavista Jr.
You can setup to which specific groups the following policy applies.
You can add the following condition, "Group" to specify certain groups which the following SLA policy will only be applied.
Thank you!
Kind regards,
0
Tsvetina Ivanova
Hi, I'm using the Explore and for the First time reply time brackets I see the bracket - No replies. I'm wondering how is calculated? Does it include the tickets that are created internally? Does it show the tickets that are left in a backlog? Thank you in advance for your help.![](/hc/user_images/jrVLp2B8I8HYvZ3kxmF_Dw.png)
0
Gab Guinto
The No replies bracket will include any ticket where there was no public reply sent out by an agent, so this should include your internal tickets without a public comment, regardless if it's in solved status or unsolved in the backlog. As long as there are no agent reply, then it will be counted under the No replies bucket.
0