Service Request SLA Clock. To Pause or not to Pause?

I have run into an interesting scenario and discussion with a Service Owner that insists that the SLA clock should Run when Waiting for Approval, more specifically waiting for the requester’s manager’s approval.

So in other words, a SR is submitted, waiting for approval, more specifically for the customer’s manager, and the clock is running for the service request, counting towards completion. If it takes the manager 5 days to approve, the time waiting is considered part of the Resolution Time / Compliance metric.

This is a first for me. The Service Desk Industry standard (norm) that I’ve always encountered is to pause the Service Request clock when Waiting for Approval, similar to how Waiting for Customer behaves, as typically any events outside of the Service Request owning team are paused, when the “wait” is for an external event/action, Versus an internal team action/approval/event with a “Waiting for Internal Team” status or similar status.

The argument made was that the Service Level Agreement Resolution Time and Contract with the End User, should be the total time from Submission to Completion, and using OLAs at the Task Level to measure the Team’s Resolution Time and Compliance.

What are your thoughts/experiences?

Here is what an Ivanti Business Partner had to say in the Ivanti Forums:

If it’s the customer’s manager i,e, someone external to the business then controlling the approval becomes harder and 2 weeks is a really long window for approval on a new mailbox. I would flag that for discussion with my customer to see if there are alternative ways to reduce the approval time. Also if it’s an external approval I would pause the clock as you can only measure and be targeted on the elements you control

Here is one of 6 SLA Best Practices from the BMC Blogs:

It’s just as important to define where an SLA does not apply as where it does apply. Your SLA should define any usual and unusual situations that will hinder or prevent IT service processing.

Some SLA exceptions might include:

• New users will be added to the system within one day of receipt of a completed new user form, provided management has approved adding the user. It will not be considered a service level miss if a new user request has been received but management is slow in approving the new user.

Advertisement

The SLA’s red headed step child

When it comes to Service Level Agreements (SLAs) there is one important configuration that’s overlooked or forgotten.

SLAs red headed step child – Independent ITSM Podcast covering Ivanti Service Manager ISM HEAT Latest Solutions & Best Practices

When it comes to Service Level Agreements (SLAs) there is one important configuration that's overlooked or forgotten. Holidays and Exceptions You've likely seen me post Holiday message on Instagram for the US, Canada, UK, Australia, Europe, Singapore, etc.  Make no mistake about it, Holidays are important.   Your SLA clock is likely ticking away when Incident, Service Request, and Task SLAs should be paused! It's somewhat of a straight forward process to configure SLA Holidays & Exceptions. There are two types of "Exception" configurations for your Hours of Operation (HOP) Calendar, aka Business Hours: Recurrent Manual Dates Continue reading at blog.a19consulting.com

Holidays and Exceptions

You’ve likely seen me post Holiday message on Instagram for the US, Canada, UK, Australia, Europe, Singapore, etc.. Make no mistake about it, Holidays are important. Your SLA clock is likely ticking away when Incident, Service Request, and Task SLAs should be paused!

It’s somewhat of a straight forward process to configure SLA Holidays & Exceptions.

There are two types of “Exception” configurations for your Hours of Operation (HOP) Calendar, aka Business Hours:

• Recurrent
• Manual Dates

Recurrent are pretty straight forward, for example every New Year’s Day, which is the 1st non-working day of January. That’s right, not the 1st of January, because that could fall on a weekend and then get pushed forward to Monday.

Manual Dates can be further grouped into two categories.

Recurrent Exceptions

For example, Fourth of July in America, Canada Day on July 1st, and all sorts of other country/state holidays have a set date that we can set up as recurring BUT there are exceptions for when these holidays either a) fall on a weekend or b) your company observes additional / substitute days.

Yearly Set Exceptions

Then there exceptions that occur yearly that do not have a set schedule or date. For example Easter Friday, Easter Monday, and in Australia the Queens Birthday is even observed in different months and days per region all together.

Manual Dates you will want to set for the next 5 or 10 years and then create a reminder or task to update these again!

Clear as mud right? Well wait, there is more. Some states/provinces/territories or even countries may observe holidays of their own. In which case you have to either come up with a “blended” calendar, use your company’s official HR calendar, or create custom hours of operation calendars for the states/provinces/territories or countries and use the customer’s location to drive the HOP used for SLAs. But that’s a topic for another day!

Waiting for Resolution Incident Status

A very frequently asked question when implementing Ivanti Service Manager (HEAT) evolves around the “Waiting for Resolution” Incident Status. What is its significance, should it be used, and how does it effect SLAs?

The “Waiting for Resolution” Status is typically used when a break/fix (Incident) has been completed but the ticket hasn’t been updated yet.

For example if there is a P1 Incident that has been resolved, setting the Status to “Waiting for Resolution” may prove to be rather useful to stop the SLA clock while gathering all incident resolution details from the SDAs and Task Owners, without getting penalized.

Remember that the SLA Clock is driven by the Incident Status and Waiting for Resolution pauses the SLA clock.