Understanding ticket reply time

Return to top


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

  • Cheeny Aban
    Zendesk Customer Care

    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!


  • Oliver Tietze

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

  • Chandra Robrock
    Community Moderator

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

  • Amy Dee

    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!

  • Oliver Tietze

    Thank you @... 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?


    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?


  • Amy Dee

    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!

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

  • Joanna Walkowiak


    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.


  • Bogdan Vintilescu

    Hello Zendesk!

    Is the first reply time metric included in the first resolution or full resolution metric or will the first reply time remain a separate metric in its own?

  • Amy Dee

    Hi Bogdan! The first reply, first resolution, and full resolution time metrics are all measured and recorded separately. You can report on any of them for any ticket, in business and/or calendar hours.

    The durations do overlap, but it's already accounted for in the metrics. For example, if a ticket is first set to solved after 12 hours, then reopened and solved again 4 hours later, first resolution time will be 12 hours and full resolution time will be 16 hours. Technically, that means the first reply and resolution times are "included" in the full resolution time, but you don't need to take any extra steps to report on them.

    I hope this helps! Happy reporting!

  • Bogdan Vintilescu

    Hi Amy,

    Thank you so much for following up on this. I would like some clarification on these metrics overlapping: I have a query with multiple entries and two of them yielded results differing from that expectation One of the results was:

    First Reply Time = 141 minutes

    First Resolution Time = 50 minutes

    Full resolution Time =88 minutes.

    I should note that the other 20 entries metrics (assignees on the query) seem to follow the formula:

    First Reply Time < First Resolution Time < Full resolution Time, but this one does not. Any idea what may trigger this? 

  • Amy Dee

    Hi Bogdan! There are a couple things to check for a report like this.

    Up front, I can't see how this report is aggregated. You're using the median, but it's not clear how many or which tickets are in each row. If there are a number of tickets with long first reply times that have not yet been solved, they'll add to the reply metric but not the resolution metrics. That could skew the results.

    Assuming these are all solved tickets, the next consideration is the schedule. I see you're using business hours metrics in your report. That adds some complexity to the metric calculations.

    Zendesk does not maintain a live counter for ticket durations. Instead, it calculates durations at the time of the relevant ticket event, based on the schedule at that time. Zendesk applies the schedule to the whole metric duration, regardless of when the schedule was added/updated.

    That can lead to situations like the one you see here. If a ticket was on Schedule A at the time of the first reply and changed to Schedule B before solving, then the first reply metric will use Schedule A and both resolution metrics will use Schedule B. The resolution metrics will apply Schedule B to the whole duration, from creation to solve, ignoring the fact that Schedule A was in effect earlier in the ticket. If Schedule A has longer hours than Schedule B, it could lead to the business hours first reply time being notably longer than the business hours resolution times.

    The same thing happens if you change the hours on an existing schedule. You don't need to have multiple schedules in your account for this to occur.

    If you see a bunch of results like this around the same time and nowhere else, check for updates to your primary schedule. If you see tickets in one workflow doing this frequently while others don't, check for schedule changes within that workflow. And, just to confirm the actual timeline, set up a query in calendar hours for reference. That should help you fit values like this into context.

    I hope this helps! Happy reporting!

  • Bogdan Vintilescu

    Hi Amy! 

    This is very helpful! I am using a median of these metrics and the query is for ~2,000 tickets on average for each assignee. These are all solved tickets, but there were some with long first reply times. We did not change the schedule during this query, but there was another team involved in working on some tickets and their schedule may be different than ours. Will look further into it. Thank you!


Please sign in to leave a comment.

Powered by Zendesk