First reply time (FRT) is one of the metrics available in Zendesk's Insights reporting and analytics suite, and it can be incredibly helpful when trying to understand your customer satisfaction levels.
Put simply, FRT counts the number of minutes between the time a ticket is created, and the timestamp of the first public agent comment on that ticket. The calculation is just a bit more nuanced than that, however. There are a few other factors that can impact the number of minutes to FRT, including events that may pause or cancel the calculation. Below are lists of starting, stopping, pausing, and canceling events that can impact your FRT numbers, as well as similar events that do not impact your FRT numbers.
For more information on FRT and Insights metrics:
- The ticket is submitted by a user.
- The ticket is submitted by an agent on behalf of a user.
- The ticket is shared by another Zendesk account.
- If you have set business hours, the above events only start the clock if the ticket is submitted during those hours. Tickets submitted during off hours start marking time at the beginning of the next business period.
The FRT clock STOPS and calculates FRT when:
- The first public comment by any agent is made, whether they are assigned to the ticket or not, if the ticket was created by an end-user.
Note: The ticket description comment, which is created when a ticket is initially submitted, is a special case, and does not impact the FRT metric. See About ticket fields for more information.
- The second public agent comment is made, if the ticket was created by an agent on behalf of an end user.
- For tickets created via public sharing agreements, the first public comment by any agent from the receiving or sending account.
- For the tickets created via private sharing agreements, the first private note by any agent from the receiving account or the first public comment by any agent from the sending account.
The FRT clock PAUSES when
- Business hours (if set) for the company end. The clock re-starts at the beginning of the next business period.
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.
Note: Until a ticket is marked Closed, an agent can add a public comment to a Solved ticket and re-start the first reply time clock. - For tickets created via private sharing agreements, a ticket is marked Solved with no private note added by agent from the receiving account and no public comment added by any agent from the sending account.
Events that DO NOT IMPACT the FRT clock include:
- A ticket is assigned to an agent.
- An agent adds an internal (not public) comment to the ticket.
- The end user adds a comment to the ticket.
- The ticket status is changed to On-hold.
Comments
57 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.