Understanding first reply time (Professional and Enterprise)

Have more questions? Submit a request

80 Comments

  • Ariane Ramirez
    am trying to understand where the First Response calculation comes from. 
     
    Is there a detailed analysis on this?
     
    Say example, I checked on the report for the last 24 hours.
     
    It says here that I have 7 new tickets in the past 24 hours and the average response time is 20.85 hours.
     
     
    I checked on all the 7 tickets and found only 6 of them on the given time. Out of the 6, one of them is a new message from us, therefore there is no reply given. That leaves me with 4 tickets, which were all answered in less than 4 hours. 
     
    I just need to know how we arrived at an average of 20.85 hours
     
    I'm hoping that a more detailed report may be given to us to better understand this. Having a 20.85 hours response time is unacceptable and I know that the agents are performing better than that.
     
    Let me know what details you would need so that I can communicate my concern better.
    0
  • Madison Davis

    Hi Ariane! Looks like a member of our Support team was already able to assist you with this in a ticket. I'll her finish up with you there!

    0
  • Katarina Ondrejovicova

    Hi,

    We are monitoring the FRC and sometimes, as it happened to many others as I read here, the numbers are inexplicably high despite we reply to every new ticket within 1 hour. I have couple of questions about FRT calculation:

    1. A ticket is created by agent on behalf of user and put on Pending straight away. After that user replies and agent replies back. Is a FRT calculated from the time that the ticket is created to the time agent replies? Or does the clock stop while the ticket is on pending?

     

    2. When a ticket is created by agent as an outcome of an issue solved on call directly, the ticket is created and put on Solved status. The clock stops and FRT is null. Sometimes user replies days after that with an issue not related to the first one and reopens the ticket, agent replies to that. The clock starts again and the FRT is calculated from the ticket creation till agent's reply, is that correct? If so, what would you advise to avoid this?

     

    Thanks

    0
  • Jonny

    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! 

    0
  • Katarina Ondrejovicova

    Thanks for the reply Jonathan! 

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

     

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

    2
  • Blaine Knab

    Hi Jason,

    Thanks for your feedback! I have some ideas that might help with getting an FRT that better fits your workflow.

    I've created a ticket to discuss this with you.  I'll see you in the ticket!

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

    0
  • Jason Fordham

     I see no ticket, how am I supposed to get there?

    If you can demonstrate that the response time in the workflow you're suggesting is the time between the first post by the end-user and the response to that by me as a service provider, then you will convince me that there is a workable definition of "First Response Time" that reflects a useful metric. At this point, I see no way that starting the FRT clock when the ticket is opened rather than when the end-user sends an email/updates the ticket can work.

    We have a similar issue with spinoff tickets, where we decide to bifurcate the issue. If we open a new case for a question which comes up "by-the-way", and includes the answer, but it's then left waiting for a customer response while the main issue is worked on, then again, the clock runs until the response after the customer replies, and the FRT does not measure responsiveness on our part, but on the customer's. Every time that the customer's first response time is included in our response time, the metric loses value.

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

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

     

    Thanks!

    0
  • Jessie Schutz

    Hey Dustin!

    I'll need to confirm with some of my reporting experts, but you might be on the right track. Tickets that are closed by merge will automatically have a tag added to them (I think it's literally closed_by_merge), so you might try excluding that tag from your report and see if the number seems more realistic.

    I'll see if I can get some input from our reporting gurus as well.

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

    0
  • Zeke U

    In sum, providing I've set work hours correctly and incorporated holidays, the FRT clock is paused until re-initiation of business?  And it will no longer be necessary to send a rather pained, strained and ineffectual token e-mail over the weekend (when I should be "off") to end users simply to keep the metric from going haywire?

    I've just moved into a position where I do not believe parameters were necessarily set up by my predecessor to accurately record metrics.  Quite literally, token "stop the clock work" over the weekend was her recommendation and has been ongoing practice.  Ugh.

    So, just to be sure and for clarity, if I set the clock and holidays accurately, the system -- I'm presuming as designed -- will do things for me by pausing?  If that's the case, I'm throwing a party.

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

    1
  • Zeke U

    Thank you for the reply, it is appreciated.  That said, I do have a following query:

    Under Reporting>Insights (View Only)>Overview, there is a panel marked "Median first reply time" detailing that number over the previous thirty days.  By design, does this panel incorporate Business Hours going forward or will my true number be something I generate via "My dashboard" using a widget incorporating [Biz Hrs] First Reply Time choosing "this week/month/quarter" etc?

    Again, thank you for the reply.

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

    https://support.zendesk.com/hc/en-us/articles/203662436-Creating-dashboards-in-Insights-Professional-and-Enterprise-

    I hope this helps and happy reporting!

    0
  • Zeke U

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

    Thanks!

    0
  • Eagle

    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?

    0
  • Patrick Bosmans

    Hello Eagle,

    I'm going to pull your question into a ticket so I can get some more information from you and not ask you to post everything on a public forum.

    You should be hearing from me shortly!

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

     

     

    0
  • 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"? 

    Thanks!

    0
  • Nick Moore

    In the topic:

    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.

    Does this mean the clock keeps ticking?

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

    0
  • Nicole - Community Manager

    Hey Nick, here's what I found out: 

    Yes, the clock DOES keep ticking, and until FRT is calculated (by having a completed FRT), the ticket it not counted toward the overall average. 

    Let me know if you have additional questions! 

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

    2
  • 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: https://support.zendesk.com/hc/en-us/community/posts/204143826-Address-first-response-time-for-agent-created-tickets

    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.

    0
  • Sean Riley

    So how do the metrics on the individual agents calculate?  For example, we have a Tiered IT Dep. where the HelpDesk mitigates tickets that funnel in from a single email address.  They do not comment on higher tiered tickets such as administrative account actions to supported systems. So say they make a public comment, shutting off the FRT timer, and put in into the Systems Admin queue.  Now the higher tier agent completes the action required, comments, and sets the ticket to solved.  To whom is the FTR time assigned to, the first commenter or the final assignee to the ticket per closer/solved?

    0
  • Guy Dee

    Hi Sean -

    First reply time as discussed in this article is a simple numeric value stored as a ticket property. This means it's associated with the ticket, not with the user who actually made the reply. As a consequence the FRT number follows the ticket around wherever it goes, so it will turn up under the current ticket assignee if you're slicing your report by assignee.

    It is possible, through the use of some complex custom metrics, to report on first reply time by ticket event. This allows you to get more detailed information about the first reply such as when it was made and what agent made it. If you're interested in pursuing this course of action, this recipe article covers the process in detail.

    0
  • Jim Tatum

    Hello all,

     

    I have need for a custom metric that only calculates the FRT to only when the ticket is assigned or taken by an agent. I have been working with Zendesk support and have been told this is very complicated, but was hoping someone here in the community has already done this. I do not want the FRT to include first comment/reply, but when ticket is assigned. All of our SLA are based on when a ticket is pickup or assigned.

    0

Please sign in to leave a comment.

Powered by Zendesk