Best way to SLA set up for multiple Incident assignment

Nisha30 · ‎08-20-2024

Hello Experts,

Need some guidance how best to set up SLA for Incidents. I know it is customer specific what the business need but our customer needs assistance .

The goal would be ultimately to have reports - met SLA or not (actually which vendor was responsible for breach in conditions when an incident already breached and was reassigned to another group etc.)

-Is it best to have Incident TASK for multiple groups ?

-or best to have at Incident level? since in task_sla table we can see the SLA against each groups may be multiple times when ticket hops from one group to another.

I mean what the best ServiceNow practice to have them set up. Anyone might have implemented can guide please how did they managed.

Thanks

Mark Manders · ‎08-20-2024

I have seen both. But it's good to realize that you aren't asking about 'how to set up SLA'. You are asking about how to set up reporting related to SLA.

An SLA is an agreement. It's a signed document which states the time within an incident should be resolved. So no matter what: you will need an SLA definition with a start, pause and stop condition that is in that agreement. Probably based on priority.

You client doesn't just want to know if the SLA was made or not, they want to know who was responsible for breaching. Metric definitions are great for measuring how long a task was assigned to a group, but unfortunately, they don't have pause conditions, so for your reporting requirement, that doesn't work.

One note: make sure the SLA with the vendor has a shorter duration than the SLA the company has with the customer, because otherwise you will never make that.

You can create SLA definitions per solution group (assignment group/vendor). Do realize that there often are SLAs with vendors, but almost never with internal assignment groups. It's not that a 3 day P4 SLA has 1 day for group A and 1 day for group B.

Look at the current process. Do they already use tasks? If so: create SLA definitions per group on incident_task level. If not, collaborate with your client if they see an upside into introducing a completely new way of working (+ integrations?) just for their reporting questions. I think they won't. In that case: create an SLA definition per group/vendor on the incident table, with start condition 'assignment group is group/vendor' and pause condition when it's not (changed to other group).
You will have multiple sla records on your incident, but you only need to report to your client on the over all one (make sure you use good distinction between the SLA's by using type/target fields).

Related to your question: is it best to have task per group, I have to say 'yes', but not if it's just for SLA reporting. Tasks are a great way to have one group keep the overall overview of the incident, while others are working on it. But it does take a big change in organizations if they aren't doing this yet.

On the SLA dashboard you can create tab (or a completely new dashboard) with a report on breached resolve SLA breached for incidents (the over all ones) and next to that a bar chart with an interactive filter where an incident can be filled in. The bar chart can show the business elapsed time on that incident per SLA Definition, showing which definition took the most time.

You could also create database views between the metric instance table, incident table, and task_sla table to give you more reporting possibilities. When you are using incident_tasks, the reporting requirements need to be reviewed with the client to see what exactly they need, because it would be results from task_sla records from two different tables.

I don't recommend it, because it's not reportable, but at one client we created an 'SLA summary' field on the form. On closing of an incident, a flow ran to get all 'completed' task_sla records for that ticket and listed it in that string field, including business elapsed time and the percentage per SLA definition. It also added priority changes, reassignment count and some more things they thought were good to have when creating SLA reports for the clients (manual created powerpoints). That field would show the delivery manager the information needed to explain what happened.

Assuming your client isn't yet using incident_tasks: if it were me, I would go with 'everything on incident level', just because it makes it easier to report.

Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark

View solution in original post

Mark Manders · 4 weeks ago

@Nikolina It's always best to create your own question on the community when it's not exactly the same as the question you are responding to. Especially when this question was created over a year ago and also has an accepted solution. Even if your question is going to be answered, it isn't (fully) related to the question this post was about and won't be found when somebody is looking to resolve the same issue you are having now.

Next to that: you mention KB0851951 and that article is nowhere to be found. Where did you find a reference to it, because it's also not mentioned in this post before.

Please share your configurations (preferably in a new post, not as a reply) and check on the triggers of the SLA records. Also validate that the commitments and offerings are associated correctly (check sysid's to make sure there aren't duplicates, causing you to think it's correct).
You also say '...this is how it works.' Is that a documented fact or an assumption? If it's the latter, please elaborate.
Are those results really breached? What is their stage? What is set on 'has breached'?
Did you log this with NowSupport as well?

Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark