Understanding first reply time (Professional and Enterprise)

Have more questions? Submit a request


  • Lauren Palmer

    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?

  • Tim Schuh

    Does Zendesk have plans to remove the need for an agent to post a public reply to a ticket they created just so they can track reply times? It's super inefficient, and frustrating to agents and management. I'm sure there is a way to condition the creation of a ticket based on the role of the person entering the ticket. 

  • Katarina Ondrejovicova

    I have to agree with Jason on this one. The tickets opened by agents on behalf of users should really be excluded from the calculation. It makes no sense sending another public reply after opening a ticket when all the information is already in the initial comment and agent actually provided the 1st reply over the phone. Not to talk about the fact that it's also time consuming. The same applies for the tickets opened like that and solved right away. User can reply to that, reopen them, and when the agent replies back, the calculated FRT is insanely high and doesn't reflect the real 1st reply time at all.

  • Sam Dresser
    We have agents who often follow-up first by phone, and therefore may not create a public reply. Is there any way for us to create a custom metric that shows first reply time but DOES include internal notes?
  • 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?







  • 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. 

  • Jason Fordham

    I'm glad to see the explanation and the discussion here, which makes it clear that we cannot rely on FRT as it is currently defined. It is a completely useless metric.

    What would be sensible, and would actually be a first response, would be a FRT which measured the interval between the first public posting by an external user, and the public response to that first external post

    Two of our processes make nonsense of the current FRT: the Welcome message, and License delivery. In both these cases, an internal user creates a case for a customer. They are not necessarily Agents: for License delivery, the license administrator just sends an email to the Support address.

    In the case of the Welcome, there is no purpose to sending a second public message after the Welcome, just to stop the FRT clock. It looks odd. So suppose the case is waiting for the customer, or a close. If there's a response from the customer three days later, saying "Thanks!" or "How do I log in to support?", then if we respond at all, the FRT is a lie. On the other hand if the case is closed when they respond three days later, then they get a new case, which is confusing.

    Please can we have a FRT metric which actually measures the first time we respond to something which came from a customer?


  • Dustin Glasscoe

    My question is regarding MERGING of tickets.  We use Zapier to create a new ticket eacj time a new order is placed in our Ecommerce software.  This ticket is always merged INTO an existing ticket by the same customer (or SOLVED when an existing customer ticket does not exist.)  Our FRT has been increasing each month and we are now at 119 hours FRT.  Is it possible that the API created tickets that get merged into existing tickets with response are throwing off our FRT?  I am frustrated by our FRT and have found "trusting" the number difficult to explain to our team.  In fact, I am not really sure if it truly represents our reality - having read the details and comments above I understand it better but I did not see any mention of how MERGING tickets affects FRT.



  • Monica Turley

    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!

  • Brian Manning

    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.

    1. Choose a "marker" string. The "marker" string can be anything but it should be something that you would never include in a normal comment.
    2. Add a condition to the "all" section of your "Notify requester of comment update" trigger. Select "Ticket: Comment text..." > "Does not contain the following string" and enter your marker string. In my example I use {FR_by_Voice} which I interpret as "First Reply by Voice". This condition will prevent a notification from going out to your requestors for any comment that includes your "marker" string.
    3. Create a macro for your agents to use that inserts a public comment including your marker string. This comment will be visible in the users Help Center activities view and in future notifications that use the {{ticket.comments_formatted}} placeholder. I recommend including some explanatory text so your users aren't confused if they see the comment later. My example macro looks like this. 
    4. Instruct your agents to apply the "First Reply by Voice" macro immediately after their outbound call on any tickets where the first reply is made via voice. 



    * 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)

  • Bill Cicchetti

    @ Megan:

     Ideally I'm looking for first reply (public or private) from the assignee of the ticket.


    Thanks Ill take a look!

  • Prajath Weerasinghe

    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

  • 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.

  • Michel

    Hi Zeke, 


    You are correct, if you are setting up a schedule including business hours and Holidays, you would have both metrics calculated. So if you are using bus hour to calculate your FRT, it would give you the amount of time spent on a ticket during your scheduled business hours.

    One thing to be aware of though, is that this will not be affecting tickets that have already been created but only tickets going to be created from the moment you created this schedule.

    I hope this makes sense to you, and you are definitely welcome to through a party anytime!

  • Justin Smith

    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!

  • Marylou Scott-Smith

    I think it's silly that an agent has to post a public reply to a ticket created by an inbound phone call to end the first reply calculation.  Isn't answering the phone call the agent's first reply?  If they have to create an internal ticket as a result of that phone call, and it takes three days for the ticket to be completed, you have a 72 hour first reply time on that ticket if the agent emails the customer back to let them know their issue is resolved.

  • Madison Davis

    Hi Robbie! You can use any of the pre-built metrics that begin with "[Biz Hrs]" in the title to only look at timed metrics within your defined schedules. You can check those out here!

  • 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. 

  • Nicole - Community Manager

    Hey Nick - 

    I need a little bit more info so that I can answer your question - where are you seeing "does not impact"? 


  • Michel

    Fair question Zeke, 


    The report on your overview dashboard is calculated in calendar hours, compared to your custom report calculated on business hours.

    You can check it out yourself by looking up the report by hitting the arrow on the report you see on the overview dashboard.





    This panel is going to keep showing your Median First Reply time in calendar hours. You would need to build up your own dashboard and display your custom reports there.


    I hope this helps and happy reporting!

  • 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. 


  • 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!

  • Nick Moore

    What does "DOES NOT IMPACT" mean:

    Does this mean the clock keep ticking?

    Does this mean the ticket does not count at all to the overall average?



  • Gorgias

    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!



  • Billy Macken
    Hey Sam, This could be possible depending on some specifics regarding your workflow, so I'm creating a ticket on your behalf so we can discuss this further. I'll see you in there shortly!
  • Megan Howell


    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!

  • Rebecca

    Hey Dustin!

    Since merged tickets are essentially just closed, as long as there as been no public comment, the First Reply Time would be NULL. This means it basically doesn't count against that metric.

    Merging a ticket transfers the comments from the closed ticket to the open ticket. The FRT of both tickets would still follow normal ticketing rules. If the closed ticket had no public comments, it would not count at all in the FRT metrics. So, it would not have a 0 time, but would simply not be recorded. However, when you merge tickets, there is an option to leave a comment in the ticket. By default, this comment is public. You can change whether the comment is public or private when merging by ticking the checkbox. If you do leave a public comment on the closed ticket, that would then trigger the FRT for the closed ticket.

    If this still does not really explain the FRT issues you're seeing and if you have Insights, I'd recommend creating a report in Insights by ticket id for first reply time and looking at the FRT of individual tickets. You can review the FRT of tickets with a higher then expected FRT and see what about the workflow performed on that ticket results in the spike in FRT. 

    If you do not have Insights, pinpointing the issue is a bit trickery but we do have the following resource: Why did first reply time increase? (for customers without Insights)

  • Monica Turley

    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.

  • Rebecca

    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.  

  • Megan Howell


    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!


Please sign in to leave a comment.

Powered by Zendesk