Understanding the importance of service level agreements (SLAs) in ITSM with SLA examples

Learn more about SLAs and their role in your IT service desk.

• What is an SLA?
• Types of SLAs
• Importance of SLAs SLM and ITIL 4 -->
• Roles & responsibilities
• Best practices
• Download self-assessment toolkit
• FAQs

Remember the last time a product you ordered was delivered after the promised delivery date? Yep, the frustration of a product or service being delayed is certainly not something you'd want to experience frequently. The frustration is sometimes enough to make you take your business elsewhere.

Similarly, IT service desks also offer services to end users. Tickets are created to report incidents and raise service requests and are expected to be resolved within a reasonable amount of time. But what is a reasonable time frame? Each requester has their own expectations, so how do you effectively standardize and manage end-user expectations?

This is where service-level agreements (SLAs) can help. SLAs are a powerful tool IT service desks can employ to manage requesters' expectations. Now let's take a look at what SLAs are, the elements you need to create an SLA, SLA best practices, and more.

What is a service-level agreement?

An SLA is a written contract between a service provider and a customer that describes the services to be provided, the standards of performance for those services, and how the service provider will be held accountable for meeting those standards.

In the context of ITSM, SLAs help set and manage the expectations of end users when they raise a request or report an incident. In IT service desks, SLAs are primarily used to define the time it takes for services to be delivered and incidents to be resolved.

How do you design an SLA?

Being an agreement between a service provider and a customer, SLAs need to document the scope and level of service provided. To effectively record the terms of the agreement, SLAs are generally made up of a combination of these elements:

• Service description: A detailed summary of the agreement, parties involved, and services provided
• Quality of the service: Details of the standard of the service
• Responsiveness of the service: Details of how quickly the service will be delivered
• Penalties on failure to meet the agreed terms: Details of what penalties are implemented for varying levels of failure to meet the agreement
• Performance measuring: List of metrics that need to be measured, including how they are measured
• Conditions of cancellation: Details of conditions under which the terms of the agreement are waived

An SLA does not have to comprise all these elements. The combination of elements is determined by the type of service provided.

What are the different types of SLAs?

SLAs can differ for every single type of service provided, but they can be broadly classified into three main types.

• Customer-based SLA:
  A customer-based SLA is between a service provider and a customer or customer group. It details the services provided, the level of service, and the terms of the relationship. For example, in the relationship between an on-demand video service and a subscriber, a single contract covers the services available, duration of the services provided, and promised uptime. The contract will change for each customer based on the plan they choose. Here the SLA is based on the individual customer.
• Service-based SLA:
  A service-based SLA is offered when the agreement is based on the service or product chosen by the customer. It details the regular and additional services offered and the level of service. For example, the IT service desk provides different services to all requesters, and each service item has a unique SLA that details the service that will be provided and when it will be delivered. Here the SLA is based on the service item, which has a common SLA for all end users.
• Multi-level SLA:
  A multi-level SLA is an agreement in which an SLA is divided into multiple tiers or levels that specify a series of customers using a single service. It addresses agreements at the corporate, customer, and service level. For example, a workstation service request has a high-priority SLA when requested by a high-ranking official, and a low-priority SLA when requested by a temporary worker.

Why do you need SLAs in ITSM?

Now let's look at how SLAs bring value to your IT service desk. Consider the example of a service request ticket for employee onboarding.

Mark raises an employee onboarding ticket. He selects the employee onboarding template and raises the request with the configuration he wants. Right during ticket creation, Mark can see that this service request will be completed within 14 days, and this sets his expectations. Mark raises the request at 12:53pm and the SLA timer starts.

The SLA defines the following service delivery terms:

• Response time: The time within which the assigned technician needs to respond to the ticket. In this case, the assigned technician needs to respond to Mark's ticket within 24 hours from the time of ticket creation.

• Resolution time: The time within which the workstation has to be delivered. In our example, the ticket needs to be resolved within 14 days from the time of ticket creation.
• Escalations: Actions and notifications that will be triggered if response or resolution times are breached. Based on the SLA that is associated with the employee onboarding template, we see that a few escalations and actions have been set up that take place in the event of an SLA violation. The first escalation is set up to alert the ticket owner that the ticket has not been responded to; it is set up to automatically notify the ticket owner 30 minutes before the response SLA is breached. The other escalations are for breach of the resolution SLA. The first-level escalation is again set up to alert the ticket owner one day before the resolution deadline. The second-level escalation is set up to flag the ticket owner's reporting manager and place the ticket in a special technician group that works on high-priority user management tickets to resolve the ticket in the shortest possible time.

And finally, after the request is closed, a custom survey is sent to collect Mark's feedback to ensure the SLA is satisfactory and working the way it was designed.

