• Kaushik Chanda

  • February 16, 2021 14:47

  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.

• Michael Froeming

  • March 09, 2021 18:58

  Zendesk Customer Care

  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,

• Sérgio Pinho

  • May 05, 2021 13:18

  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.

• Matt

  • May 20, 2021 16:06

  Hey@...
  
  Thanks for this question! Note that the Requester Wait Time is generally speaking something you would want to measure一旦机票的生活周期完成。
  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
  
  您可以使用一个定制的属性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")

  IF ([Changes - Field name] = "status" AND [Changes - New value]= "new")
  THEN [Update - Timestamp]
  ENDIF

  
  Use this Timestamp Attribute now in a custom Metric:

  IF ([Ticket status]="New") THEN DATE_DIFF(TODAY(),[New Timestamp],"nb_of_hours") ENDIF

  
  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!

• Jared Vicencio

  • September 09, 2021 08:22

  我喜欢这篇文章。这是非常有用的or 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.

• Gab Guinto

  • September 11, 2021 05:01

  Zendesk Customer Care

  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 astandard calculated metricor through aresult 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.

• Jared Vicencio

  • September 13, 2021 07:46

  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.

• Gab Guinto

  • September 14, 2021 02:18

  Zendesk Customer Care

  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

• Jared Vicencio

  • September 16, 2021 12:31

  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?

• Gab Guinto

  • September 18, 2021 01:45

  Zendesk Customer Care

  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

• Jared Vicencio

  • September 24, 2021 17:16

  谢谢,空谈。

• Sajid Ali Shaik

  • January 18, 2022 10:28

  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?

