Understanding ticket reply time

Return to top
Have more questions? Submit a request

119 Comments

  • Nathan Alvarez

    If an agent's tickets are primarily auto-generated and do not warrant a response, does marking the ticket as solved count against first reply time? Or is it simply the time it takes between receiving the ticket and closing the ticket that contributes to the first reply time metric?

    0
  • Brett Bowser
    Zendesk Community Team

    Hey Nathan,

    If an agent does not reply to a ticket before solving then the first reply time for that ticket would be a null value. This should not count towards your overall first reply time metric.

    Let me know if you see any wonkiness on your end and we can take a look.

    Cheers!

    0
  • Nathan Alvarez

    Hey Brett,

    One of our agents' first reply time is well over 200 hours but we can't figure out why. Can you take a look? I've enabled account assumption. His name is Travis.

    0
  • Brett Bowser
    Zendesk Community Team

    Hey Nathan,

    I'll create a ticket on your behalf so our Customer Advocacy team can look into this for you.

    You'll receive an email shortly stating your ticket has been created.

    Cheers!

    0
  • What happens with merged tickets? Example: a customer sends us a ticket (A) via email and then creates a second ticket (B) 5 minutes later for the same item. Two hours later we merge B into A and then reply to A. Is the average reply time:

    • 2 hours (B does not get counted because it moves from New to Closed and never gets a public reply)
    • 1 hour (A's FRT is 2 hours and B's FRT is 0 hours)
    0
  • Brett Bowser
    Zendesk Community Team

    Hey Sy,

    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 First Reply Time metric.

    Let me know if that's now what you're looking for!

    0
  • InVenture Capital Corporation (Tala)

    Hi Brett. Not exactly what I'm looking for. I understand that the numerator would be 0 (no reply time). My question is whether the denominator would be 1 (it still counts as a ticket) or 0 (it's as if the ticket never existed). This is important for us to know as we look at average reply times across groups of tickets.

    0
  • Amy Dee
    Zendesk Team Member

    Hi Sy! Merged tickets are still counted separately for all calculations and metrics. Zendesk doesn't combine the backend data or remove the merging ticket from the API. 

    For your example, ticket B would be one ticket with a null first reply time (and a 115-minute full resolution time), and ticket A would be one ticket with a 2 hour first reply time. By default, ticket B would not count in an average first reply metric, because null is not a valid value for calculations. Ticket B may still count for the denominator, though, because it is a unique ticket.

    You'll want to carefully consider your report and metric filters to account for edge cases like this. Perhaps you want to exclude all tickets with the closed_by_merge tag. That would keep ticket B out of your report, but it would still allow an un-merged ticket with no first reply time. Perhaps you want to limit your report to tickets with a valid first reply time, which would allow merged tickets as long as they had interaction before they were merged. The best option depends on your overall use case.

    I hope this helps! Happy reporting!

    2
  • Bruno Muniz

    How to create the formula to only consider tickets with reply time > 0 on the MED(First reply time (hrs)) metric ?

    0
  • Rob Stack
    Zendesk Documentation Team

    Hi Bruno, if this is for Explore, you could use a standard calculated metric like:

    IF (MED(First reply time (hrs))>1) THEN [Ticket ID] ENDIF

    I think that will accomplish what you want. Thanks!

    0
  • Jody Bevenger

    We are using Zendesk for 2 different groups (Software Support and Equipment Support) and 2 different business hours. We are trying to track FRT(business hours) for our Equipment Support group.

    If I set a trigger to set schedule to equipment support when ticket form is "Equipment". How will this affect FRT?

    If a ticket comes in as New Support Call (Software business hours) and the form is changed to Equipment Support(Equipment business hours) 20 minutes later. An agent responds with a public reply 5 minutes later, will FRT be 25 minutes or 5 minutes?

     

    0
  • Amy Dee
    Zendesk Team Member

    Hi Jody! For business hours metrics, Zendesk checks the schedule at the time of the relevant update, then calculates the metric accordingly. It doesn't maintain a live timer. 

    For your example, it sounds like the ticket starts with the Software group and schedule for 20 minutes, then moves to the Equipment group and schedule for 5 minutes, then gets a first reply. In that case, Zendesk will record a calendar hours first reply time of 25 minutes. For business hours, Zendesk will adjust the whole 25-minute duration according to the Equipment schedule.

    It doesn't matter what changes a ticket goes through on the way to its first reply. The first reply time metric will always run from creation to that first reply, and business hours will be calculated in full according to the schedule at the time of the reply.

    (SLAs do display a countdown timer, but the timer is based on a fixed breach point. Zendesk recalculates the breach point when/if the policy changes, based on the schedule at the time of the change. It doesn't use the timer to measure business hours.)

    I hope this helps! Happy reporting!

    0
  • Richard Bailey

    As part of this article in the section

    "How First reply time is calculated" there was a claim "An agent creates a ticket. Timing starts when the ticket is created and ends at the agent's next public comment." 

    From my understanding in another article "How do i create a First Reply Time SLA for agent created tickets?"  https://support.zendesk.com/hc/en-us/articles/226673228?page=1#comment_360005400374. In this article it states "Creating a FRT SLA for agent created tickets is not possible". 

    In practice we have found that any agent created ticket via email or web form channel will arrive without a first reply SLA. As in the system accepts the first public reply as the actual first reply. This is in direct conflict with the mentioned statement "....and ends at the agent's next public comment". 

    If there is any update on how we can track first reply for agent generated tickets please let me know. Also if anyone has a workaround that interfaces directly with the SLA timer in Zendesk I am open to other options. 

    2
  • Amy Dee
    Zendesk Team Member

    Hi Richard! This article is primarily about the native first reply time metric. The metric is recorded with the ticket data in calendar and business hours, regardless of whether an account has SLAs or not. The native metric's behavior does not change in different workflows - it always runs from ticket creation to the first public agent comment after that.

    The first reply time SLA target is slightly different. SLAs are a newer feature (when compared to native metrics), and their metrics are stored in a separate dataset. 

    The two first reply time measurements are usually similar, but agent-created tickets are a major difference between them. Native metrics run from creation to the agent's next public comment, while SLA first reply targets aren't activated.

    The "Zendesk SLAs and first reply time" section in the article above goes over some other known differences between the two first reply time measurements.

    For your reporting question - the best option for reporting depends on the use case. You can still use the native first reply time metric for agent-created tickets, although it may skew high if the agents wait for end-users to respond before commenting again.

    For SLAs, you could use next reply time targets to capture the time from the end-user's message to the agent's reply (and every reply interval after that). If you have an internal workflow where agents interact with each other, you could also consider a periodic update target. Periodic update targets and reply time targets include "instance" counts in reports, so you can easily find the first reply interval for each one. 

    I hope this helps! Happy reporting!

    0
  • Krista Shaver

    Do answerbot resolved tickets count against first time reply?

    0
  • Madison Davis
    Zendesk Community Team

    Hey Krista - no, a ticket resolved by Answer Bot would have a null first reply time. First reply time only measures a first public response from an agent. Answer Bot's suggestions do not count as an agent comment. Hope that helps!

    0
  • Mateusz S

    Hi,

    What's the logic behind the difference between FRT metric we can report on and FRT metric in SLAs?

    Is there a work around for adding FRT SLA to tickets created with a private comment?

    0
  • Amy Dee
    Zendesk Team Member

    Hi Mateusz! The native first reply time metric is designed to be universal and consistent for analytics. It always behaves the same way, so the results are predictable. That makes benchmarks and historic reporting more effective. However, it also means the metric isn't flexible for different workflows.

    SLAs are designed to prioritize live workflows. They're certainly useful in analytics, but their main purpose is keeping tickets on track. SLAs try to take the workflow context into account, so the target makes sense for agents.

    At this time, reply time SLA targets only apply for public comments. The only exceptions are for tickets created by light agent requesters, and for private tickets created on behalf of an end-user. We have more information in our article on Defining and using SLA policies.

    I hope this helps! Happy reporting!

    0
  • Lou Freitas
    So I have an issue with first reply time that support couldn't really help with
     
    There are system generated emails that are sent to end-users and our team…these tickets are automatically solved via trigger.
     
    Here is the first reply time issue we encountered…
     
    1. System generated email came in on a Wednesday night out of business hours, and was automatically solved via trigger. No Reply From our team.
    2. An end-user replied to the solved email on Sunday outside of business hours.
    3. Monday morning within minutes, our agent responds to the end-user Sunday night reply.
     
    Instead of our first time reply being minutes, that ends up being 24 hours…I understand why it was calculated this way, it just doesn't represent what happened.
     
    What can I do to make the FRT data more accurately represent what happened on the ticket? 
     
    This is what support told me…
     
    "If we're referring to business hours only, it will only show 24 hours as follows: November 18 (ticket creation, outside of business hours) - 0 hours, November 19 (no public reply) - 12 hours, November 20 (no public reply) - 12 hours"
    0
  • Amy Dee
    Zendesk Team Member

    Hi Lou! The native first reply time metric always starts at ticket creation, and it always stops at the first public agent comment after that. It doesn't matter what the end-user does between those two events. If your schedule matches your description, then the native metric is accurate. There were 24 business hours (plus some minutes) between ticket creation and the first public agent reply.

    If you want to start a business hours timer at the reopen, I recommend using a next reply time SLA target instead. Those run from a public end-user comment to the next public agent comment, and they can be set for business or calendar hours. You can report on each individual instance of the SLA as well, so you can focus on the first response after the reopen.

    SLA targets aren't retroactive, so it won't change the data for your existing tickets. However, it should give you more reporting options going forward.

    I hope this helps! Happy reporting!

    0
  • Fiona W

    We have the agent workspace activated in Support so that chats are dealt with through Support too. Does this metric include or exclude chat tickets? I'm thinking they would skew the data since chats are replied to more quickly than email tickets.

    0
  • Cheeny Aban
    Zendesk Customer Advocate

    Hi Fiona,

    Thank you for leaving a comment on our Community.

    Metrics such as First reply time, Unreplied tickets, % One-touch, Two-touch solves, Comments (all user types), and Agent updates consider only email replies on the ticket. You can find more information by checking Messaging reporting in Zendesk Agent Workspace

    I hope that helps!

     

    0
  • Oliver Tietze

    Hello Amy Dee et al. I didn't read all 112 comments (sorry) but we have several tickets, sourced from chat, calls or API created tickets, where an SLA was assigned (including first/next reply/periodic update metrics), but *no* metric is in effect. i. e. there is no "Next SLA breach" indicator, even though you explained clearly that for the 'first reply time' the start point is the ticket creation.

    What's wrong with our tickets?

    Best regards
    Oliver

    0
  • Chandra Robrock
    Community Moderator

    Oliver Tietze I'm not 100% sure this is the answer in your case, but would you mind double checking to see if this non-SLA tickets have a Priority selected?

    If they don't have a Priority selected, this would explain why they technically match one of your SLA policies but no SLA target is being assigned. More info here

    0
  • Amy Dee
    Zendesk Team Member

    Hi Oliver! The first reply time metric always starts at ticket creation and always stops at the first public agent comment after that. However, SLAs are different.

    If a ticket is created with a private comment, the first reply time SLA target is deferred. It doesn't start until the first public end-user comment. If the first comment is private, you can leave any number of public agent comments without doing anything to reply time SLA targets. The SLAs won't start until the first end-user comment.

    If a ticket is created with a public agent comment, the first reply time SLA target does not run. It doesn't count as an achievement or breach. Meanwhile, the first reply time metric starts as normal and runs until the next public agent comment.

    Periodic and pausable update targets start at the first public agent comment. (For pausable targets, it's the first public agent comment not in pending status.) If the ticket starts with a private comment, those targets aren't active yet either.

    Channels like Talk and Chat start with private comments, then get their recordings/transcripts added later, often in more private comments. Those channels don't usually activate SLA targets until later, after the initial conversation is complete.

    For API tickets, it depends on how they're created and what the initial workflow looks like. The most important detail is whether the first comment is public or private. If the first comment is public, what is the commenter's role? 

    I hope this helps!

    0
  • Oliver Tietze

    Thank you Amy Dee for the clarification. For our API tickets we get tickets added by an 'Agent' API User but with the submitter ID of an Enduser. Even tho triggers recognize the 'current user' to be an Agent, the tickets have the proper SLA + metric + target assigned.

    For call + chat tickets I see the functionality definitely missing consistency. Do I understand you right that the metric will be measured (in the reporting) always correctly, even though there is no 'SLA breach/achieved' event?

    Example:

    12:00 Creating a chat ticket
    12:05 Ending the chat (transcript goes to the ticket)
    12:15 Followup message from Agent to User + PENDING
    13:00 Reply from User to Agent
    13:30 Response from Agent to User + SOLVED

    Will this report as 'First reply time = 15 Minutes' but 'SLA (First reply time) unknown' and also 'Next reply time = 30 Minutes' with 'SLA (Next reply time) = achieved (100%)'?

    And will the agent see NO 'reply' target in the ticket until 13:00 (and potentially a 'periodic update' target already from 12:15 on)?

    I understand that the sense of 'First reply' is questionable with chats, but if there would be a value for 'First reply time' in the reporting, IMHO it should also be in the SLA/in the ticket to be consistent.

    The use case is "if the ticket needs a further response" (i. e. user asks a question in chat that can't be answered immediately), the ticket will stay open and needs to compete with a million other tickets having SLA goals. Missing the SLA goal makes the ticket disappear at the end of the list, i. e. in nowhere if the list is long.

    Would the 'end user wait time' target be the solution for chat + call tickets that need further processing. As these could be 'pending' (target paused) I guess we'd need some nudge/automation to be fully covered,

    Anything I miss?

    Thanks
    Oliver

    0
  • Amy Dee
    Zendesk Team Member

    Hi Oliver! You described a lot of moving parts there, and a lot of them depend on the specifics of the workflow. 

    For reply and update targets, SLAs look at the comment author to determine the role. If the comment is created by an API call with agent credentials, but the author is set to an end-user, it should count as an end-user comment for SLA targets. That's likely why your API script worked in some workflows; it was probably setting the first comment's author.

    For your Chat ticket example, the native first reply time metric will start at 12:00 and end at 12:15 with the agent's response (assuming the agent left a public comment). That's the native ticket metric, separate from SLAs, and it has no variations. 

    For SLAs, it would depend on how the ticket was created and whether the transcript is public. Chat tickets are often started with a private comment and end-user requester. If that's the case, and the transcript is private as well, then the first reply time SLA target would start at the end user's 13:00 reply and fulfill at the 13:30 solve. There would be no next reply time targets for that ticket. Periodic update targets would start at the agent's 12:15 reply and fulfill at the 13:30 solve.

    If the ticket is created with a private comment and end-user requester, and the transcript is public with an end-user author, then the first reply time SLA target would start at the 12:05 transcript comment and fulfill with the agent's 12:15 reply. The customer's reply at 13:00 would start a next reply time target.

    SLAs are based on ticket events in Support, and they operate in whole minutes. Chats often move much faster, with tighter targets. Chat also runs through a different system on the backend, with its own metrics and data sources. SLAs and Chat don't work together in their current iterations. Our developers are always working on improvements, though, so the two may align better in the future.

    For specific use cases or workflows, I recommend reaching out to our support team directly. Tiny details can have a big impact, so it's better to confirm those details in the context of your account.

    I hope this helps!

    0
  • Oliver Tietze

    Thank you for these very deep and also very clear insights.

    I consider them very helpful (much more than the documentation I found) and I'd like to encourage you to put the disctinction between 'native reply metric' and 'SLA functionality' in a prominent place ;)

    Thank you very much!
    Oliver

    0
  • Joanna Walkowiak

    Hi!

    We want to turn on Ticket Sharing but we are facing some difficulties with FRT.

    When we create a ticket and share it through ticket sharing channel, FRT is not measured as the agent on the second Zendesk account is treated as an agent, not as an end-user.

    Is there any option to solve it? Can an agent be treated as end user on the Support account with which thickets are shared?

    We need to measure FRT and we are struggling to do it with ticket sharing feature turned on.

    Thanks!

    0

Please sign in to leave a comment.

Powered by Zendesk