Changing SLAs

[kerr_jamese]

We just went live on a reimplementation a few weeks ago and we realized our SLA Definition are now what we really want. They are reporting off of Closed not Resolved. We would like them to be resolved for several reasons. One, because we don't allow anyone to change the state to Closed, except Admins. We want the customer to be the only ones to Close an incident, and they do that by approving the Resolution email that they receive. Two, we also have the auto-close set to 3 days. If there are no updates to that incident when in a resolved state it automatically closes the incident. This is messing with our SLA metrics/reports because the work is complete on Resolved but the incident could sit in a resolved state for 3 days because a lot of people just ignore those emails.

Our thought is to just change the definitions but we don't know what impact this will have on our instance, how long it will take, is it retroactive etc...

We will obviously test this before we do it but I wanted to reach out to the community for some advice.

Any advice would be appreciated.

James

[williamsun]

OK, what you want to do is add a "Pause condition" on the SLA so that the clock is stopped when the state is set to "Resolved", but the SLA does not close.   This will enable it to continue if the customer rejects the solution and it's placed back to work in progress.

Also, when you change it, it will affect any incidents that meet the Start conditions.   They will not be retroactive.

The change is actually quite transparent and should not affect anything.

[bgworld]

Hi James Kerr,

We also had the similar requirement.

We pause our SLA when incident is resolved, and stop the SLA when incident is completely closed.

This is important from the perspective that incident can be re-opened from resolved state if concerned user is not completely happy or incident is not fully resolved form user view point.

Hence SLA will be made active if state changes from resolved to open.

this is one of our SLA snapshot:

One important thing is SLA definitions are attached dynamically and are referenced in each task SLA instance. This means that any change you make will also reflect the new as well as existing incidents.

Our experience: we did update definition some times but communication was made to all users well before so user are not surprised. All incidents followed the new definitions from the time change was made.

Hope it helps!!!

[shaanoh]

One important thing is SLA definitions are attached dynamically and are referenced in each task SLA instance. This means that any change you make will also reflect the new as well as existing incidents.

This paragraph got me a bit confused. Are you saying if we change the SLA duration on SLA definition then it will be applied to the already opened ticket which is in progress/new? And how about the tickets that were closed earlier? will it updated too.. I feel it wont.

Would love to hear from the community while I test