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.
12 Comments
Dear Zendesk Support Crew,
Thank you for the article! Quiet helpful!
I'm still looking for a metric in which I can see the average resolution time from the moment it was opened until it was solved & first replied to. Reason is that for a few tags I'm trying to find out how much time we spend on a ticket from the moment we pick it up (opened) until we either reply (1st resolution) or solve it.
Could you help me out on how I can create such a report:
- Based on 2 ticket tags
- Average Handling Time, open -> closed (both for 1st resolution and for solved)
Looking forward to your reply!
Thank,
Cor
hello how are you?
I am also interested in obtaining the times between the states of the tickets.
I hope soon the zendesk support team can help us
To create a report that would show how much time a ticket spent per status, then you will have to create a custom metric for this. Unfortunately, creating custom metrics is beyond our scope of support. But I have attached this documentations that can help you create custom metric:
https://support.zendesk.com/hc/en-us/articles/206544348-Insights-metrics-reference-Professional-and-Enterprise-
https://support.zendesk.com/hc/en-us/articles/222794107-Creating-custom-metrics-in-Insights
For the first reply time you can create a metric like the following
SELECT AVG (First reply time in minutes within business hours/60/XX)
XX is the business hours you provide support in a day...
This will report the time in DAYS. If you want that in HOURS just remove the XX part
Same for the Full Resolution Time. Just use the fact related to that.
SELECT AVG (Full resolution time in minutes within business hours/60/XX)
Average handling time I think is the requester wait time.
Same as above, this time use the fact "Requester wait time in minutes within business hours"
There is also fact not related to business hours if you don't want to count your support schedule in.
That should be it
:)
Hey!
Can someone help me understand why my Requester Wait Time is always lower than my First Reply Time, if the RWT is also supposed to include the time the ticket was 'New'?
Thanks
Hi Joana,
As you know Requester wait time is a status-based metric but First reply time is not. Although time a ticket spends in the New status is normally sub-part of the First reply time, it is not always so. It all depends on the workflow. For example, there might be cases when a ticket is created in the solved status by agents or you have a number of tickets where the status wasn't changed from New yet.
I suggest creating a report that lists tickets and their Requester wait and First reply times, then you can look for the outlier tickets that have Requester wait lower than First reply time. Once you find them check how they were created and how their status had changed.
Example report:
This is one of my all-time favorite zendesk articles. It helps in terms of clarity with SLA definitions. I just wanted to point out a typo under the Full Resolution image. "First Resoltion" instead of First Resolution, I assume. I've copied and pasted these images to share with my Managers and various reporting users on our teams, which may be why I noticed.
Thanks!
Sam
Hello Sam Donovan,
So glad you like it! I'll be sure to pass this on to the article creator!
Best regards.
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 Sergio Pinho
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!
Please sign in to leave a comment.