Resolution time medians do not match status time medians | Community
Skip to main content

Resolution time medians do not match status time medians

  • August 3, 2022
  • 1 reply
  • 0 views
James64

Hello, 

I'm currently looking into building queries to monitor ticket performance for my team, and I'm a little confused by some apparent disparities in query results. 

If you look at the two queries in dashboard below, one is set up to monitor response/resolution times, the second shows status times 


As you can see, there are significant differences in total times for resolution vs. total times for status, i'd have expected that status times added together would match resolution times given the ticket will have been in some kind of status until resolved. 

I've checked the queries and both of them are calculating by median, concern the same assignees, the same ticket group, and the same time period (7 days prior to today). These are the queries being used: 





Can anyone explain the differences I'm seeing please? 

      1 reply

      Alex89
      • Alex89
      • August 9, 2022
      Hey James,
       
      Thanks for sharing.
       
      A few difference I can think of for why the status times would not match up with resolution time.
       
      1. Not all tickets are resolved, this would result in a blank for resolution time but the ticket could still have status times calculated.
      2. There is not a solved status time so tickets that are reopened would have spent some time in a solved status which would be accounted for in the resolution time but not the status time.
      3. Edge case scenario - If you use the MED aggregator for your status times it will not necessarily pull in the complete status time for your tickets. For example, if you have a ticket with 3 separate pending status time values of 1, 2, and 3 minutes. Using the MED aggregator would give you a value of 2 minutes for pending status time while SUM would pull in 6 minutes.
       
      That is what I can think of right away and this would be comparing individual tickets against each other for a group of tickets like you have here it would be even more complicated to compare against each other. But essentially I would say that it is not accurate to try to compare these two values against each other.
       
      Best regards,
      Terms & ConditionsCookie settingsAccessibility statement