Understanding my SLAs Part III — Pause Times

iris_geist — Wed, 05 Jul 2023 22:49:43 GMT

In Understanding my SLAs Part I, we discussed where you can find the missing time in an SLA workflow. In Understanding my SLAs Part II, we went over the difference between actual and business elapsed times In Understanding my SLAs part III, we are going to talk about Pause Times and their relation to your schedule.

Some questions I tend to get are:

What does it do to my SLA when my overachiever colleague updates a ticket in the middle of the night and puts it into a pause state, then comes back in the middle of the day to take it out of the pause?
What if my vendor in India responds to my request in the middle of my night, taking the incident out of Pending Vendor state?
Will my SLA start counting again immediately, although I am fast asleep?
What if I enter a pause time outside my schedule, and exit it inside, or vice versa.
How is it calculated if my pause times are completely out of the schedule?

Since Aspen, the SLA property "Compute prior SLA pause time for new, retroactive SLAs (2011 SLA engine only)" is set to true and the pause times are calculated as defined when a retroactive SLA is attached.

Consistent Pause Times across all SLAs

I recommend defining all pause times the same between your SLAs. If Pending Vendor is a pause time in one SLA, it might be best to have the same in all, in case the SLA changes due to changing priorities. Typical pause times are waiting for a customer to respond, waiting for a vendor to fix an item, waiting for a problem/change etc. to be finished.

It is important to remember, that pause times will be counted only within the defined schedule. So, if my incident goes into pause time at 8pm, and goes out at 4 am, the pause is completely outside the 8am-5pm schedule and will be ignored in the business elapsed time calculation.

If the incident goes into pause at 6 am in the morning and goes out at 10 am, 2 hours will be counted in the elapsed business time calculation, and 2 hours will be ignored in the calculation while on the 8 — 5 schedule. If the ticket was opened, as in our example, on Friday evening at 20:49, goes into pause from 6 am to 10 am on Monday, and the ticket gets closed at 11 am on Monday, the business elapsed time would be just 1 hour, the time from 10 — 11 am.

Taking into consideration what we have learned in the previous blog posts..

The Task SLA is typically only updated, when its matching scheduled job has executed — and that calculation is done independently on the workflow that takes care of the notifications.
True SLA breach times are based on business hours defined in the schedule, not the 24x7 schedule represented in the actual elapsed times and percentages, but the out of box system shows the actual times and percentages rather than the business times and percentages that count.

Finally — it only counts as a pause if it happens during our working hours — totally, partially, or anything in-between.

I have attached an excel sheet with quite a few examples of SLA behaviors.

Re: Understanding my SLAs Part III — Pause Times

joseeduardo — Mon, 12 Oct 2015 05:10:47 GMT

thank you for all the SLAs serie! was pretty awesome! I learned about the pause times! I havent asked this question before: What about if they happen in night when my business time is not running!?, It is good to know now thank you!

Re: Understanding my SLAs Part III — Pause Times

BhupeshG — Wed, 06 Jun 2018 14:43:47 GMT

I have a question. During the Pause state , due to change in Criteria, a NEW SLA is attached and old is cancelled. Will the new SLA be breach or will it inherit the pending time from previous SLA?

Re: Understanding my SLAs Part III — Pause Times

Marcin Kroszel — Tue, 29 Oct 2019 10:42:43 GMT

Hi,

If the new SLA is attached, it means that the completely new calculation starts for it and the previous one is no longer considered valid (e.g. risk assessment was done improperly).

I can imagine your situation might happen if everything was done within one SLA condition where priority condition is not specified or you share the same resolution time for different priorities which shouldn't really take place.

As far as I know, a good practice is to have different SLAs for each priority while the conditions can still remain the same or very similar to each other.

post Understanding my SLAs Part III — Pause Times in ITSM blog

Understanding my SLAs Part III — Pause Times

Consistent Pause Times across all SLAs

Re: Understanding my SLAs Part III — Pause Times

Re: Understanding my SLAs Part III — Pause Times

Re: Understanding my SLAs Part III — Pause Times