Last updated on: October 29, 2024
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.
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.
Improper SLA management
Ensuring your SLAs are free of issues is vital for flawless and timely IT service delivery. Let's discuss some areas where organizations often fumble when it comes to dealing with SLAs.
Incorrect criteria applied to SLAs (or none at all)
It’s a best practice to define SLAs based on priority, since priority is a function of urgency and impact. Any other parameter would offer less clarity and delay resolution. Your organization needs to define various priority levels and create distinct SLAs for each of them with proper response and resolution mandates.
Unrealistic SLAs and resolution times
A common mistake organizations make regarding SLAs is mandating an unrealistic resolution time for various types of incidents. This happens when there is an absence of active collaboration between IT and business teams when drawing up service levels. Targets such as resolution and response times must be achievable, and they should consider the availability of IT staff, their training, and the needs of the business.
No proper escalation mechanism, or reactive responses to violations
An SLA's role doesn't stop with mandating response and resolution time limits; SLAs also define escalation mechanisms when the defined parameters are violated. Your organization should configure multiple levels of proactive and reactive escalations for each SLA.
Functional escalation deals with escalating the incident across IT to subject matter experts and is focused on providing the right solution to tickets. Hierarchical escalation, on the other hand, involves higher levels of management and is usually for preventing a violation or for decision-making. It is pertinent to note that these two types of escalation are not mutually exclusive, and you may escalate a ticket to a higher level of management while also placing that same ticket in a specialist technician group. Automated actions during escalation improve the effectiveness of SLAs.
Keeping SLAs as the primary KPI
The main purpose of SLAs is to ensure that incidents are resolved within mandated time limits. But if your organization measures technicians’ effectiveness solely on how well they meet SLAs, technicians may begin to close incidents as soon as possible by providing quick solutions rather than accurate ones. This of course compromises the quality of your organization’s incident resolution. Instead of measuring SLAs alone as KPIs, your organization should consider SLAs and customer satisfaction scores (CSATs) in conjunction to deter such undermining of SLAs.
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.