In this article, you'll learn more about some of the metrics built into Zendesk Support that help you measure the duration between two events.
Note: This article covers only the native Support metrics. SLA metrics might have identical names but their behavior is different because they are live counters. See: Defining and using SLA policies.
For more information about the metrics and attributes you can use with Explore, see Understanding Explore datasets.
The native duration metrics are not live counters, instead, they measure time duration between specific events. Support computes the time difference between two event timestamps and adds the results with the following behaviors:
- The new metric value is recorded on the ticket only after the specific events take place.
- The metric’s value will appear as null until two required events occur at least once.
This article contains the following topics:
- First reply time
- First resolution time
- Full resolution time
- Requester wait time
- Agent wait time
- On-hold time
Tip: In the graphics below, green indicates time counted and gray indicates time not counted.
First reply time
- Definition: The duration between ticket creation and the first public agent reply on the ticket.
- First timestamp: Ticket creation.
- Second timestamp: The first public comment by any agent.
- Exceptions: If the ticket is created by an agent and the first comment is public the second timestamp shifts to the second public agent comment. If the ticket is created via private sharing agreement, the first private note by any agent will be considered as the second timestamp. For more details see: Calculating first reply time
First resolution time
- Definition: Duration between ticket creation and its first resolution.
- First timestamp: Ticket creation.
- Second timestamp: The first time the ticket status is set to solved.
- Exceptions: If the unsolved ticket is set to closed by a business rule or API, this event is considered as the second timestamp.
Full resolution time
- Definition: Duration between ticket creation and its most recent resolution.
- First timestamp: Ticket creation.
- Second timestamp: The last time the ticket status was set to solved.
- Exceptions: If the unsolved ticket is set to closed by a business rule or API, this event is considered as the second timestamp.
Requester wait time
- Definition: The total combined time ticket was in the new, open, and on-hold statuses.
- First timestamp: Ticket status is changed to new, open, or on-hold.
- Second timestamp: Ticket status is changed from new, open, or on-hold to any other status.
Agent wait time
- Definition: The total combined time the ticket was in the pending status.
- First timestamp: Ticket status is changed to pending.
- Second timestamp: Ticket status is changed from pending to any other status.
On-hold time
- Definition: The total combined time the ticket was in the on-hold status.
- First timestamp: Ticket status is changed to on-hold.
- Second timestamp: Ticket status is changed from on-hold to any other status.
15 Comments
Hello,
Is there a way I can get the duration in business hours between 2 status changes directly from Zendesk reports please?
Example: Audit log-
New to Pending - 2021-01-06 T16:42:33
Pending to Open - 2021-01-08 T03:30:07
Open to Solved - 2021-01-08 T17:39:37
I basically want to get the duration the ticket was sitting in 'Open' status. So basically the difference of time b/w 2021-01-08 T17:39:37 & 2021-01-08 T03:30:07.
If I need to do the calculation in excel, the data should be sorted and then getting duration in business hours (excluding weekends, holidays etc) in another complication to handle.
Can you help me figure this out please?
Thank you!
Kaushik Chanda.
Hi Kaushik,
You could use the default metric Open status time to get the duration a ticket is in the Open status, but unfortunately this don't come with a business hours calculation. Business hours metrics are only available in Support: Tickets dataset and not available in Support: Ticket updates dataset(where the said metric is in).
Best,
Hello,
Knowing that the requester wait time is only updated when status changes (This number is only measured after a ticket status is changed from New/Open/On-hold/Pending/Solved/Closed), how can I know the requester wait time updated with the current date/time if the status does not change in the meantime?
Thanks.
Hey @...
Thanks for this question! Note that the Requester Wait Time is generally speaking something you would want to measure once the ticket's live cycle is completed.
So for example on Tickets that have been solved/closed. Even if the ticket did only change from New status to Closed status directly, this will give you a value for the Requester Wait Time.
If you are looking specifically to report on the times a ticket spent in a Status, this could be done following a recipe like this one: Reporting on the duration of fields
You can potentially use a custom attribute in the Ticket Updates Dataset, to create a time stamp for when the ticket changed to a specific status and then use a custom metric to measure the time between that time stamp and today. But this is not related to the Requester Wait Time but is simply a way of calculating a time spent in a current status.
Here is an example to measure the time your ticket spend in the New Status, if they did not change the status yet:
Create the Timestamp Attribute: (let's call this "New Timestamp")
Use this Timestamp Attribute now in a custom Metric:
I'm afraid there isn't a direct native way to measure the requester wait time for tickets that do not change the status, as this is not really what it would be used for. But I hope the workarounds supplied might be helpful to you!
I so love this article. This is extremely useful for us in upholding our SLA commitments to our customers.
I have a slightly tricky question. I compute our metrics based on the count of tickets that meet our RWT and FRT SLA. But in RWT, is there a way for me to count the tickets that meet a certain SLA but will not include On-Hold time? Although we don't expect our teams to mark tickets as On-Hold, I plan to use that Ticket Status for customers whose requests need to be referred to third-party contractors whose SLA's are beyond our control. I would also have a separate metric for that On-Hold Time. We initially inform our customers that we are closing the tickets since their requests are not feasible at the moment but they wanted to keep them open until they get feedback (which can take forever). Thanks.
Hi Jared,
There are metrics for On-hold time under the Tickets, Ticket updates and SLA datasets. So, you should be able to calculate for the requester wait time minus the on-hold status time via a standard calculated metric or through a result metric calculation. You can then build your report around that metric, or create custom attributes to classify tickets based on different brackets/values of the custom requester wait time calculation.
Thanks.
Another question. I created an SLA for First Response Time (2 hours for Urgent and High Priority Tickets and 24 hours for Normal and Low priority tickets). Ticket priority is determined by the macro used for that ticket. I then created a report in Explore to show which tickets Breached and which Tikcets achieved the SLA Targets. I did this by using Ticket ID in the Row Section and Ticket SLA Target count of Achieved and count of Breached in the Metrics section (In a table format). I noticed that in some of the ticket IDs, it showed that the SLA was breached twice (marked 2 under. How is this possible? Thanks.
Hi Jared,
Is your query filtered by SLA policy and target metric? If the rows in the query are not specific to a single target metric and SLA policy, then it may display all the breached and/or achieved SLA events for one ticket ID/row.
Gab Guinto
Technical Support Engineer | Zendesk | APAC
Really appreciate the responses. I have a few more questions.
Adding a few more details from my previous query:
1. I only used one policy In the row section. I currently have 2 policies: 1 for First response time / FRT (1 hour for Urgent and High Prio and 12 hours for the rest) and 1 for Requester Wait Time / RWT (2 hours for Urgent and High prior, and 24 hours for the rest). Wish I can share my screens or do this in chat.
2. I have data filters for the timeframe and a data filter for the Assigneed.
3. I created 4 queries: FRt for Urgent/High, FRT for other prior, RWT for URgent /High, and RWT for other prios.
3. In each query, my metrics are D-count for Achieved SLA Metrics and D_Count for Breached SLA MEtrics For the Row, I set SLA policy (1 policy only in each query). My filters isolated the prior and Assignee name.
Questions:
1. Shouldn't the total counts of tickets be the same?
2. If an Agent marks a ticket as solved and the customer responds again reopening the ticket, and Agent responds again solving the ticket (again), will this cause the double counts in their FRT and RWT metrics? I think it is the case for RWT but for FRT? How do I make the report count the tickets only as 1 for Achieved OR 1 only for Breached?
Hi Jared,
It looks like I need to investigate further on this. I've created a request on your behalf so that we can continue our conversation over the ticket. Thanks!
Gab Guinto
Technical Support Engineer | Zendesk | APAC
Thanks, Gab.
Is there any way to exclude the time gap in the full resolution time from Solved to Re-open
Example: If a ticket got created on Day 1 and solved on Day 1 and again the same ticket got re-opened on Day 3 and solved on day 3 . The full resolution time metric is calculating the time from day 1 to Day 3.
I want to exclude the time gap from Solved to re-open. Is there any way?
Hi Sajid,
I think this is possible, though it will be highly customized, by combining DATE_FIRST_FIX and DATE_DIFF
I think you'll have to create a couple of custom attributes for this, using Ticket Updates dataset. First, we'll have to get the timestamp of when the ticket was reopened. This can be done by creating a formula based on the Changes value (like the one in this recipe - Explore recipe: Reporting on the duration of fields, except we'll be returning Update - timestamp)
Next, we'll have to create a new calculated attribute to identify when the ticket was reopened. It'll be pretty similar to the one above, except instead of returning Update - timestamp we'll only return True. This will help us identify the timestamp of when the ticket was reopened.
The third attribute that needs to be created would be to get the timestamp of the first reply after the ticket was reopened. We'll have to use DATE_FIRST_FIX here, and an IF clause to make sure that Comment present, Comment public, and Reopen (the one we previously created) are all set True.
Lastly, using DATE_DIFF, get the difference between when the ticket was reopened and when the first reply to the ticket was (first and third attribute here). We can then use that and subtract it from the Full Resolution Time to get the Full Resolution time minus the extra time when the ticket was first Reopened.
Hello Giuseppe,
Thank you for your response. I have the same question for the full resolution time. In a business sense, we need this metric to know how long does it take to solve a ticket. However, if we include the duration from solved to reopened, it creates a bias. Since customer can reopen a ticket at any time for instance 15 days later. And including that time into resolution time does not seem to be fair and reflect the true story. I understand from your explanation that there is a way to customize the metric, which looks rather complicated. Thus, wouldn't it be possible to change the way Full Resolution Time is calculated? To exclude the duration from solved to reopened. If you do not think this is appropriate, would you please provide me explanation of what is the business sense behind it? Thank you.
Thanks for your response. I completely understand where you're coming from. I am not part of the dev team thus I would not have insight on the thinking behind it. However, my first hunch would be that a reopened ticket was not solved in the first place. More so that agents can basically just solve a ticket whenever they want, a ticket being reopened means that the issue was not resolved, or at least not fully resolved. There's definitely some pros and cons here, and simply changing how full resolution time is not really an option that we have right away, thus the custom metric that Giuseppe recommended.
However, as mentioned I do see your point here. It would be great if you can post this as a feedback as well for our product team to see. Posts that get a lot of traction via comments and upvotes are reviewed by our product team for possible future improvements. https://support.zendesk.com/hc/en-us/community/topics/1260801325369--Feedback-Ticketing-System-Support-
Hope this helps! Cheers!
Please sign in to leave a comment.