A question that I recently received was: “In my organization, there is a bad practice of escalating tickets for resolution that have already been breached, what is a better way to for us to manage SLA breaches? What about SLAs associated to tasks?”
To understand the question better we can break it into easier pieces. This user wants:
- To ensure that the ticket is resolved within the service level agreement (SLA) timeframe agreed to with the customer.
- Understand how to manage SLA breaches.
- Help with resolution to prevent breaches by assigning tasks to complete based on incident.
- This behavior happens all the time.
- That the escalation should occur before the breach of the SLA.
- Escalations and SLAs are related.
- Maybe assigning a task to the incident can help with resolution before SLA is breached.
SLAs and Breaches
When making SLAs there should be an understanding of organizational capabilities for service delivery and service support.
- Service delivery aspects should include: service capabilities (utility and warranty), price, delivery schedule, contact information, and the roles and responsibilities of each party.
- Service support should include: what is supported, when support is available, price, definition of priorities, and timeframe for resolution for each priority. Underpinning the SLAs are the internal operational level agreements and/or underpinning contracts with a third party to support the SLA with the customer.
- A value chain of internal and external capabilities support the SLAs. The SLA helps define the relationships between the customer and service provider.
So, what if there is no service level agreement? Or it is badly defined? Or the service desk does not have knowledge of the SLA?
- Then the service desk will use best effort approaches to manage the incident and the perceived breach.
- Most of the SLAs, if not all, will be breached. An organization cannot effectively deliver to an unknown service support capability.
In addition, there are three types of SLAs defined in ITIL. Service-based, customer-based, and multi-level. Organizations need to pay attention to the types and how to effectively write appropriate SLAs for each type.
Is There a Better Way to Manage SLA Breaches?
Let’s go back to the original question. It sounds like the SLAs are not written well for the interpretation of what to do if the particular service has a support issue and how the service provider should respond for defined priorities agreed to with the customer. When this happens the service support organization just performs based on best effort without proper guidance from the SLA, which they agree to in the form of operating level agreement (OLA).
Since this seems to happen all the time, this supplier needs multiple things to happen, such as understanding of their support capabilities for the services at the service desk, then articulating them in OLAs for the Service Level Manager. The support SLAs may not be good enough for the customer, in that case a service improvement program needs to be put in place to satisfy the customer needs at the right price (so the support organization recovers cost of support at the level the customer needs it). Or the response to the breaches mentioned may be overdone (timeframe, priority, or not in alignment with customer needs or expectations). The service desk may be working on the wrong issues based on business needs. For example, this particular breach could be related to a service that could have a longer resolution time but the service desk is not managing the breach correctly.
And, yes, SLAs can be related to downstream operational tasks at the service desk, only if the intelligence is built in (OLAs, technology and other stuff) that support the capability that the SLA promises.
Relationships to the Issue
Often, in cases like this one, an organization needs to back up and look at other relationships related to the issue. This helps with root cause analysis for putting in better or permanent fixes for operational efficiency. The source of the issue here may be improper service level agreements and supporting operational level agreement, including training at the service desk for responding appropriately.
About Anthony Orr
With more than thirty years working in various IT strategy, managerial, consulting, executive advisory, marketing, and technical positions. Anthony is author of the ITIL v3 2011 publications and the ITIL MALC exam book, as well as a Sr. Examiner for the ITIL v2, v3 and Cyber-Resilience certification examinations. He has published numerous podcasts, videos, booklets, white papers and articles, including a white paper, Synergies between ITIL and DevOps, with AXELOS. Anthony has traveled to over 50 countries and lectured at universities around the world.
Read more articles by Anthony