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. Both Insights and Zendesk Explore read this value and make 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 stores the first reply time in calendar hours and calculates and stores the first reply time in business hours.
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.
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 the Reporting Overview
This is not available with accounts that only use Explore. For more information about built-in reports, see Using the Reporting Overview. These reports:
-
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
Reporting using Explore and Insights
Both Explore and Insights read 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 Insights metrics reference and Explore 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.
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.
81 Comments
Hey Jim! Welcome to the Community! You picked a real barnburner for your first question. :)
I'm going to poke some of the Insights experts among our Community Moderators and see if they have any ideas for this. Stand by!
Jim
The assign time is an available metric in the ticket times folder. Is that what you are after?
If I'd like to measure FRT for a specific date (say yesterday), what's the best date dimension to use in the filter?
That is, I want to know what's the FRT only for all tickets that were first replied yesterday.
Which date dimension should I use as a filter?
a) Date (ticket created) - if I use this one, I'll only get FRT for tickets that were created and first replied yesterday. However, if we gave a first reply to tickets created before yesterday, these won't be included.
b) Date (ticket solved) - if I use this one, I'll only get FRT for tickets that were solved yesterday. However, their first reply might have been given in a different date than yesterday.
c) Date (event) - if I use this one, nothing happens; that is, I get the same FRT value as if I don't use any date dimension in the filter
d) Date (assignee updated) - if I use this one, I'll only get FRT for tickets whose assignee updated the ticket yesterday, regardless of the type of update (it could be changing a ticket field only, or adding an internal comment). However, their first reply might have been given in a different date than yesterday, or not even been given yet.
Hey Joana!
I'm going to check with our Community Moderators to see if one of them can shed some light on this for you. Stand by!
Joanna
Generally, Gooddata holds a snapshot of tickets as at now. So, you can look at all tickets today and examine the first reply time of each ticket. But you cannot look at the first reply time yesterday or a past date.
First reply time is not a provided date dimension or part of the historical values set.
It sounds like the best approach for you is to pick the date dimension for ticket created. Then measure the first reply time by that date. As you move forward in time, you will see a trend for first reply time. But it does mean that, for the example, yesterday’s date create value will change until all the tickets created eventually get a first reply value.
Graeme,
Sorry for the late response. What I am looking for is the actual time of the first response by our support staff. We need to know for our SLA metrics when an agent first responded to a new ticket, not when they took or was given assignment of the ticket. And we need to filter on only business hour rules, so that after hours and weekends do not count against our SLA. Hope this makes sense.
Jim
First you need to set your business hours schedules.
You may then find it easier to use the pre-built SLA metrics available in GoodData but the first reply time in business hours is available:
Here is an example recipe that should help.
My question is: If the ticket is created by the user (the clock starts), one of the agents from one of my groups have replied to the user (the clock stops), the user comes back again (the clock starts again), my agent is not replying/replying to the user and assigning ticket to any other group, so the clock will continue to run or will it stop?
IMO FRT is essential to measuring your staffs responsiveness to the clients but it appears ZD doesn't provide much flexibility on how you can track this. Maybe I'm wrong and just confused after reading all the different scenarios and suggested solutions.
Let me tell you the scenarios we have and how I would like i captured to see if there are others with similar workflows and how they handle it.
Ticket are created either by
Scenario I
If the ticket is created by the client I want to measure from the time the ticket is assigned to an agent to the time the agent makes a public reply. I dont want the time it sits in a open queue unassigned added to the FRT of the agent.
Scenario II
I would like the FTR to begin when a level 1 or 2 rep takes the ticket. Not the time prior when the Call Taker opened the ticket and added preliminary notes.
Is this possible?
Bill,
That is exactly what I am trying to get thru to Zendesk, scenario #1. We need to know how long it took our support agents to respond to the customer. We don't care about average or median times.
I have a scenario that I need help with.
So we have an automated email that is sent into our queue whenever an item is shipped, that way we can track when it's delivered and when we can set it up.
What can I do to make FRT for these tickets not count against my report or stop the clock on them somehow?
I was thinking I could setup a trigger that auto replies to the requester with an unique reply?
I think that would skew my FRT report since it comes in and auto-replies immediately.
Anyway to have a ticket come in and not count against FRT?
@Michael,
So if I'm reading that right, you want to exclude those tickets from FRT calculations altogether? I dont think that's an option at the moment since Zendesk assumes all tickets are "real" and need FRT. Yoi can customize the FRT report to exclude tickets like that using a tag. I would create triggers that look for some specific language and tag those tickets with "frtignore" or something and customize the FRT report to exclude tickets with that tag.
Another possibility is replying to those tickets but automating that will be tricky since FRT is calculated by AGENT repsonse time not bot response time. Maybe theres an app that can respond using an agent's credentials or something? And i would delay it for 10 minutes or 1 hour or whatever would be acceptable as these will be included in FRT calculation and you don't want to skew it as you said.
I bet there are better ideas out there, but perhaps this sparked food for thought .
Hi,
I would like to exclude the tickets that were created by agents from the FRT report. I read all the comments and understood how I can add a tag to mark those tickets. I didn't get how can I excluded those tagged tickets on the FRT report.
Any help is appreciated!
Thanks,
Marcia.
Marcia
Reporting on tags can be a little tricky. Fortunately, Amy has an excellent article here that explains the process. The very last section covers listing tickets where a tag is not present.
Thank you Graeme for your prompt reply!
I will try this out, although I think I need to filter out the tickets that DO have a tag on it.
Hi, all - There's a great Support Tech Note defining our native time metrics that you might find useful.
Hi All,
I'm trying to create a metric that measures the number of tickets with business hours first reply or solve time of <2 hrs.
I'm trying to use the pre-built business hours metric as a start, but can't figure out how to include null values (many of our tickets will be solved without a public comment) as part of the function.
Does anyone have any ideas?
When a user submits a ticket they already get an automated response via a trigger saying that we're working on their ticket. Is it possible to have the trigger stop the FRT clock since we already replied with the trigger?
@Justin Smith
"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."
This sounds like exactly the solution I'm looking for! Do you have any advice or guidance on how I can execute this? I'm not teh most Zendesk or coding savvy =/
TIA!
I'm finding a similar issue to a commenter above where the follow up was that a ticket was created. Can someone help me find a workaround to the issue?
The issue is that I am trying to get average first reply time (FRT) by assignee, and I'm seeing that there are several tickets that were closed (either with a private comment or merge) so no FRT was provided to the end-user. However, these tickets are still contributing to the assignee's average FRT, which is skewing their metric.
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.
How do you view or create report for first reply by agent for business hours only. My SLA is set for first reply for business hours and all the reports are in calendar hours so the reports take a lot of time to sift through to find any true breaches to my SLAs, similarly with the SLA breach feature.
Please sign in to leave a comment.