Insights recipe: First reply time by event Follow

Comments

28 comments

  • Avatar
    Art Rybalko

    Thanks for the great recipe, Amy!

    We didn't get to the end on the first try but looks like we have the metrics working right now :)

    One question though, what would happen if we use the ticket creation dates in How with these metrics?

    If we want to slice by hour of the day, for example, I would argue that it's more important to look at response times for the hour the tickets' been created at, that way we know we're not staffed enough during those hours, while if we slice it by hour of event (first response in this case) we would not be addressing real bottlenecks.

    Does this make sense?

  • Avatar
    Amy Dee

    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!

  • Avatar
    Art Rybalko

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

  • Avatar
    Anthony Garcia Jr.

    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!

  • Avatar
    Amy Dee

    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!

  • Avatar
    Ben Fulton

    Hi Amy,

    I have been struggling with developing this exact metric over the last couple of weeks myself, and our main problem is that we would also really like to be able to determine our custom first reply times (and other similar metrics) in business hours. 

    What are the chances we could get a new attribute added to Ticket Updates called something like "Minutes since ticket creation in business hours"? This would allow for a host of custom metrics based on any kind of ticket update event, but in business hours.

    To give you a sense of our use case--we have a multiple escalation model: Customer Service Tier 1 & 2 and R&D Tier 1 & 2, and I would like to be able to track first reply SLAs at each level.

  • Avatar
    Amy Dee

    Hi Ben!

    Unfortunately, that sort of report isn't possible at this time. Insights is not a real-time reporting platform, so it can't support a live "minutes since" counter. It calculates durations by finding the difference between specific start and end points after they occur.

    Also, Insights can't see your Zendesk business hours, so it can't incorporate them in its calculations. Any duration based on business hours needs to be calculated in Zendesk, then sent to Insights as a completed value. 

    If you have SLA targets based on business hours, I recommend using Zendesk SLAs instead. That would allow you to specify targets in business hours for each escalation. You can then report on how long each SLA target was active on each ticket. That should get you pretty close to the results you describe.

    We have more information about creating the policies on our SLA Resources Page. You can see the SLA data available for reporting in our Insights object reference and metrics reference.

  • Avatar
    Ben Fulton

    Hi Amy,

    Thanks for your response, but I'm afraid it does little to address our situation. First, let me go into a little more detail about what we require, and then let me clarify what I think we are asking for.

    We have a fairly deep support organization. Our escalation model looks something like this:

    IT Tier 1->IT Tier 2->R&D Tier 1->R&D Tier 2

    Each level has agents who are responsible for addressing escalated issues, and each level has an independent SLA for their first touch (a public or an internal reply, usually).

    Zendesk's built-in model for SLAs only provides business-hour SLAs for first and next public replies, and these replies may be made by any agent.

    What we need is the ability to look at the first touch times, within business hours, for agents belonging to each escalation group. An issue that hit the maximum escalation level would have four times associated with it--one for each level. We can use these numbers to monitor our ticket life-cycle, to determine if we need to improve coverage at any particular level.

    I can get close to what we need using something similar to the recipe that you provided. What is missing is the elapsed time, filtered by business hours, between ticket creation and the ticket update event. Note that this is NOT a live value. If Zendesk included this attribute as part of Ticket Updates, it would allow users to create a number of custom metrics based on different kinds of updates, all using business hours.

  • Avatar
    Amy Dee

    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!

  • Avatar
    Rory Dearling

    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.

     

  • Avatar
    Amy Dee

    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!

  • Avatar
    Adi Ravia

    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?

  • Avatar
    Matt Hoffman

    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.

  • Avatar
    Chris Lambert

    Is there a way to filter tickets with a first response time greater than, say, 50 hours first response time?  I have agents that sit on "call back" tickets for days, even weeks, before a response is required.  These long duration tickets really throw off my average first response times and are not representative of actual response times within my support department.

  • Avatar
    Amy Dee

    Hi Chris! You can do that with a Numeric Range Filter. The first reply metric in this recipe is already adjusted for hours instead of minutes, so you don't need to take any extra steps. 

    Make sure you keep the combined numeric range filter from the recipe at the top of the filter list. Then add a new numeric range filter like this:

    • For the Attribute, choose Ticket Id
    • For the Metric, choose First Reply Time by Event (hrs) [Avg]
    • For the Range, choose Less than or equal to 50

    The results would look something like this:

    You can also set the filter to "Greater than 50" to only see those outliers. That would allow you to review those high handle time tickets on their own.

    I hope this helps. Happy reporting!

  • Avatar
    Ryan

    The bar chart showing Updater and First Reply by Event is great! The only other bit of information that would help in my situation would be to see how many first replies each agent had, alongside their First Reply Time average. Is it possible to create another metric to show this, and then overlay on the same chart?

  • Avatar
    Amy Dee

    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!

  • Avatar
    Ryan

    Thanks Amy. That's exactly what I needed! 

  • Avatar
    Jeff S. (Edited )

    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!

  • Avatar
    Amy Dee (Edited )

    Hi Jeff! This particular metric is looking at the properties of a specific ticket update. The Ticket Requester Domain attribute is associated with the ticket as a whole, not any given update, so it may not be connecting properly here. Also, I wouldn't recommend making changes within these metrics, since they have a lot of moving parts.

    There is an easier way to filter for agent-created tickets. Check out this recipe article: Ticket Creation Events. That recipe allows you to report on ticket creation as an update. From there, you could user the Updater Role attribute to find tickets that were created by agents or administrators. 

    If you just want to filter the report, you could create a filtering metric like this:

    • SELECT IFNULL((SELECT (SELECT Ticket Creation Events WHERE Updater Role IN (AgentAdmin)) BY Ticket Id ALL OTHER WITHOUT PF),0)

    This counts tickets where the ticket creation was performed by an agent/admin. If the ticket was not created by an agent/admin, it counts a 0 instead of a null. (The "BY Ticket Id ALL OTHER" portion ensures that the filter applies equally to the whole ticket, since the core metric only looks at one update.)

    You don't need to display that metric under WHAT. Instead, you can use it in a Numeric Range Filter on your first reply report:

    For the Attribute, choose Ticket Id
    For the Metric, choose the Tickets created by agents metric above
    For the Range, you have two options:
       "Is equal to 0" means you will only see tickets that were NOT created by agents
       "is equal to 1" means you will only see tickets that WERE created by agents

    I hope this helps! Happy reporting!

  • Avatar
    Jeff S.

    Hi Amy,

    Thanks so much for the quick response. Your note about updater domain referring to the whole ticket makes a ton of sense. 

    I've gone and created a Ticket Creation Events metric and am attempting to create the filtered metric like you wrote but I'm getting an error. Here's what I've entered and the error I'm receiving: 

    Any ideas?

    Thanks!

  • Avatar
    Amy Dee

    Hi Jeff! It looks like I missed a parenthesis before. Sorry about that!

    There should be two open parentheses after IFNULL -- SELECT INFULL((SELECT (SELECT Ticket Creation Events...

    Give that a try instead. The metric editor should be happier.

  • Avatar
    Jeff S.

    That did it -- thanks again Amy!

  • Avatar
    Matthew Heflin

    Does this work with Median instead of Average?

  • Avatar
    James Sanford

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

  • Avatar
    Chris Stroud

    Hi Amy,

    Thank you so much for this.Very helpful. 

    How would I filter out tickets by tag? For example, when a chat is ended it creates a ticket. Right now, those are being included and I want to filter them out.

    Thanks!

  • Avatar
    Amy Dee

    Hi Chris! Tags are tricky in Insights, because one ticket may have any number of tags at the same time. To manage that, tag data is stored in a separate dataset. You need to take special steps to use tags in reports.

    We have an article that covers those steps here: Reporting on ticket tags. Basically, you'll need to create a metric to identify tickets with/without a particular tag, then use that metric for your filters.

    If you want to use tags with this recipe, you'll need to use a Numeric Range Filter on the report as a whole. Tag data is not connected with event data, so it would clash if you tried to nest it in this recipe's metrics.

    I hope this helps! Happy reporting!

  • Avatar
    Nicole Relyea

    @Chris Let us know if you have any further questions. Also, I see that this was your first post. Welcome to the Zendesk Community!

Please sign in to leave a comment.

Powered by Zendesk