From this example, we see that SLAs make sure incidents and requests are resolved on time, helping minimize downtime and enabling normal business operations. SLAs also play a vital role in enabling your IT service desk to utilize their time and effort efficiently. High-priority tickets are assigned appropriate SLAs that demand these tickets are responded to and resolved immediately, whereas low-priority SLAs afford more time to respond to and resolve low-priority tickets.

ITIL 4 breaks the mold of traditional SLAs that were solely focused on individual activities, such as resolution time and system availability, and led to the watermelon effect. The watermelon effect is when SLA metrics show good results but still leave customers dissatisfied. An SLA that meets an acceptable level of deviance but affects the customer's workflow will lead to dissatisfaction. ITIL 4 places more emphasis on identifying metrics that measure a truer reflection of customer satisfaction. The service value chain introduced in ITIL 4 helps align SLM with these newfound goals. This is a small representation of how SLAs work along the service value chain:

• Plan: SLAs help plan the service and product portfolio and the level of service.
• Improve: Customer satisfaction surveys can help determine the effectiveness of the SLA, and changes can be made to improve SLAs.
• Engage: Customer feedback and continuous service improvement ensure engagement with customers to eliminate the watermelon effect.
• Design and transition: Better SLAs can be designed and developed, and existing SLAs can be improved based on feedback.
• Obtain or build: SLAs provide a baseline for service delivery standards and enable measurement of service delivery performance.
• Deliver and support: SLAs provide support teams with service delivery objectives and ensure services are delivered on time.

SLA management roles and responsibilities

Now let's look at who is in charge of SLA management, and the responsibilities of the various stakeholders.

• Service level manager (process owner): The service level manager is accountable for the entire SLM process. They ensure the process is effective and that the right stakeholders are involved during the process. They also have final say on the level of service for each service item.
• Service owner: Service owners are responsible for delivering services within the agreed service levels. They usually lead internal support groups.
• Support groups: These are groups of specialized technicians who deliver services within the agreed service levels.
• Technicians: A technician is a support agent who delivers services within agreed service levels.
• End users: An end user is a consumer of services.

Best practices to improve your SLA management

Here are some best practices you can use to improve your SLAs.

• Create different SLAs for different ticket severities.
  One SLA does not fit all! It's important to create a variety of SLAs for different ticket types and ticket priorities. This helps the IT service desk allocate the right resources for each ticket and manage requesters' expectations better.

• Set up response and resolution SLAs.
  Response SLAs refer to how quickly technicians respond to tickets. Responding to tickets can significantly boost requester satisfaction, as it shows them that their ticket is being actively worked on. Response SLAs ensure that technicians respond to every single ticket on time, even on busy days, and escalations can be configured to make sure every ticket is responded to on time.

Resolution SLAs refer to the time within which tickets need to be resolved.

• Configure SLA escalations.
  SLA breaches are unavoidable at times, and when they do happen, you need to have mechanisms in place that ensure the ticket gets resolved soon. SLA escalations automatically flag issues for management, such as a ticket that has breached its SLA or is nearing the deadline. SLA escalations can be proactive or reactive depending on your business needs, and you can set multiple levels of escalation to ensure tickets are resolved. Escalation actions can be configured to bump up the priority of the ticket and reassign it to a specific support group or technician automatically during each level of escalation.

• Monitor SLA performance regularly.
  SLAs need to be regularly monitored to gauge the performance of the IT service desk and identify if SLAs are effective. The IT service desk's environment is constantly changing, and evaluating SLAs helps understand the adjustments that need to be done to keep SLAs relevant and effective. You can monitor SLAs using dashboards and get detailed metrics using reports. Some important metrics to keep track of are first call to resolution, defect rate, average time to respond, turnaround time, and mean time to recover.

• Create realistic SLAs.
  Finally and most importantly, set up realistic SLAs. SLAs that overpromise and under-deliver are the bane of any IT service desk. Tickets won't get resolved on time, requesters won't be satisfied, and ultimately normal business operations will be disrupted, causing the organization to lose money. So, first evaluate your ticket requirements and your available resources when defining your SLAs.

Conclusion:

When used properly, SLAs can be a powerful aid in making your IT service desk more efficient by helping prioritize tickets and carefully allocating the required resources to resolve tickets on time. SLAs also define service delivery standards and help you manage requesters' expectations better. Adopt SLAs to take your service delivery to the next level and ensure no requester is left frustrated with delayed services.

Try out ServiceDesk Plus to implement these SLA best practices out of the box with zero scripting.

Quickly assess your IT incident management practices with our toolkit

• A self-scoring assessment to gauge your core incident management practices, from incident identification to closure
• A checklist to review your team's readiness to tackle major incidents for the hybrid work environment
• A cheat-sheet to help overcome the common incident management challenges faced in the hybrid work model