SLA BREACH OPTIONS

ID NOBLE
Tera Expert

We're currently looking for some best options to document the breach of an SLA for a given incident. For example, if an incident has breached SLA, we want to know the reason for the SLA BREACH before that incident could be closed. Does ServiceNow currently have OOTB functionality that supports this, OR what can we do in alternative please?

1 ACCEPTED SOLUTION

Hi,

Exactly, it's a process question, rather than technical, but to your point, yes, you could create a solution where if a record is being set to resolved (closed happens out of box after 'x' number of days), and there was a breached resolution SLA definition associated to that record, then abort the save (via before business rule) IF...they haven't supplied an SLA Breach Reason, such as what you mentioned.

Out of box, there is no automatic solution for that. You'd have to review with your process manager, what you all want to capture. Do you want to supply a select box and on the "resolution information" tab, place it there and just have it full of selections? Or do you want it like a multi-text field where the technician needs to supply a reason?

It may not be a technical reason, right?

It could be a staffing issue? It could be a user error issue (where they didn't pause it appropriately)? It could be a vendor issue that you don't pause on and so that breached and it was an external entity issue?

Once you decide that and what you're wanting to resolve by reviewing these metrics, then you can set the technical plan in place to implement the solution. So for this, I'd recommend starting at the very end, then working backwards.

Please mark reply as Helpful/Correct, if applicable. Thanks!


Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

View solution in original post

5 REPLIES 5

Allen Andreas
Administrator
Administrator

Hi,

Can you give a bit more information because if an SLA breached, it was because you didn't satisfy the stop condition set within that specific SLA definition.

So that part is static and you'd know what that is.

If you're referring to that specific incident and the concept of time, which means they didn't do 'x' by 'y' time...then that is dynamic...and that story would be told through the incident itself (fields, comments, work-notes, etc.).

Please mark reply as Helpful/Correct, if applicable. Thanks!


Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

Thank you Allen. Just like you mentioned, If an SLA is breached it's an indication that the stop condition set within the specific SLA definition was not satisfied. However, what we want to do in this regard is that we want to have a record of WHY the specified stop condition set within that SLA definition was not satisfied. For example, maybe we can add a mandatory custom field called "SLA Breach Reason" whereby the incident would not be closed unless the reason that lead to that breach is provided.

Although my example above might not be the best or even possible, I just used that for more clarification. And according to them, there have been a lot of incidents whose SLA were breached and had been closed, but could not link the reason for such breach to anything other than what you've already mentioned that the set condition was not satisfied. Simply put, why is the SLA set condition not satisfied?

 

Thanks always.

Hi,

Exactly, it's a process question, rather than technical, but to your point, yes, you could create a solution where if a record is being set to resolved (closed happens out of box after 'x' number of days), and there was a breached resolution SLA definition associated to that record, then abort the save (via before business rule) IF...they haven't supplied an SLA Breach Reason, such as what you mentioned.

Out of box, there is no automatic solution for that. You'd have to review with your process manager, what you all want to capture. Do you want to supply a select box and on the "resolution information" tab, place it there and just have it full of selections? Or do you want it like a multi-text field where the technician needs to supply a reason?

It may not be a technical reason, right?

It could be a staffing issue? It could be a user error issue (where they didn't pause it appropriately)? It could be a vendor issue that you don't pause on and so that breached and it was an external entity issue?

Once you decide that and what you're wanting to resolve by reviewing these metrics, then you can set the technical plan in place to implement the solution. So for this, I'd recommend starting at the very end, then working backwards.

Please mark reply as Helpful/Correct, if applicable. Thanks!


Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

Thank you million times Allen.