Best way to SLA set up for multiple Incident assignment

[Nisha30]

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 · Accepted solution]

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.

[Nisha30]

Hlelo @Mark Manders 

Wonderful explanation. Thanks for explaining yes it makes sense.

We dont use Inc_task yet so agree if we specifically define SLA based on vendor and other criteria  it would give us all SLA attached to an incident.

Just to end up for Resolution SLA, if an incident gets re-opened (changing from Resolved to Open/In progress)

the Time for SLA resolution should count excluding the time elapsed during 1st resolution. 

So example: if it is 1 hour Resolution SLA, and INC was resolved within 10 min, if this is re-opened, it should start counting next time for 50 min . Can we do it ???

Thanks

[Mark Manders]

Best practice: use a pause condition when an incident is set to 'resolved' so it can count on after it's reopened. Only when it's closed, the SLA should stop, because that's the time that the caller can't do anything anymore, but create a new incident and a new SLA will start (they have the days between resolve and close to respond if it's resolved or not).

Start condition over all SLA: on creation of the incident

Start condition on group/vendor SLAs: when incident is assigned to them

Pause conditions for all SLAs: awaiting caller/resolved

Additional pause conditions for group vendor SLAs: assignment is not theirs

Out of pause: when pause conditions are not met

Stop condition on all SLAs: incident is closed.