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.
110 Comments
I have tried to write an advance metric to count the number of open tickets where the first reply time is blank, but using =null doesn't work as a function. Can anyone recommend an alternative or show me how to write a metric correctly including this function?
Thanks
Lauren
I'm also having a similar concern on FRT capturing on voice calls. when the voice call is answered its 'responded'. so it shouldn't have a requirement of a public reply to stop the FRT clock. Theoretically FRT on voice calls are 'second reply'. is there a workaround to capture FRT without a public reply for voice calls?
I think this should be a mandatory feature in zendesk
First Reply Time (FRT) is calculated as the time elapsed between ticket creation and the first public comment. The measurement isn't taken until the first public comment is added to a ticket. This means that tickets that never receive a public comment will have an FRT value of Null.
If all of your communications in a ticket are by voice then FRT is never measured. The only way to "stop the clock" and record a measurement for FRT is to create a public comment.
The Workaround:
There is a workaround you can use to create a public comment without sending a notification email to your end user. The workaround is not ideal. If you have access to Insights reporting I encourage you to create your own FRT reports broken out by Channel. If you don't have Insights or have a unique use case for FRT use the workaround at your own risk.
Caution:
* Your users will not receive an email notification for this comment but it will still be visible in their Help Center activities and in future notifications using the {{ticket.comments_formatted}} placeholder.
* If you somehow include your marker string in a comment inadvertently no notification will be sent. You should select a unique marker string that will never be used for any other purpose.
My Opinion:
Personally I don't think comparing FRT for "real time" channels like voice to other channels is ideal. If you have Insights I'd encourage you to break out your FRT reports by channel. If you want to compare across channels I'd suggest either "Time to First Resolution" or "Time to Final Resolution".
(Edited 2/21/2016 for clarification)
I've updated my previous post to offer more detail and some clarification. If you are interested in the FRT workaround I encourage you to have a look at the updated version above.
@Brian Manning, in Insights, it seems like you can only build a report around Median first reply time. Is this better info than Average reply time (as is shown in the Overview section) or am I missing a way to measure than Average within Insights? Admittedly, I'm new to Insights and not a pro with it.
Hey Aliza,
The default metrics are median values, but you can create a metric that takes the average value for first reply time by following the steps in one of our articles, "Reporting on Average First Reply Time".
I hope this helps!
The article states....
The FRT clock STARTS when:
Does this mean if I make the initial communication by creating a ticket and adding the customer as the Requester, that the FRT Starts counting once submitted, and doesn't Stop until the customer replies and I go back in and make another/2nd public comment?
We're seeing insanely large times (>300 hrs on one day) that in no way can be accurate. We're trying to figure out where these are coming from. Any other ideas or way's to tell?
Hey Monica,
The FRT calculator begins counting up at the moment of the initial ticket creation, and is stopped once the next public comment is added by an agent. So if you have an agent creating tickets on behalf of your customers, that FRT timer isn't stopped until a second comment is added to the ticket by that or another agent. This second comment doesn't specifically need to be after the customer replies back, but it does need to be after the initial ticket creation step.
Often times I see high first response times in accounts with a workflow where they are creating tickets on behalf of customers. They create the ticket, the customer takes a day or two to respond, and then after they do, the agent replies back ending that first reply timer. This causes a much higher FRT than expected since that timer was ended several days after the ticket was initially created.
I have two general recommendations for this sort of behavior.
1. Have the agents make a second public comment on the tickets created for customers, specifically to end that first reply time. It isn't the most graceful of methods, but it does allow you to get an accurate first reply time on those tickets.
2. Create a trigger to add a tag to tickets created by agents in this sort of workflow, and then create/use your own FRT report which doesn't include tickets with that specific tag. This method takes a bit of work to build out, but it would allow you to see a more accurate picture of the FRT timers on tickets where that FRT timer is actually relevant.
I hope that helps!
Hello Justin, Thank you greatly for your reply. It unfortunately confirms what we were afraid of. Yes, many of our tickets are created by an agent, in which sometimes it is not uncommon for a couple weeks or even a month to pass before a follow up is necessary, due to the nature of our business.
Option 2 is not favorable for us, but good to know. Option 1 is what I feel will be necessary, although unfortunate.
Thank you for detailing this out for us!
I have been looking at our first response times - using the insights filter. I want to only look at tickets emailed to us by our customers. I have found a couple tickets that were created outside our business hours (Saturday) however, the time is being counted. The first reply I see is Monday morning before noon - but the count on the ticket is over 40 hours.
Per this note I thought that wouldn't happen:
I also just found a ticket that does not have a public reply - it was closed with a private comment & it has a calculated first response time.
Doesn't this note mean that shouldn't happen?
The FRT clock stops the calculation and gives it a NULL value (effectively cancelling the clock) when:
A ticket is marked Solved with no public comment added.
@Jeff,
For the FRT in Business Hours in Insights, you will want to make sure you are using the [Biz Hrs] First Reply Time (hrs) [Mdn] metric, which uses the Business Hours, the regular FRT metric just uses calendar hours - sorry for the confusion! That Biz Hrs metric should work the way you have described. As for your other issue with the ticket solved with a private comment, I have created a ticket for you, and I will see you there shortly!
@justinsmith - For option #2 as you suggest, could you please give me some instructions for how to setup that trigger? I'm not sure I have it working right. I'm afraid that tagging any Current User is Agent AND Ticket is Created will probably tag more tickets than I want.
Thanks,
--Felipe
Hi Felipe!
Those conditions should work. You may want to add ticket channel is web form (for tickets created within your Zendesk account or through Help Center) to narrow down the types of tickets that get those tags. We're always happy to take a closer look at your particular instance and trigger in order to better help your specific case. Open up a ticket with us if you've got more questions! Thanks!
How can you report off of first note whether its private or public?
We have a scenario where we in support open a ticket with a developer. Support is the requester and DEV is the assignee
At times the developer assigned to this ticket will look at it and loop in another DEV resource by CCing them and sending a private note before updating the requester (support rep)
We want to know how long before some activity is done on the ticket.
@Bill:
I don't believe that this is something that could be reported in one metric (FRT for public replied tickets and FRT for internal replied comments), but I could see something working out for internal replied FRT set up along the lines of this events dataset timestamp metric article that creates metrics to capture the timestamp of ticket creation as well as the timestamp of the first internal comment, and then subtracts the two timestamps in a third metric.
Then you could use the regular FRT metric to look at the public comment first reply time.
Hopefully that helps get you started!
@ Megan:
Ideally I'm looking for first reply (public or private) from the assignee of the ticket.
Thanks Ill take a look!
I have a question about time range.
Which tickets do you take into account over a time range to measure first response time?
a. Tickets created over this time range
b. Tickets that had their first response over this time range
c. Tickets which were solved over this time range
Thanks!
Hi Gorgias-
The tickets show in a report on first reply time would be independent of specific dates as this metric calculates the amount of time passed between when the ticket was created and the first reply added to the ticket:
You can report on other calendar time frames using Date metrics, for example Date (ticket created) or Date (ticket solved) but the metric itself is independent of a date. Further you can even avoid using date metrics in a report on first reply by using the ticket ID or # tickets metrics.
Gorgias - I'm just a user, but I believe it is your second option:
b. Tickets that had their first response over this time range
When I first discovered FRT, I did so on accident, as I was responding to tickets we had created with just one public comment on them. When I added the second public comment, that's the week in which our FRT skyrocketed, like 300+ hours. I went back and looked at the report week date for the week the tickets were originally created, and those seemed to stay the same as I reported them prior, months before that. But when I added that second public comment, that week I was in was the one affected.
ZD Support, please correct me if my reply is in error.
Thanks Rebecca & Monica for your response.
@Rebecca, I'm pretty sure FRT is related to a date, because otherwise there would be no point in measuring it per month.
@Monica, thanks that helps a lot. And by any chance, did you change the status of those tickets when you added this second comment? Thanks!
@Gorgias, No, the status was not changed. I originally created the ticket by submitting the first public comment and set it to Pending. When I followed up with the second public comment, it was submitted again with the same status, Pending.
The second comments were follow ups to customer requests, which were still needing to be addressed, so we just touched base with the customer to let them know we were still working on the issue.
Hi Monica and Gorgias!
Frist reply time as a metric is independent of a specific calendar date; first reply time is the number of minutes, hours, or days since a ticket was created and a first reply comment was sent to the customer.
On our reporting dashboards we filter by a date range to provide a useable reference for the first reply time ticket data and to make it useful for our customers to use and interrupt. However there is no specific date range that goes into how the first reply time metric is calculated.
Does this help? :) Maybe I am misunderstanding the inquiry?
@Rebecca,
Thanks for the reply. I believe the disconnect here is that when we look at the Reporting view, a user can select First Reply Time and then use the "Reporting period", which is essentially a date filter, to return the FRT for that date range. While you state "there is no specific date range that goes into how the first reply time metric is calculated", there is a date captured somewhere, otherwise the result given when doing the above is invalid.
To further detail the question maybe:
When in the Reporting view, and the user selects FRT, and a custom date period has been selected, the reported Hours Average is determined by what?
a. Tickets created over this time range
b. Tickets that had their first response over this time range
c. Tickets which were solved over this time range
d. Other?
Hi Monica-
If you're looking at the reports on first reply time specifically, the Reporting Overview is date filter is based on the date of the first reply. If your account has Insights/Gooddata the frist reply time in the Overview and Efficiency dashboard is based on date ticket created.
Hi Rebecca,
To clarify, in the Reporting Overview, First Reply means Second Public Comment, correct? So the timer for that is determined when the second public comment is made? Matching Gorgias selection B?
b. Tickets that had their first response over this time range
Hey Monica-
In most cases the first reply is the second public comment on the ticket (or the first public comment made by an agent). There are some outlier cases that this article outlines very nicely. The Reporting Overview follows the various cases of calculating first reply time.
In the reporting overview, it is showing the average first reply time for tickets assigned to a group or agent. When filtering by a date range, the report is based on the date of the event- so yup, the first reply to the tickets occurred during the time range selected.
Makes sense. So b then. Thanks a lot Rebecca & Monica!
Please sign in to leave a comment.