• Giuseppe

  • January 20, 2022 15:18

  Zendesk Customer Care

  Hi Sajid,

  I think this is possible, though it will be highly customized, by combiningDATE_FIRST_FIXandDATE_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 theChangesvalue (like the one in this recipe -Explore recipe: Reporting on the duration of fields, except we'll be returningUpdate - 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 returningUpdate - timestamp我们将只返回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, andReopen(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.

• Zixuan

  • March 16, 2022 17:10

  HelloGiuseppe,

  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.

• Marco

  • March 30, 2022 12:12

  Zendesk Customer Care

  Hi Zixuan,
  
  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!
  
• Hana Tran

  • June 09, 2022 15:50

  Hello,

  Does the Requester wait time include non business hours?

  For example, client texted at 5.30am, out support opens at 6am and ticket changed to status pending at 6.05am. So in this case Requester wait time will be 35 min or 5 min?

• CJ Johnson

  • June 09, 2022 21:21
  • Edited

  Is there anyway to get the formula for:

  • Second timestamp: The first time theticket status is set to solved.
    
    

  I'd like to set up anattributethat returns the timestamp of the First Resolution time but I'm a little stymied on how to reference this.

• Dave Dyson

  • June 10, 2022 01:29

  Hey CJ -
  
  If you want the absolute time that a ticket was first solved, I think the best way to do this would be use the DATE_ADD() function, adding the time to first resolution to the time of ticket creation. Is that what you're asking?
  
  
  
• CJ Johnson

  • June 10, 2022 18:44

  Hi Dave,

  Thanks, can you explain how I would use DATE_ADD for this? It seems to want me to provide 2 attributes, one for the date and one for the modifier, but there are no attributes for First Resolution, only Metrics. That's why I'm asking about the second timestamp attribute.
  
  

• Jared Vicencio

  • June 30, 2022 15:06

  What is the formula I can use to compute the percentage of Solved tickets of a particular group/type, whose Requester Wait Time did not exceed say, 24 hours? Thanks for the help.

• Ronald

  • July 25, 2022 15:36
  • Edited

  How is it possible that my Average Full Resolution time for Q2 4/1/2022 - 6/30/2022 is MUCH higher than the Average Full Resolution time for those same groups during each individual month of Q2? Is there something mathematical that I'm overlooking here? I trust these numbers are correct I just don't understand how.

  I could understand if say the month of April had a high ticket volume and a high Average Full Resolution, that would skew the Average for the quarter higher.

  But each of April, May, and June all have a lower Average Full Resolution time than the Q2 metric. How can that happen?

  April - 46.4 hours
  May - 37.2 hours
  June 33.3 hours
  Q2 - 67.2 hours

  Update:After some additional investigation I discovered the above was being caused by the Time filter widget configuration. The time filter is being applied on "Ticket created" and "Ticket solved". So when I filter the tickets by each month individually it is calculating the Resolution Time for tickets created and solved during that month only. But when I created a report for April - June that is able to include tickets that were created in one month but then solved in the next. Which would certainly explain a higher resolution time.

  TLDR - When doing the quarterly calculation it includes tickets created in April and solved in May/June and tickets created in May and solved in June. But hose higher resolution time tickets arenotincluded in the calculation when doing April or May individually due to the time filter widget being applied on created and solved.

• Dane

  • July 12, 2022 06:17

  Zendesk Engineering

  Hi Ronald,

  I have created a ticket for you to further check this behavior. Please wait for my update via email.

• Ron Purdy

  • September 09, 2022 18:10

  Hi!

  My team frequently assist each other with our tickets. Is there a way to calculate the Average Requester Wait Time (Business Hours) by the agent making the reply instead of by the agent who is assigned when the ticket is solved?

• Dave Dyson

  • September 13, 2022 00:20

  Hi Ron, and welcome to the community!
  
  I don't think there's going to be any easy way to do this -- requester wait time is simply defined as the time a ticket spends in theNew,Open, andOn-holdstatuses. In the Tickets dataset, you can of course look at this by Ticket Assignee, but that's going to the the ticket's assignee at the time the report is run. For my money, I think requester wait time is a good metric to look at from an overall team perspective, or when breaking things down by customer or request time (and in any case, I'd use median instead of average, since median isn't heavily influenced by data outliers), but to measure agent responsiveness, I'd probably look at how many tickets they're solving, or how many public responses they're making per day (which can be found in the Agent Updates tab of the built-inZendesk Support dashboard.
  
  But it's possible someone else may have found a way to do this that I haven't thought of.
  
• Omar

  • September 22, 2022 16:33

  If a ticket comes into Zendesk, in Status NEW

  The agent assigns to themselves (their name) and then closes it as SOLVED

  The customer replies back, the ticket comes back, its NEW (or open, whichever status)

  When the ticket comes back in the NEW status, (after being solved) will it go against the agents metrics, because it is still under their name?

• Dave Dyson

  • September 23, 2022 00:15

  Hi Omar, first just to clarify:
  
  If a ticket is in Solved status when a customer replies, the status on that ticket will change to Open (seeAbout the inborn system ticket rules）.如果解决了蜱虫et does move to Closed ticket, then if the requester responds, a new ticket will be created with New status, and that new ticket will (as you said) be assigned to the same agent that the Closed ticket was assigned to (seeCreating a follow-up for a closed ticket）.
  
  If the Assignee is not changed on that followup ticket, then yes the metrics will be attributable to the assigned agent on the original ticket. But the assignee on the followup ticket can be changed at any time, in which case the metrics will be attributable to the new assignee.
  
  
  

• Omar

  • September 23, 2022 08:58

  @...

  I have business hours set on dashboard and widgets etc. e.g. requester wait time business hours

  We have shift patterns i.e. 8.30-5.30 and 12.30-9pm

  the agents change these shifts weekly. best way to account for the shift patterns and the agents who change them weekly would be? Can you set business hours in a way so it takes into account the shift pattern, and the changing shift pattern of that agent each week?

  (but essentially be the same dashboard)

• Omar

  • September 27, 2022 13:10

  @...

  just to be sure ive understood

  Agent A assigns themself a ticket

  closes ticket as solved (all metrics have gone to agent A since they assigned themselves)

  cust comes back 2 hours later with a reply

  The reply is still assigned to Agent A.

  The new ticket which is on status 'NEW'- metrics will go to agent A from when it arrived in the Zendesk inbox, so if its idle and not had a reply for 2 hours, that (2 hours wait time) metric will go to agent A

  Thanks

• Emily Sia

  • October 31, 2022 19:41

  有办法只看到完整的决议蒂姆e average for tickets created and solved on the same month? ie, resolution time for tickets created and solved in January, February, March, only, etc?

• Gab Guinto

  • November 02, 2022 08:11

  Zendesk Customer Care

  Hi Emily,
  
  You can create a custom attribute that checks the creation/solved month and year of tickets and then use that as filter in your report. Example:
  

  IF [Ticket created - Month]=[Ticket solved - Month] AND [Ticket created - Year]=[Ticket solved - Year] THEN "Include" ELSE "Exclude" ENDIF

  You can filter the report by this custom attribute; using the example above:
  
  With this filter, the report should only show tickets created and then solved within the same month & year.
  
  Hope this helps. Thanks Emily!
  

Pleasesign into leave a comment.