Weird SLA Violation

Please see the attached.  Can you explain why the SLA was violated on this ticket?  Is it because on 2/3/2022 the state transitioned from "On Hold" to "Closed" without going through "In Process"?

Thanks, Tevis

Asked by Tevis Boulware on Fri 2/4/22 11:38 AM Last edited Fri 2/4/22 3:58 PM
Sign In to leave feedback or contribute an answer

Answer (1)

This answer has been marked as the accepted answer
Mark Sayers Fri 2/4/22 11:45 AM

Hi Tevis,

I don't think I have all the details needed to make a determination on why that violated just yet. I'd need to see the full Feed of the ticket, and I'd also need to know what was the deadline on the Respond By portion of the SLA in question?

Sincerely,
Mark Sayers
Sr Support Consultant, CS

1 of 1 users found this helpful.
See the updated image that shows the feed. Six hour, Operational Time Respond by SLA

Mon 1/31/2022, 1:38 PM New Ticket. 1:38 PM, SLA Timer started
Mon 1/31/2022, 1:39 PM New to In Process. SLA timer should have been stopped
Tue 2/1/2022, 10:39 AM, In Process to On Hold SLA timers should still be stopped
Thu 2/3/2022, 4:20 PM On Hold To Closed, SLA Timer should not have started, SLA should be satisfied
Thu 2/3/2002, 4:23 PM SLA Violated

From my understanding, and logically, there should have been only a single minute from the SLA clock.
- Tevis Boulware Fri 2/4/22 3:58 PM
Hello Tevis, the SLA timer continues to count the Respond By timeframe until or unless the ticket is placed On Hold at some point (which *does* pause the timer and extends the deadline of the Respond By piece of the SLA).

From my math, the ticket spent 3 hrs and 22 minutes on 1/31/22 in a New or In Process status class (SLA timer still is counting down to its deadline before evaluating). Then on 2/1, the ticket spent a further 2 hours and 39 minutes still In Process before being moved to On Hold. At that point, a total of 6 hours and 1 minute has been spent in an Open/In Process status with an active SLA counter, and the processor for evaluating SLAs has a +/- 5 minute window and must not have evaluated this ticket as having "met" its Respond By yet.

(cont'd in next post due to character limitations).
- Mark Sayers Fri 2/4/22 4:24 PM
When the ticket dropped back off of hold on 2/3, it would have updated the Respond By value on the ticket to match the latest time/date the ticket dropped into an Open/In Process/Resolved status class, which would be 2/3/22 at 4:20 PM.

At that point the processor would have evaluated the ticket on its very next sweep, and would have seen that a total of 6 hours and 1 minute of the SLA's timer had elapsed while the ticket was New/In Process and the date/time of the Respond By on the ticket are values that are later than the ticket's Respond By deadline and it would violate the Respond By piece of the SLA.
- Mark Sayers Fri 2/4/22 4:29 PM
Mark, this doesn't make sense. The definition of a Respond by SLA, per TDX KB, is:

"Respond By is the agreed to time limit, in hours, for communicating with the requestor, confirming the ticket has been received, and setting expectations."

Then in response to a question you stated:

"An SLA Respond By is satisfied by the status of the Ticket changing. You can either Update or Edit the ticket to change the status."

I read that as soon as an update to a ticket that moves the ticket into an "In Process" state, a response by SLA should be satisfied.

I have to admit, the rules for the SLA are convoluted and make little sense to the Service Managers, to such a point they are thinking of not using them.

I have submitted enhancement requests to update the SLA business rules but have not heard anything about any plans to change or clarify the SLA business rules. To date, the SLA business rules are the weakest part of TeamDynamix.
- Tevis Boulware Fri 2/4/22 4:36 PM