Primary Responsibility at time of Respond by SLA Violation

Greetings.

I'm trying to determine who is Responsible for tickets when an SLA becomes violated. 

If I use Primary Responsibility and Respond By Violated it will tell me if an Respond SLA Violation happened and who is the most recent person responsible for it. I want to know who (if anyone) had Responsibility when the SLA Violation occured. Bonus points if I can find out how long they had been Responsible for the Ticket.

Also can you tell me the differnce between Create to Initial Respond and Create to Respond is? And what units Create to Respond uses?

Is there a way to do this that I'm not seeing?

Tags sla primary-responsibility created-to-respond violation
Asked by Richard Linscott on Fri 10/18/24 3:28 PM
Sign In to leave feedback or contribute an answer

Answer (1)

This answer has been marked as the accepted answer
Mark Sayers Fri 10/18/24 3:55 PM

Hello Richard,

Unfortunately there isn't a good way currently to report on who was responsible for a ticket at a given point in time (the point at which an SLA violated), nor can you report on how long a given person/group was responsible for a ticket.

As for the difference between Create to Initial Respond and Create to Respond:

  1. Create to Initial Respond = the amount of time that has passed (in either absolute hours or in terms of your operational hours for your ticketing app) from the creation of the ticket to the time that it was first ever marked into a status class higher than the status the ticket was *created* with.
  2. Create to Respond = the amount of time that has passed (in either absolute hours or in terms of your operational hours for your ticketing app) from the creation of the ticket to the time that the ticket was *most recently* moved into a status that is in a higher status classification than the one the ticket was created with.

Both of these metrics will display time in terms of hours, where Absolute Hours is just a count of the total time passed and Operational Hours is a count of the days and hours (on a 24 hr day scale) passed since creation of the ticket. So let's say you have your ticketing application's operational hours set to span for 8 hours of the day Mon-Fri. If a ticket was created on Monday, moved in and out of an Hold status a few times where it last dropped off hold at the end of the day on Wednesday, that would span (Operationally) 3 days, but the metric would list it in terms of the addition of 8 hr increments until 24 hours is reached. So because those 3 days of 8 hours operational time equals 24 hours, it would list it as 1 day of operational hours (equivalent to 24 hours total operational time). I know that can be hard to follow potentially, but I hope it was clear enough with the example I used.

Sincerely,
Mark Sayers
Sr Support Consultant, CS

1 of 1 users found this helpful.
Both answers given by Mark are comprehensive and completely answer my questions. Thank you. - Richard Linscott Fri 10/18/24 4:04 PM