On-hold and Breached Calls

[CraigP]

We've had a situation recently where a an Incident had a resolve by date for the 13/04. My colleague put the call on-hold on 6/04 due to needing further information from the customer who was on leave. The ticket was set to come off hold when they were due to return on the 12/04, but then still proceeded to breach at the original resolve by time on 13/04. My colleague was expecting the resolve by date to move along with the time it was put on-hold, but this didn't appear to be the case. Why was this? It seems to defeat the purpose otherwise.

With this in mind, can I please have clarification on exactly how the On-Hold status interacts with preventing breaches? I imagine it should at least stop it from breaching if it is on-hold when the request goes past its resolve by date, but does it then just breach automatically when it comes off hold? If it doesn't breach immediately then when will it breach after coming off hold?

[James Ainsworth]

Hi @CraigP

Thanks for your post.

When a request is placed on hold, the timers for the service level targets are also paused.  In the case of this particular ticket, the expected behaviour is if it was put on hold on 6/04 the timers should have stopped at this point, and then the new target recalculated when the request came off hold.  The amount of time that the request was on hold is added to the targets.

What I can't say is if other events may have occurred that changed the outcome of this.  For example, were the Friday and Monday on the long Easter weekend added as exclusion days to the Working Time Calendar?  

There are a few things to consider...

• Thursday 6th placed on hold - was it placed on hold after the end of the day based on the working time calendar (WTC)?
• Friday 7th Holiday - if set as an exclusion day this would have been considered in the original calculation for the target and it wouldn't have been used for extending the target while on hold.
• Monday 10th Holiday - if set as an exclusion day this would have been considered in the original calculation for the target and it wouldn't have been used for extending the target while on hold.
• Wed 12th Off Hold - what time of day did it come off hold?
• Thurs 13th Resolution Target - while the date may have been the same, did the target time change?

It is entirely possible that depending on when the request was put on hold and then taken off hold when compared to the working time calendar that there were not enough hours added to the calculation to push the new target into the next day.

[CraigP]

Hi James

Thanks for the information. I've now checked our Working Time Calendar and can confirm the Easter bank holidays are not specified on it. It is standard Monday - Friday 8am-6pm.

We've since tested with another one and it seems to have behaved in a similar way. It was due to breach on 17/04 at 11:38, so it was placed on hold at 09:46 on 17/04 (using an On Hold option that has "Pause Until Date/Time" ticked). It automatically came off hold on 21/04 at 09:46 and then proceeded to breach on 21/04 at 11:40.

Now I noticed there were those 2 minutes difference between original breach time and the new one. According to the timeline, a colleague placed it on hold using an indefinite on hold status, and then two minutes later it was then changed to the on hold status I mentioned above which requires a date to come off hold to be entered. So in my mind I was wondering if the timer only shifts for On Hold statuses set up in a specific way?

I tried to have a look at the Service Level Diagnostics for this IN, but not entirely sure if there is any useful information.

I did notice that there were 3 entries for System Timer creations, not sure why this may be, or if it is relevant?

 Thanks!