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

How do you add SLA Metrics such as Compliance, Average Duration, Percentages, and Hours of Operation Calculations to Dashboards?

With skill and finesse!

They said it can’t be done with Dashboards. But they are WRONG…. So Wrong!

• Yes, you can add Hours of Operation Calculations to dashboards!
• Yes, you can add averages to dashboards!
• Yes, you can add aged groups to dashboards!
• Yes, you can add percentages to dashboards!
• Yes, you can display data from multiple business objects on one dashboard!

That’s right. DASHBOARDS. Not Reports, not Xtraction, not Power BI, not some other non-native Ivanti Add-On.

SLA Compliance Dashboard

Resolution Timeframes Dashboard Part

SLA Compliance Pivot with Percentage Dashboard Part

Why dashboards and not reports?

• Reports are ugly outdated third-party with many limitations and no development effort committed to by Ivanti. In fact in 2017 Rapid Reports was introduced for native reporting to replace Reports. Dashboards are sexy and here to stay!
  
• Reports are not native, meaning you can not drill-down to the record in Ivanti Service Manager (HEAT). With Dashboards you can!
  
• Reports are OK for distribution. If you’re stuck in the 90s!! In today’s shift-left world, the focus is on enabling the Analyst, Manager, Executive with meaningful, timely (LIVE), interactive information in an easy to use simple intuitive interface. With Dashboards you get LIVE interactive meaningful well presented statistics!

With dashboards you can add Hours of Operation Calculations, averages, aged groups, and data from multiple business objects (Incident AND Service Request for example) and much much more.

Are you getting the most out of your Ivanti Reporting?
You are not! Not until you talk to us!

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!

Email, productivity tool or time-waster?

Email was a great productivity tool, back in the 1990s! In the HEAT Classic Days.

Nowadays managing your inbox can be a full time job, and those notifications that you thought were great at scope of work or solution design workshops, quickly become annoying, forgotten, and filtered to some folder you’re quite frankly just going to purge when your mail account runs out of storage space.

Notifications are good but Dashboards, Targeted Emails, and Email Summaries are better.

Here are some quick tips and a19 Best Practices to reclaim your email inbox and use email as it was intended to, as a communication tool. Effective communication that is!

• Limit Escalation Notifications to P1 and P2 only on Breach. For everything else use dashboards or the a19 SLA Status Indicator.
• Limit Team/Individual Assignment Email Notifications to P1 and P2 only.
• Limit Customer Emails to Incident/Service Request Creation, Update, and Closure Only.
• Phase-out incoming email where possible and encourage the use of Self Service. My clients have found a 50% drop of support calls and emails with the a19 Self Service Implementation along with an increase in efficiency by streamlining underlining workflows.
• Use Dashboards to review important metrics such as Items requiring attention, whether Incidents, Service Requests, Tasks, and so on.
• Use Email Summaries for situations where Ivanti ISM (HEAT) Users are not able to check their Dashboard Daily. Summaries can be created to show the same metrics as dashboards, on a schedule (every morning, after lunch, and so on) for example, all Tasks assigned requiring acceptance or resolution, overdue tasks, Incidents requiring an update/action, and so on.
• Use a central email notification template. Managing the OOTB email notifications can be time consuming, often requiring a “simple” change in many business rules, quick actions, and workflows. Use a19’s Central Email Notification template instead.
• Keep Email Details Simple. There is a tendency to include as many details as possible within an email.  That was a great strategy back at the turn of the century when you only received a handful of emails, but in today’s fast paced world, there are likely going to be many email updates, and those can turn out to be counter productive and confusing as individuals read, act, and reply to emails that are long outdated.   The better approach is to have only essential details in an email message with a link to the current details in the system.  
• Automate system generated notifications, for example, security certificates expiring, low disk space, outages, to automatically generate service requests in your system and auto-assign the appropriate teams and individuals.

Email was great back in the day. It’s time to face the news and re-evaluate when and how to use Ivanti ISM (HEAT) email notifications to communicate more efficiently and implement the latest best practices.

Email: Productivity Tool or Time-Waster? – Independent ITSM Podcast covering Ivanti Service Manager ISM HEAT Latest Solutions & Best Practices

This podcast is based on the Ivanti HEAT ISM Blog Post of the same title.  Do you have an Ivanti Podcast Topic or Question?  Submit it at podcast.a19consulting.com

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.