SLA Best Practices for ITIL, Help Desk & Service Desk
According to ITIL 4, a service level agreement (SLA) is “a documented agreement between a service provider and a customer that identifies both services required and the expected level of service.” Simply put, an SLA defines what the IT service provider and the customer should expect when contracting for a service.
In the ITIL service lifecycle, SLAs are defined and modified in the Service Design and Continual Service Improvement core areas. This means that SLAs for IT services should be created alongside any specifications for new and updated services. Whenever an IT service is designed or changed, its accompanying SLA should also be reviewed and modified to make sure it is fair, enforceable, and realistic.
Given this, here are six best practices for creating and fulfilling IT service SLAs in an IT service management (ITSM) environment.
These all-new for 2020 ITIL e-books highlight important elements of ITIL 4 best practices. Quickly understand key changes and actionable concepts, written by ITIL 4 contributors.
SLAs are a collection of promises the service provider makes to the customer. Avoid creating a single SLA for your entire service catalogue. Rather than defining that all IT service requests will be fulfilled in five hours for example, create separate SLAs for each IT service you want to track.
Strive to be specific. Some examples might include:
Each IT service has its own lead time and approval schedule, which must be completed accordingly.
If you’re providing support for an organization with many different locations or divisions, be careful creating SLAs that cover multiple locations. Different operating units may have different support requirements, so an umbrella SLA may not adequately support each location.
For example, if you’re providing printer support, the customer may request a response time of four hours between 8 AM to 5 PM weekdays. This may be easy to satisfy in a metropolitan area, where there are a lot of technicians. It may be more difficult to keep that four-hour response in rural areas, where there are fewer technicians living farther apart. This and similar situations may require more detail on services by region or separate SLAs for each region.
SLAs should be created for the desired outcomes of the customer. Be aware of the “watermelon effect”, where the service provider is meeting the metrics of the SLA (service uptime, for example), while failing to support your customer’s real goals.
A traditional SLA uses IT operational metrics such as Telecommunication lines must be up 99.1% of the time. These SLAs manage the numbers, but lack context for the customer’s desired outcomes. Instead, use truthful measurements and metrics in your SLAs, reflecting the customer’s actual desired outcomes.
As an example, your SLA may guarantee 99.9% uptime for telecommunication lines. Your testing shows that you’re meeting that metric, but the .1% downtime occurs at the customer’s busiest time, when telecom traffic spikes, like during the NCAA tournament or on Amazon Prime Day. Service drops during those .1% outages and the customer is unhappy. Like a watermelon, the service provider sees a green SLA being met on the outside—99.9% telecom uptime—while the customer sees a red SLA failing on the inside—their users are losing connectivity when the line is swamped.
Whenever possible, discover the customer’s desired outcome for the SLA and write the SLA to that outcome. A replacement outcome-based metric SLA could be Redundant telecommunications services will allow uninterrupted user access between 6:00 AM and Midnight EST. Outcome-based SLAs manage to the customer’s desired outcome rather than managing to a number. Outcome-based SLAs will also affect how you, as an IT service provider, manage the customer’s service.
This important best practice hinges on engaging and listening to your customer while creating and modifying their SLAs. Let them become part of the process so they can understand your service levels and you can write your SLAs to their needs.
Your ITSM service desk must be capable of gathering and presenting the necessary metrics to determine whether an SLA has been accomplished. SLAs must represent SMART goals—specific, measurable, achievable, relevant, and timely.
Each individual SLA must possess the following characteristics:
An IT service provider must be able to gather data about SLA performance and report on that performance. Make sure your service management software is up to both tasks.
As part of the ITIL Continual Service Improvement core area, an SLA should be reviewed and updated whenever there are proposed or promised changes for that service. Adjust for any change that affects desired customer objectives such as service hours, availability, uptime, completion, or response time.
Companies who fail to review and adjust their SLAs at times of IT service improvement may no longer meet their service levels targets – and the result could be a customer lost or penalties from SLA non-compliance.
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:
For more on service level management, browse the BMC Service Management Blog and check out these articles:
