ITSM Service Level Agreements, or ITSM SLAs, set the right expectations between the IT service desk and their customers. As a New Year’s resolution, refining your SLA best practices will help meet customer needs and combat the growing problem of shadow IT.
What is an SLA in ITSM/ITIL
As defined in 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.”
In other words, an SLA is the contract between the IT service desk and the customer regarding what will be provided and in what amount of time it can be expected. For example, imagine that you have a broken laptop and contact IT support. The SLA defines whether the IT service desk will repair or replace your laptop as well as the amount of time you can expect the service desk to take to resolve the issue.
ITSM SLAs are similar to agreements between other business units. In fact, you probably encounter SLAs in other business units without even realizing it. If you’ve ever requested marketing materials, or asked for HR support to better understand your benefits, those departments likely have an SLA in place to define the limits and terms of satisfying those requests.
An SLA is different from an Operational Level Agreement (OLA) and an Underpinning Contract (UC). An OLA defines the interdependent relationships in support of a service-level agreement, while the UC is a contract between an IT service provider and a third party.
None of this should be confused with key performance indicators, or KPIs, however it does take KPIs to measure whether or not your SLAs are being met. These can be measured in your IT service management software.
3 Types of SLAs in ITSM
There are three types of SLAs within ITSM:
- Customer SLAs: This is an SLA between the IT service desk and an external customer. For example, when an online banking customer reaches out to the company’s IT support for problems accessing their account an SLA would typically be in place. A customer service-level agreement includes: details of expected service; provisions of service availability; escalation procedures; and terms for cancellation if the issue is not resolved.
- Internal SLAs: These are SLAs between IT support or the support provider, and the internal customers. For example, a company employee and the IT service desk. This agreement includes: the level of support; escalation procedures; and service level targets.
- Multilevel service-level agreements: This type of SLA is used when there are various levels of service for specific types of customers. This is in play when there are multiple levels of services available and the higher levels of service may be available for a fee.
Benefits and Challenges of SLAs in Modern ITSM
There are a number of reasons to create clearly defined SLAs, but at the core the biggest benefit is an improved employee experience. When the employee experience is better, it ripples out to create many other benefits, including: cost optimization, better metrics and reporting, clearer goals for self-service initiatives, and a better ROI on self-service.
We’ve talked about how SLAs define the limits of service delivery to the customer, but they also define the urgency. This is an important part of creating a great employee experience because it assures the person with the IT issue that their problem matters and will be resolved with some sense of urgency and commitment by the IT service desk team. But, that can’t happen without SLA management capabilities within your ITSM tool to help manage priorities and keep issues from falling through the cracks.
In turn, this also creates a better experience for the service desk agent because they are empowered to prioritize tickets and identify the VIP customers. This puts your service desk team in control with clear guidelines on their commitments.
Of course, none of these benefits come without their share of challenges. Some of the main challenges IT service desk teams face include setting unrealistic expectations, ignorance of the SLAs that are currently in place (either by the staff or customers), or too many requests which create the need for changes in SLAs and scalable solutions.
5 SLA Best Practices for 2022
To realize the benefits of ITSM SLAs, you must address the challenges which can be accomplished using the following 5 best practices. These practices address the communication issues to help you scale, modify, and refine your SLAs for the new year.
1. Create and Set Realistic Expectations
Realistic expectations should be set for every level of ticket. This means not only addressing and setting realistic resolution times, but realistic times for when there is a high ticket volume vs. low ticket volume.
For example, you want to be sure that the expectation isn’t always a 24-hour turnaround time for tickets just because that is feasible when it’s a week with a lower amount of tickets. You’ll want to set expectations that can be met when the volume is high and there is short-staffing due to vacation or illness as well.
2. Create Separate SLAs for Each Service You’ll Measure or Provide
Service delivery is not one-size-fits-all. The IT organization provides different levels of service to different customers, which is why you’ll need to create separate SLAs for each service you’ll want to measure and provide. This can be done through a multi-level SLA.
For example, you’ll want to set a different SLA for providing service and support to a customer whose job directly impacts the company’s ability to make money (a value center) vs. the expectation for how long or the level of support to a business unit that operates as a cost center.
However, SLAs might not always line up completely with business needs. You should coordinate with business units to set the right expectations from the start, based on the greatest business need.
You can base these SLAs on different user personas, be it based on the business unit or pared down even further to the different possible customer types within those units.
3. Make Sure SLAs are Measurable
SLAs are useless if they’re not measurable, because the inability to measure them means that you can fall into the trap of people ignoring them. KPIs create accountability. Additionally, they show you which SLAs need to be adjusted, scaled, or modified.
SLA compliance can be measured by dividing the total number of incidents resolved within SLA time by the total number of incidents. Why does this matter? This measure tells you the percentage of IT incidents that are resolved within your contractually agreed upon parameters. This can help keep business goals on track with IT in mind and help keep expectations realistic – while still alerting you to which expectations need to be adjusted.
4. Include SLAs for Self-Service
SLAs shouldn’t end with human support from the service desk. Self-service requires SLAs as well. For example, you can create an SLA for self-service password resets. This can help customers understand what they can actually accomplish through self-service channels and what they might require human help to achieve.
You can learn more about the right SLAs and which KPIs to measure regarding self-service by downloading this new Gartner report.
5. Recognize the Relationship between SLAs and Collaboration Efforts
Something many of us fail to bake into the recipe of SLAs is the inherent relationship between SLAs and collaboration efforts. By that, I mean that when multiple team members collaborate, either through peer-to-peer insights or through collaboration software and shared resources or knowledge, that can improve resolution times (not to mention improve customer experience and employee experience).
Because of this relationship, the SLAs should take into account the level of collaboration that your team currently has, as well as the level you aspire to have in the future. This will help you realistically set expectations for customers and team members alike.
Examples of SLAs in ITSM with Best Practices Applied
Now that we’ve talked about best practices for SLAs, let’s look at an example of an effective SLA for incident management.
In ITIL, incident management processes and SLAs for each step might look like:
Step 1: Incident logging – The service desk agrees to log incidents within 1 hour of reporting through ITSM software.
Step 2: Incident categorization – The service desk agrees to categorize the incident when it is logged through an ITSM automation process.
Step 3: Incident prioritization – The service desk will prioritize tickets that impact external customers at a higher level than password resets and lower priority tickets. This process is automated through an ITSM automation process.
Step 4: Incident assignment – This ticket will be assigned to the proper agent, if that agent is unavailable we will re-assign within 24 hours.
Step 5: Task creation and management – The agent will work on your task and manage the process while communicating to the customer within 24 hours.
Step 6: SLA management and escalation – If the ticket requires escalation, we may modify the time to resolve. This may take up to 24 hours.
Step 7: Incident resolution and closure – The service desk will communicate with the customer prior to ticket closure to communicate the resolution.
Bear in mind, this is an overly simplified example for lower-level issues. However, it is an example of how to break down the steps of resolution and create service level agreements for each step.
To learn more about how to become proactive in service management and automate processes, check out our new eBook here.
