breach All SLA's Breaching even when on hold?

[yelyah.nodrog]

Good evening,

Since one of the most recent updates, we have noticed that all of our calls where the priority has changed are breaching there origional priority even if on hold. Even calls assigned to priorities with no SLAs are now breaching.

We are getting Breach emails aswell as the calls actually breaching. This is going to be a serious problem for our stats.

The Below example is of a call that was logged as a R2 (with a SLA) but downgraded to a R99 (Outside SLA).

It was downgraded a day before it breached. However it appears it still ran on the R2 timer and breached anyway... We have had quite a few of these happen over the last week

Here is a snip of me downgrading the ticket to a R99 (a ticket ourside of SLA as it is a project)

Here is it breaching resolution the day after

and here is the breach email

So clearly they are not downgrading in the background?

Hayley.

 

[James Ainsworth]

Hi @yelyah.nodrog

It sounds like there may be a couple of different things going on here.  Requests on hold definitely shouldn't be breaching.

Regarding the down grading of a Service Level.  From your description and screen shot am I right in saying that you are changing the priority?  Changing the priority does not automatically apply the Service Level unless you have this set up in your BPM using the Service Level operation to re-assess your Service Levels.  At the moment you have to select the Service Level from the right hand side of the request and select the new service level.  You should see a screen a bit like this...

We do have a change that is in our development queue which will allow for some automation between the updating of a request and the updating of the service.

We will have to look into why your requests that are on hold are still breaching.  

Regards,

James

 

 

[yelyah.nodrog]

Thanks for this advice, would be nice if changing the priority would change the SLA, as otherwise there isnt really any point in changing the priority is there?

Keep me updated with the breraching problem... However this isnt the first time i have reported it.

 

Please see:

Thanks as always!

Hayley.

[Victor]

1 hour ago, yelyah.nodrog said:

would be nice if changing the priority would change the SLA, as otherwise there isnt really any point in changing the priority is there?

@yelyah.nodrog there is a change on our list that will address this. Besides this, there is apoint actually in changing the priority in the context of customers who do not use the SLM functionality.

Regarding the "Breach emails - continuing on hold" topic, for which we asked to raise a support request: on this support request we asked for some information but we never received a reply so we have close it back in April.

[yelyah.nodrog]

@Victor

Apologies if i missed that victor, i don't really come on here all the time, and the emails I get from yourselves magic into a folder i don't look at regularly enough clearly...

Here are some examples of SR and IN's where i know we have had the issues I will log another ticket for you, but can you please tell me if you need any particular information or if ticket number examples are enough?

SR00060593
IN00060473
IN00060388
SR00060390

Many thanks as always

Hayley.

 

 

 

[Victor]

1 minute ago, yelyah.nodrog said:

I get from yourselves magic into a folder i don't look at regularly enough clearly...

Gasp!!! 

I can log a support request on your behalf. To make sure I understand the issue, is that escalation email(s) are sent while the request is on hold and/or escalation email(s) are sent as soon as a request is on hold if the emails would have been reached their timer if the request would have not been on hold?

[yelyah.nodrog]

Yes please Victor, its not letting me raise one atm, and i guarantee that it's because we are having network problems atm....(atm meaning ALWAYS)

If we raise a call, and place it on hold, it appears that the SLA timer is still running in the background, it doesn't seem to register that its on hold and i believe the response or resolve timer continues to count down in the background. - However i don't think the calls are breaching, its just issuing out the relevant breach emails at the relevant times.

Hope that makes sense.

H

[Victor]

1 minute ago, yelyah.nodrog said:

However i don't think the calls are breaching, its just issuing out the relevant breach emails at the relevant times.

@yelyah.nodrog - yes, I remember it was not actually affecting the timer but only seem to be something wrong with escalation actions... I do remember discussing this with dev team at that time, that possibly the clock for escalation is ticking even if the request is on hold but the advised they checked this and it was working fine (i.e. escalation clock only ticks while request is off hold). I'll raise the support request and look at the examples you sent. Perhaps there is a scenario we are missing here...

[Victor]

@yelyah.nodrog - I have sent you an email from the support request raised to investigate this. From my investigation so far I believe the issue occurs if the request timers are started while the request is on hold and if it stays on hold... If the timer is started while the request is on hold then the timer clock (for escalations actions at least) will tick as if the request was off hold...