Insights recipe: First reply time by event

Have more questions? Submit a request

53 Comments

  • annie jasmine
    Comment actions Permalink

    Amy,

     

    How can I get the below report in Overview into our insights? I do not find this report in the list of reports in good data. I tried using "Tickets by First Reply' but that extracts the count of tickets rather than %.

    Thanks 

    0
  • Anthony Garcia Jr.
    Comment actions Permalink

    Hi Amy, 

     

    Would you please advise on how I can make the First Reply Time by Event metric to only compute the amount of time it took for an agent to put a public reply on the ticket from ticket creation within business hours? Will changing Ticket Updated (Minutes) on the formula to First reply time in minutes within business hours do? Thanks in advance!

    0
  • Rory Dearling
    Comment actions Permalink

    For the last caveat:

    An agent is demoted to an end-user.

    If this happens, but then we switch that person back to an agent, does it not "reverse" the issue?

    I tried to do this (we were on Plus, but now Enterprise), and it doesn't look like it's working - my report values are not changing, and I can see that the person is still listed as an end-user when I go through the Updater attribute values listings.

     

    0
  • Mariko Yano
    Comment actions Permalink

    Hi Amy!

    I've already followed that recipe :) I tried doing it that way but struggling with getting our first reply time in business hours using excel.

    I've listed down our business hours below (we have APAC and Seattle Support hours). The gaps in support hours make it a little challenging for me. Had we been doing 24/7 support, this would be easy. :)

    sunday 5pm-11:59pm

    Monday: 12am-2am, 8am-11:59pm

    Tuesday: 12am-2am; 8am-11:59pm

    Wednesday: 12am-2am; 8am-11;59pm

    Thursday: 12am-2am; 8am-11:59pm

    Friday: 12am-2am; 8am-5pm

     

     

    0
  • Matt Hoffman
    Comment actions Permalink

    Hi Adi -

    Two points here - first, you can probably make this report without including the "first comment = private comment" part into the metric. Check out the Ticket Update Via attribute and filter for API Phone Call Incoming and API Phone Call Outgoing - you can use this with an events-based metric like # Tickets Created to see tickets that had an update via RingCentral.

    Second (and the reason why I addressed the other possibility first) - some of the Metrics Masters and I had a look at this and you would be very hard pressed to come up with an accurate metric that combines this events-based FRT with a built-in component for first comment = private comment. Filtering the report it is used in could result in erroneous results, for example if a date filter slices off the earliest comment so now the 2nd comment appears to be the first comment.

    If you were to brute force this sort of a metric, you would probably want to do it as such:

    1 - create a metric for "timestamp of the first private comment"

    2 - create a metric for "first public ticket on the comment"

    3 - return tickets where 1 is less than 2.

    4 - filter your report, built off of another metric like FRT, with a numeric range filter for the metric made from combining 1 through 3.

    As you can see, this is messy - way better to do it without a complex metric, if possible! Based on what I know about RingCentral I think you will have luck with the method that I outlined first, if not you could employ a trigger that will tag or otherwise categorize tickets made with Ticket: Channel: CTI Phone Call (incoming).

    If you have any questions just drop us a line at support@zendesk.com.

    0
  • Jessie Schutz
    Comment actions Permalink

    Hi Jaime! Welcome to the Community!

    Have you checked out the Time Tracking app? I believe that  will help you get the data you're looking for.

    0
  • Dan Cooper
    Comment actions Permalink

    Hi Mariko, 

    Unfortunately it's not possible to show first reply time for replies that occur later in a ticket. You could potentially adapt your workflow to capture this by having your tier 1 create a new ticket for your tier 2 agents, but you'd give up the total time that the customer has been waiting for that entire interaction. 

    0
  • Dan Cooper
    Comment actions Permalink

    I'm really glad someone came in to debunk my own searches (and you have a super awesome article on it already)!  Thanks Amy! 

    0
  • Amy Dee
    Comment actions Permalink

    Hi Rory! "Reversing" the role should work (after the next data sync), as long as it is the same user profile with the same User ID throughout. If you delete and recreate a user, though, or promote a different profile for the user, then it won't work. Those workflows change the ID number, so they count as new agents.

    If your agent has the same ID number as before, but they still aren't updating in Insights, then something else may be going on. I'm going to follow up with you in a ticket to investigate further. Watch for my email!

    0
  • Jeff S.
    Comment actions Permalink

    This is a super helpful report, Amy -- thank you! I'm trying to adapt it to filter out tickets created by an agent as customers' reply times are outside our control. I'm having trouble though. As you can see in the screenshot below I'm trying to filter out using the Requester Domain <> flag but I'm still getting agent-originating tickets in my report. I've hidden my companies domain in the screenshot here, but know that I am selecting it using the Attribute Values selector.

    Do you have any advice? Thank you!

    0
  • Ceren Has
    Comment actions Permalink

    Is it possible to build a "% change in first reply time since previous week" key metric? If yes, how? :)

    0
  • Adi
    Comment actions Permalink

    Hi,

    I'm trying to create a metric that calculates tickets that started with an internal update (because they're phone tickets created by the RingCentral app). 

    I wrote the following and it's still pulling cases that their first comment is public. Any ideas how to fix?

    0
  • Amy Dee
    Comment actions Permalink

    Hi Ben! I’ve been looking into this for you.

    As it is right now, Zendesk calculates a few key metrics in calendar and business hours. Apart from the first reply time, they all happen after a ticket is solved (first resolution, full resolution, agent wait time, requester wait time, and on-hold time). For all other updates, Zendesk records a simple timestamp.

    For the reporting fact you propose - time since creation in business hours - Zendesk would need to do a full duration calculation with business hours filter for every single update on every single ticket across the whole of the Zendesk platform. The processing requirements alone are huge, and that’s before logistical questions (like how to handle tickets moving through different business hours at different stages).

    I agree that a metric like this would be incredibly useful, and it would certainly allow for a lot of valuable reports. Unfortunately, the metrics architecture just doesn’t support it right now.

    It may still be possible to get close by using SLA targets. This will get into account specifics, though, so I’m going to pull you into a ticket. Watch for my email, and happy reporting!

    0
  • Olivier Pascal Netatmo
    Comment actions Permalink

    Hi Amy

    I am far away to be an expert but I would like to know if I have to follow the same steps to get the reply time for new tickets and for open tickets?

    Thank you

    0
  • Amy Dee
    Comment actions Permalink

    Hi Oliver! It looks like you posted this question over in the community as well. There are some notes on the post, and you should have an email soon to follow up in a ticket.

    Watch for that email, and happy reporting!

    0
  • Amy Dee
    Comment actions Permalink

    Hi Art!

    If you're interested in ticket creation dates, then it will be much easier to use the default first reply time metrics. The default values are stored as ticket properties, so they work well in a ticket-based report.

    That's not to say this recipe won't work in that context. If you use the Date (Ticket Created) attribute, this recipe should return the same results as the default first reply metrics. It just may not be worth all the extra hassle if the default already meets your needs.

    There are a few specific cases that the default metrics can't cover. These are things like finding outliers by the date of the reply, or crediting the agent who replied even though they're not still assigned. Those are cases that must use this recipe.

    Hope this helps! Happy Reporting!

    0
  • Amy Dee
    Comment actions Permalink

    Hi Paul! There are two things I would check up front.

    First, just to confirm, are you using Ticket updated (minutes) or Ticket updated at (minutes)? The two look similar, but they do different things. Ticket updated (minutes) returns the timestamp for any given update, which is what you need for this recipe. Ticket updated at (minutes) returns the most recent update timestamp, which isn't helpful here.

    Second, do you get a lot of tickets through inbound ticket sharing agreements? The creation and update timestamps for shared tickets can get a little skewed, since updates are coming from two different accounts. You may need to report on those tickets separately.

    If you're still having trouble finding the cause for these discrepancies, I recommend sending in a support ticket. Please include your draft report and metrics, along with a few example tickets that return negative numbers. We'll take a closer look.

    I hope this helps! Happy reporting!

    0
  • Amy Dee
    Comment actions Permalink

    Hi Ryan! This recipe has a lot of moving parts. I can't guarantee one approach for all use cases. However, I'd start with something like this:

    • SELECT COUNT(Ticket Id, Ticket Updates) WHERE (SELECT First Reply Event Comparison BY Ticket Id) = 0

    This would count tickets by that first reply event. I did some basic testing with the report-level filters described in this article, and the results were encouraging. I saw the number of first replies posted by each agent on each date.

    That said, you should still closely monitor and audit your results, to make sure it fits with your data.

    Happy reporting!

    0
  • Brandal Henao
    Comment actions Permalink

    Hi Amy 

    I tried using this recipe but it's not taking the correct values in some cases and I don't know why :S 

    This is what I have: 

    where the second filter is the one recommended by you adding the empty values (tried the default recipe and it didn't work as expected either .. 


    The organization with org_tags is based on your other recipe https://support.zendesk.com/hc/en-us/articles/228202567-Reporting-on-user-and-organization-tags

    Any ideas why it's not working as expected?, the average should be around 0-2 for all weeks .. 

    Thank you !



    0
  • Amy Dee
    Comment actions Permalink

    @Dan - You're welcome! That's definitely a fun article for building crazy reports. As a data nerd, I highly recommend losing an afternoon with it.

    @Mariko - Insights can't see your schedule, and Zendesk only records business hours on default metrics and business hour SLAs. There is no way to do this conversion automatically with native Zendesk tools. Once you get into custom durations like this, you would need to do a lot of complicated and repetitive math outside Insights to filter for business hours.

    That said, the values in the Ticket updated (minutes) fact are just epoch timestamps in minutes. There may be apps or programs out there that can do this sort of conversion for any epoch start and end times. If you find something like that, you could export the timestamps on their own and calculation the duration separately.

    Please note - most epoch timestamps are recorded in seconds, and Insights uses minutes. You'd probably need to multiply your results by 60 to be compatible with an epoch-based app or script.

    I hope this helps! Happy reporting!

    0
  • Oliver Taylor
    Comment actions Permalink

    Hi Amy,

    I have a metric I'm trying to get to and this post is the most similar I have found so far and I'm hoping you can help. What I'm looking to do is this:

    I'm looking to create a metric that show me the percentage of open tickets where there has been no communication from us to the customer for the last x days. I want to put a target on this for my Support team.

    First I want to get to the date value of the last comment, filtered by agent role and public = True.

    Then I want to count the number of tickets in 'Open' status, where the above date is greater than 10 days ago.

    Lastly, I want to work out what that number is as a percentage of all tickets in open 'status'.

    I'm really struggling with the MAQL to do this. I'm thinking it will need to be multiple metrics but I've been round in circles many times. Any ideas?

    0
  • Amy Dee
    Comment actions Permalink

    Hi Anthony!

    Unfortunately, that won't be possible with this recipe. Insights can't see your business hours, so it has no way to incorporate them in the calculation. If business hours reply times are important for you, you'll need to use the default metrics.

    The facts you mentioned are on different scales, so they aren't interchangeable:

    Ticket updated (minutes) is the epoch timestamp of a particular event. For Zendesk tickets, this is usually around 24 million minutes. You get a duration by taking the difference of two epoch timestamps.

    First reply time in minutes within business hours is the completed calculation from Zendesk. It has already found the start and end times and adjusted for business hours. This may be 2 minutes or 2000 minutes or more, depending on the ticket.

    I hope this helps!

    0
  • Jeff S.
    Comment actions Permalink

    That did it -- thanks again Amy!

    0
  • Pilar Santerbás
    Comment actions Permalink

    Hello, 

    I read everything and compared it an existing report that I have. We want to look at the average First Reply (public comment) time within business hours in minutes by the agent assigned to the ticket on a weekly basis. So I come up with this:

    What: [Biz Hrs] First Reply Time (min) [Mdn]

    How: Ticket Assignee

    Filter: 1.- Week (Sun-Sat)/Year (Event)
    2.- Group - (selected the groups we want to see)

    I just want to double check with the community that I did it correctly. I would appreciate some feedback. 

    Thank you very much! 

    0
  • James Sanford
    Comment actions Permalink

    Hey Matthew!

    Yes, you can substitute Median in place of Average in the "First Reply Time by Event (hrs) [Avg]" metric construction illustrated in this guide.

    Your metric would just start with "SELECT MDN( (" instead of "SELECT AVG( ("

    0
  • Mariko Yano
    Comment actions Permalink

    Thanks Dan. I tried making a public comment an internal comment, then add another public comment. That action still didn't update my first reply time. Is that expected?

    0
  • Art Rybalko
    Comment actions Permalink

    Thanks, Amy! Yes, being able to attribute first response time to the right agent is a big plus.

    0
  • Dan Cooper
    Comment actions Permalink

    I'm not sure if the private to public comment would work, but it's an interesting idea.  The insights refresh time isn't instant (it's 1 hour on our Enterprise plan) so you may need to wait to see if that sticks.  As far as I'm aware, I haven't heard anyone else try what you call out, so if it works in your testing, share it.  It would be great to give people an option if they need one. 

    0
  • Amy Dee
    Comment actions Permalink

    To all the awesome folks following this comment section -

    There's a new version of this recipe! You can find the details here: First reply time by event (version 2). The new version builds the filtering into the metric itself, so you don't need the three-part numeric range filter. This makes the metric much easier to use. Give the new version a try in your next report!

    To Ceren - 

    The percent change report you described won't work with this version of the recipe, since you can't see the previous week with the numeric range filter in place. Fortunately, the new version of the recipe does allow you get those results, since the filters are all built in.

    Try building the new version (available here), then use it in the template from this recipe article: Time-over-time reporting. You'd just need to use the new first reply metric instead of # Tickets, and Week (Mon-Sun)/Year (Event) instead of Month/Year (Ticket Created).

    To Olivier -

    This recipe (old and new version) doesn't include any filter for the ticket status beyond excluding deleted tickets. It should give you the same results regardless of whether the ticket is in new or open status.

     

    I hope this helps! Happy reporting, everybody!

    0
  • Kelsey Hales
    Comment actions Permalink

    Love this article, this was very helpful and taught me a bit about how some of the MAQL custom metrics work. Something I'm trying to track is the total # of first replies an agent sent vs non-first replies (our handle time expectation for a first response is much more brief than a second or third response). How do I isolate this? I've added Ticket Id to the How, and that pulls what appears to be correct data, but I can't seem to get just a total number. Any ideas where to start on this?

    0

Please sign in to leave a comment.

Powered by Zendesk