Understanding first reply time (Professional and Enterprise)

Have more questions? Submit a request


  • Jessie Schutz

    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!

  • Graeme Carmichael


    The assign time is an available metric in the ticket times folder. Is that what you are after?

  • Joana Crisostomo

    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.

  • Jessie Schutz

    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!

  • Graeme Carmichael


    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. 

  • Jim Tatum


    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.

  • Graeme Carmichael


    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. 

  • Dipak B

    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?

  • Bill Cicchetti

    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 1:  Clients create tickets via email or the web and it goes into a open queue for reps to pick from
    • Scenario II:  Our Call Takers take a call, place the notes in the ticket, and then place it  it in an open queue for

    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?







  • Jim Tatum


    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.

  • Michael

    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?

  • Heather R

    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 .

  • Marcia Keren


    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! 



  • Graeme Carmichael


    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.

  • Marcia Keren

    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. 

  • Aimee Spanier

    Hi, all - There's a great Support Tech Note defining our native time metrics that you might find useful.

  • Dylan Cunniffe

    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?


  • Darren Taylor

    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?

  • Bee Pugh

    @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 =/


  • Admin

    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.

  • Robbie Chasse

    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.

Powered by Zendesk