Calculating first reply time (Professional and Enterprise) Follow



  • Avatar
    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?

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

  • Avatar
    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?
  • Avatar
    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?


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

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

  • Avatar

    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!

  • Avatar
    Katarina Ondrejovicova (Edited )

    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.

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

  • Avatar
    Nicole Relyea

    Hey Nick - 

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


  • Avatar

    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!

  • Avatar
    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?



  • Avatar

    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!



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

  • Avatar

    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)

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

  • Avatar
    Rebecca (Edited )

    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.  

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

  • Avatar
    Aliza Scott

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

  • Avatar

    Hi, I am new user on Zendesk. I am looking at our company's Email FCR calculation. Now the formula we use is "#First Reply Time" divide "#Solved Ticket". However, I find most of our agent use more than 2 activate emails to solve our customers' problem, which is not meet our "2 activate emails deal with customers' problem" requirement. This causes "Email FCR Percentage" at virtual height. But I cannot find a better way to calculate the FCR because I didn't find appropriate email related data to calculate it. What should I do?

  • Avatar
    Blaine Knab

    Hi Katarina,

    If you'd like to exclude agent created tickets you can do this using tags.  You can add a specific tag, either manually or via a trigger, to tickets agents create on behalf of end users.  Then, you can filter out these tickets from your FRT report. This article describes how to do that.

    If you have further questions please reach out and open a ticket with us!

  • Avatar
    William Macken

    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!

  • Avatar
    Kayla Schmidt

    Hi Tim, at this time, agent-created tickets are not excluded from the calculation and the first reply time is only calculated once there is another public agent reply after the ticket is created by an agent. I apologize for any inconvenience. I found a product feedback request similar to yours I suggest adding your voice to and following for updates:

    There are some suggested workarounds in the post's comments from fellow community members including tags and triggers to exclude these agent created tickets from reporting that I hope can help with your workflow.

  • Avatar
    Zeke U (Edited )

    "Calendar hours." Got it. The front page measures calendar hours and you have to specify business hours under Insights. 

    Meaning calendar and business hours are both legitimate numbers, it's just really about what you want to measure and knowing what that is.

    But measuring calendar hours generated by sending a convenient stop-gap email (to keep it artificially low) is wholly skewed if what you really want is business hours. 


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



  • Avatar

    Makes sense. So b then. Thanks a lot Rebecca & Monica! 

  • Avatar

    Hey Katarina,

    Thanks for reaching out with your questions. I will be more than happy to answer them in the order they were received:

    1. In this scenario, first reply time works off of how long it took your agent to respond to the end user and will mark the time between when the ticket was submitted and the time they respond. If your agents are creating a ticket for an end user, our system reads that as the end user acting. So if your agent creates the ticket on behalf of the end user, then the end user responds with more information and your agent responds to the end user again, the time between when your agent created the ticket and then left a comment is your agent's first response time


    2. Yes, you correct. If this are Voice (or CTI integration), the easiest option is to filter on the ticket channel(or possibly the update channel of the creation event) - this would get FRT for everything that isn't one of those tickets. Another most dynamic option is to set up triggers and/or macros that tag tickets where customer follow up is not expected. This would work for future tickets, but it isn't retroactive I'm afraid. 

    Hope that helps! 

  • Avatar
    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)

  • Avatar
    Bill Cicchetti

    @ Megan:

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


    Thanks Ill take a look!

Please sign in to leave a comment.

Powered by Zendesk