How Effective Are Your Service Level Agreements?
Abstract
Service Level Agreements (SLAs) are embedded in most service contracts in an attempt to hold third-party service providers accountable and measure their performance. Sadly, SLAs are not as effective as they could be in reality. This blog touches upon some of the reasons for this. Poor SLAs result in missed opportunities, added costs, and lower customer satisfaction.
What are SLAs and why do they exist
To begin we need to understand what a Service is within the SLA context. Services are a set of activities performed by a third-party provider to mitigate an adverse situation that prevents a client from being able to support their end-users. Typically these adverse situations are recorded in tickets.
According to ITIL, a Service Level Agreements is a documented agreement between a Service Provider and a Client that outlines an expected level of service. In other words, it is a measure of the level of quality of a service that the customer is willing to live with, one that they believe works to the best interest of their users.
By its very definition, having an SLA implies that a Client understands how the absence of the service affects their end-users and that they can represent that impact accurately in the agreement with a third-party service provider. It further implies that the client fully understands their end-users’ needs and can establish SLAs for all major service components that affect them.
For practical reasons, SLAs must be easily measurable and reportable. And they must be enforceable so that a non-performing service provider may be held accountable.
Elements of an SLA
I break SLAs into 3 elements:
Design:
- Service Description
- Duration/periods of service
- Exclusions from service
Measurement:
- Component of Service to be measured (e.g., Time to resolve)
- Any specific categorization of Service (e.g., Priority)
- Objective for the Service – what the Client believes they can live with should the service not be available (e.g., High Priority tickets resolved in 2 hours)
- Service Level Target or Level of compliance (e.g., 95% of tickets)
Compliance:
- Monitoring – this refers to the tracking and frequency of measurement of each SLA measure
- Reporting and presentation of achieved and missed targets
- Escalation – execution of a process to elevate the importance of an unresolved ticket both in communication to higher-level personnel and in assignment to higher-skilled personnel
- Resolution and Penalties – This includes the closure of a ticket with appropriate information added to the tracking tool and an assessment of penalties or recovery of credits
Do SLAs work?
In a word, sometimes! In my experience there are several reasons why SLAs don’t always work. SLAs are often treated as the as an afterthought – a last-minute imposition to complete a laborious contract:
- They are poorly designed, and objectives and targets are set without regard to business impact, measurability, or enforceability
- Tool contracts are separate from service provider contracts and selected tools may not have the ability or be configured to collect the data required to enforce service SLAs
- Ambiguous and unenforceable SLAs allow a service provider to claim they have no liability and can’t be held accountable
- Even if a Client realizes their SLAs are not effective, there is no incentive to change them because that would require a contract change – and that as we can all agree is like “fighting city hall”
- In some situations, Clients ask a service provider to produce their own SLA reports with minimal verification – this activity is one that gets relegated to the bottom of the list especially as many companies run “lean’
The sad news about SLAs is while they are ubiquitously found in contracts, they are seldom well-designed, or well-measured, or well-reported, or well-enforced.
What’s Next?
You can imagine the cost implications of a poorly designed SLA. Just think if you have a repair time of 8 hours for an outage but you can’t do much about it because your SLA does not hold a service provider accountable, either because you designed it poorly, or because you can’t measure it accurately. Imagine the impact to your end-users and to your organization. Also imagine the cycles you have to spend in designing the right SLAs and updating the service contract. All in all, a goat rodeo. As they say, an ounce of prevention …
We can be pollyannish and ask/expect Clients to redesign their SLAs from scratch. This is not real-life. Rather, we suggest keeping track of relevant metrics (even if they are not in the service contract as SLAs), independent of the service provider. This will allow you to understand what you need to do to improve the health of your services and hold your service provider accountable. This approach works even when the services are provided by an internal group. As Ronald Reagan was fond of saying in Russian about the erstwhile Soviet Union, “doveryai, no proveryai”, which means trust but verify.
Do your experiences differ from mine? What do you think are some of the core issues affecting SLAs? Do you have some tricks/tips to improve this ITSM area? Your thoughts are important and welcome.
Sai Balakrishna
Managing Partner & CEO
📧 info@quantumvision-ai.com
🌐 www.quantumvision-ai.com
No responses yet