SLAs (service level agreements) are notoriously difficult to measure, report on, and meet. They can also be difficult to configure and change in many service desks. Still, it’s important to track your performance against top objectives, and SLAs provide a great opportunity to improve customer satisfaction.

What is a service level agreement (SLA)?

As a service provider, a service level agreement is a plain-language agreement between you and your customer (whether internal or external) that defines the services you will deliver, the responsiveness that can be expected, and how you will measure performance. 

SLAs define contractually agreed upon terms for services including things like uptime and support responsiveness. For instance, promising customers 99.9% service uptime or a response from support within 24 hours. In addition to formalizing service expectations, SLAs set forth the terms for redress when requirements are breached.

The importance of SLAs

SLAs are a foundational agreement between your IT team and customers that are important in building trust. They manage customer expectations and allow your team to know which issues you are responsible for resolving.With SLAs in place, there is mutual understanding of service expectations. Implementing SLAs can benefit your IT team in numerous ways that include:  

• Strengthening IT’s relationship with customers – SLAs ease the concern over risk, which improves trust between parties. By defining what happens in the event of a breach, they reduce uncertainty. 
• Formalizing communication – Conversations with stakeholders about IT issues can be difficult. Nobody wants to be hearing from a customer ten times a day or,on the other hand, allowing a customer to quietly stew over their unspoken expectations for service performance. An SLA enables stakeholders to have structured conversations based on already agreed-upon terms. 
• Improving productivity and morale – SLAs define the urgency of incoming requests. They focus IT teams on which incoming issues matter the most.

The difference between SLAs and KPIs

An SLA is an agreement between you and your customer that defines how your relationship will work in the future. Key performance indicators (KPIs) are the metrics chosen to gauge how well a team performed against agreed standards.

An IT service desk, for example, typically agrees to provide technical support for a wide variety of services and devices within the business, and offers guarantees around things like uptime, first-call resolution, and time-to-recovery after service outages. KPIs are the specific metrics that are chosen to track whether the IT service desk fulfills these guarantees.

The challenges of SLAs

This all sounds simple, right? In theory, yes. In practice, though, IT teams often run into one or more major challenges:

• Tracking SLAs is difficult, and changing them is even harder. To see how they’re performing against SLA, many IT managers have to extract a ton of raw data, write custom queries, and build elaborate Excel formulas and reports. Plus, the SLAs often have to be custom or hard-coded into many service desks, meaning it can take days of development effort to change them.
• SLAs don’t always align with business priorities. SLAs seldom seem to change or evolve at the same pace the business does. In fact, more often than not, they’re inherited. Someone set an SLA a decade ago, and today it’s honored simply because it’s there. 
• There is little flexibility in reporting. Even though there are a ton of unique circumstances influencing SLA attainment (like how long it takes for a customer to reply to you, etc.) most SLA reports don’t easily account for them. You either met your SLA or you didn’t. There’s no way to highlight something in a report that shows why, or helps you continually improve.

How to set SLAs and measure your performance

Above, we talked about how SLAs can feel a bit arbitrary and like you’re not always measuring things that directly support your company’s bigger business objectives. To make sure you’re measuring the right things, and meeting the expectations that other parts of the business have of you, we recommend revisiting your SLAs regularly. Follow this process:

1. Set a baseline. The best place to start is by looking at your current SLAs, and how you’re performing against them. Take an inventory of what you offer, and how it aligns to the business goals of your company and your customers.
2. Ask how you’re doing. Talk directly with your customers and solicit constructive feedback. What are you doing well, and what could you do better? Are you offering the right services?
3. Build a draft of new SLAs based on the results of the steps above. Get rid of the services you no longer need, and add the ones that will make customers even happier and bring more value to both the business and IT.
4. Get support from management. To be successful, SLAs need the blessing of your IT leaders, and the leaders of your customer organizations, too. Start by getting your own management to buy in, and then ask them to help you negotiate with your customer’s management team.

If you’ve followed the above process, your SLAs should be in pretty good shape.

SLA best practices

Once you’ve brokered the best SLAs for your current business and customer needs, you’re ready to implement them. Here are some tips for taking SLAs to a whole new level of ease and effectiveness.

Create an SLA that stops tracking time to resolution while you’re waiting for a customer to reply

IT departments need to be able to measure their own response times effectively in order to provide the best possible service. Still, measuring SLAs gets complicated quickly as slow-responding customers and third party escalations cause response times to look far worse than they may actually be. Make sure your measurement and reporting systems can accommodate exceptions like these, so the service desk team is tracked based on how they are actually performing.

Remember the agent experience

Use simple, clear naming conventions. Agents should be able to read the name of the SLA and quickly understand what they’re being measured on. It’s also important to resist the urge to create too many goals. Agents should be able to clearly understand what their goals are, without too many special situations. The more goals you create, and the more variables you introduce into each goal, the harder they become to understand and adhere to.

Break up large, complex SLAs

Rather than creating complex SLAs use a series of smaller ones, so you can measure and report on the individual pieces of your workflow, not just the entire pie. This also makes it easier to update your SLAs and keep them current.

Set different performance goals based on ticket priority levels

On an average day, your service desk team won’t consider a printer failure its highest priority ticket. But the CEO’s printer? That’s another story. In practice, IT teams prioritize tickets in a ton of different ways: from which parts of the business are being affected to who opened the ticket to even more complex combinations (like an outage of the sales booking system at the end of the quarter).

You need flexibility from your service desk software so you can create SLA performance goals based on just about any combination of parameters you define. It’s important to be able to change or edit them easily to keep your team’s priorities completely aligned with changing business needs.

Keep some SLAs running 24/7, and restrict others to normal business hours

If your service desk team works Monday to Friday during normal business hours, you can’t provide true 24 x 7 support for every service you offer. Even with on-call service desk teams and customers that pay for priority support, you will still often have some services that warrant weekday responses, and some that warrant instant attention, no matter what time of day or night.

Configure your service desk to stop the clock from ticking on Saturdays and Sundays, and get even more complex if you want to create customized rules for things like company holidays. And, considering creating calendars to support teams based in different locations.