Requirement to remove the pause duration of before sla to the current sla.

[Sharad_Mehra]

We have 3 SLAs running in Brit, requirement to configure all SLAs to start when condition matches and All SLA's starting should exclude pause time.

Eg. INC647466

1.SD SLA 1: INC P1-P4 Response 30M -> SD SLA 4: P2 INC Restoration 8H (tech assigned)->SLA paused->EUS SLA 16: P2 INC Restoration 8H->SLA paused->IR-02: INC P2 Restoration

Since 'IR-02: INC P2 Restoration' calculating from the start of the ticket, is it possible to calculate time excluding both pause times ticket been waiting for customer to respond.

[Mark Manders · Accepted solution]

Again: the requirement makes no sense. This has nothing to do with SLA management. It can be that the requirement is valid, but not from a Service Level Agreement point of view. This is not how it works, process wise. 

What is the requirement your requestor has? It seems like there is a real SLA and other stuff is being done for reporting purposes. If that's the case, fine, but it's not communicated like this.

Next to that: OOB, you can't do this, so you will be needing customizations on the SLA engine within ServiceNow, which isn't going to be easy to do. An SLA record runs on a schedule and measures the time it takes to get from a to b. You want to set that time based on other records.

[Sharad_Mehra]

Hi @Mark Manders ,

Thanks for your response.

We have 3 SLAs which are based on the groups.

1.SD SLA- when ticket is in the ServiceDesk queue.

2.EUS SLA-when ticket is in the EUS onsite queue.

3.General SLA- when ticket is not in the EUS onsite or ServiceDesk queue.

Pause -1.When tickets moves out of their respective groups and resume when comes back.

             2.if ticket moves to 'Awaiting customer' state.

For eg. if ticket is in ServiceDesk and technician puts the state to 'Waiting customer' for 2 days and SD SLA paused for 2days .Customer responds and Services desk triage the ticket based on requirement to another queue.

The requirement is when new SLA for EUS or General starts ,should exclude the time till ticket was in Pause state(2 Days).

Thanks

[Mark Manders]

I now understand what you are saying. But I doubt that your solution is the correct one.

Where does the ticket come in? Is that on the ServiceDesk, so that is always the first one to trigger?

An SLA is an agreed upon time that it may take to resolve a ticket. What you often see is that there is one 'over all' SLA agreed upon with the caller (no matter who resolves it, this P3 incidents needs to be resolved within 3 days). On top of that the first assignment group needs to validate as soon as possible what is needed for the resolving (mainly: who is going to resolve this) and with those groups have their own SLA's (or OLA's, depending on your setup). 

Example from my own experience when I was on a service desk a million years ago: a ticket came in and it needed to be resolved within 3 days. We picked it up and we saw that we needed a supplier to resolve it. That supplier had an SLA of 2 days on this, so we needed to make sure that within a day, the ticket got to the supplier, or we weren't able to resolve the ticket in time (as service desk we were responsible for the 'over all' SLA.

Back to your setup: you have an SLA for the ServiceDesk, an SLA for EUS and a General one for any other group. What I am missing is your agreement with the user (the 'over all' SLA).
Because, even if you would take away the 'awaiting information' from the servicedesk, you would still have your EUS group 'suffer' from any delays on the servicedesk group. If they have 3 days to resolve something and the servicedesk had it laying around for 2, waited a half a day, the EUS group would only have 1 day left.

If it were me, I would configure these SLA's to start on the first moment they get assigned to the group (ServiceDesk, EUS or 'not EUS and not ServiceDesk and not empty'). The pause conditions are then 'awaiting customer OR assignment group is not xyz' and restart when pause conditions are not met. And in the end the stop condition on 'active = false'.

That is the honest way of making sure the groups get the time they need for resolving it. And it is up to the assignment group itself to make sure the ticket gets assigned to the correct group as soon as possible, to prevent the 'over all' sla from breaching.

Does this sound logical? I can't see why the second group needs to work harder, because the first group didn't do their job. The time spend by the first group should not be part of the resolution time of the second (or third).

[Sharad_Mehra]

@Mark Manders 

Thanks for the response.

This is the business requirement to have 3 different Restoration SLAs for groups.

First group is ServiceDesk for responding to ticket and triaging to correct group, no pause condition for this.

We are having this requirement when 3 Restoration SLAs start.

Thanks I will try to convince business on this.

[Sharad_Mehra]

[Sharad_Mehra]

@Mark Manders @Dr Atul G- LNG 

All SLAs start at creation of ticket, I have retroactive start and pause configured on SLAs.

SD SLA 3: P1 INC Restoration 5H -was in pause for 1hr 2min when tech put state in waiting customer.

Response SLA took 22 min , SD SLA 3: P1 INC Restoration 5H took 1hr 42min (1hr 2min in pause)

Excluding pause duration of 1hr 2min we have active time 22min+40min= 62 min=1hr 2min

Requirement is when IR-01: INC P1 Restoration/2hr, attaches it should have (2hr-1hr 2min) 58 min left to action on ticket.

The business is considering whether it is feasible.

Thanks for checking.