Service Level Agreements are often legally binding contracts with customers, especially for enterprise software. If an SLA is breached, your organization could lose a customer, be expected to pay large fines or be sued for breach of contract. Just like uptime guarantees, support SLAs are critical for large companies working with VIP customers.
“Delivered in 30 minutes or the pizza is free” – Domino’s SLA, once upon a time.
When Domino’s started delivering pizzas in 1979, they guaranteed that customers would get their pie in 30 minutes or less… or else they wouldn’t have to pay for it. Sounds like a good deal, right? That guarantee is a great example of a Service Level Agreement. Service Level Agreements (SLAs) help customer support teams define and deliver an expected experience to customers. In support, most SLAs are time-based. For example how quickly will customers receive a first response? (Hint: 2.5 seconds is not the correct or rational answer here.)
SLAs are often legally binding contracts with customers, especially for enterprise software. If an SLA is breached, your organization could lose a customer, be expected to pay large fines, or be sued for breach of contract. Just like uptime guarantees, support SLAs are critical for large companies working with VIP customers.
First of all, you should use SLAs because they make your team faster. Ain’t no one go time for slow-pokes here. As Zendesk reports: “A recent study of IT users covered by response-time SLAs reported an average response time 200 times faster than their non-SLA counterparts.”
This is probably because using SLAs keeps your team’s attention on the right tickets at the right time, like having a tiny virtual general that shouts “FOCUS UP” every time a ticket comes in.
SLAs create seamless automated workflows to surface older, more urgent tickets. Andrew Spittle, Happiness Engineer at Automattic, recently sat down and talk about their support set up. They rely heavily on SLAs to prioritize tickets and reduce the cognitive load of agents choosing which ticket to answer next. Since they’ve set up priorities and SLAs for every incoming ticket, agents simply click “Play” and are served up a queue of tickets in the order they need to be answered. It’s a great way to prevent your team for ignoring Brian’s latest ticket just because he didn’t invite them to his exclusive GoT costume party (jerk).
Defining SLAs with your customers also helps set better customer expectations. They know how quickly they can expect a response, and this helps them benchmark your service and avoid obsessively checking to see if they’ve heard back or not. A short SLA can build trust with a customer who needs to know you’ll be there if they run into trouble.
Finally, as mentioned above, some SLAs are legally binding. You need to be consciously tracking the service provided to these customers in order to meet obligations.
Deciding how quickly your team can consistently reply and resolve tickets can be difficult. You want to be responsive, but you also don’t want to set unrealistic expectations that you can’t meet. Plus, you might not always need to respond right away. Here is a list of some top SLAs that are typically set up.
First reply time – the amount of time it takes for a customer to get their first reply to a new ticket. As we know, in this day and age, an immediate response isn’t quite fast enough for some.
Next reply time – the amount of time between the oldest unanswered customer’s reply and the next public agent reply. Do you keep track of how long it takes for someone to respond to you? Yeah, so does everybody else.
Requester wait time – the combined total time customers spend waiting for a reply, measured by the ticket being in the New, Open, and On-hold statuses. The SLA will pause on Pending. It measures the customer’s experience of waiting. And in case you’re not aware, most people don’t relish the time they spend waiting, not surprising!
Agent work time – the combined total time agents are working on the ticket, measured by the amount of time in the New and Open statuses. The SLA will pause on Pending and On-hold. It measures the company’s efficiency at responding to customers. It won’t feel like being watched, but, you are being watched 😇.
Consider the industry you’re in - if you deal with business critical software, customers need responses fast. A store with a broken cash register is losing money every minute and the SLA needs to reflect that urgency. However, if you work with consumers on a free app, maybe you can take more time to respond.
Look at customer satisfaction responses - if customers are consistently complaining about slow responses, it’s time to pick up the pace. If you aren’t seeing any concerns about response time, it might actually be worth slowing down a little and focussing on quality over speed. Faster isn’t always better, remember, the fable about the tortoise and the hare?
Identify the most urgent channels - For example, a ticket sent from Slack might not be as urgent as responding to public tweets about product or client issues.
Be realistic about your resources - Ideally, we’d love to always be at inbox zero, 🎉 but we don’t always have the team size to respond instantly. Set a realistic goal that your team can hit without sacrificing their mental health, and then improve from there.
For example, Domino’s actually ended their 30-minute guarantee in 1993. They found that delivery drivers were taking unsafe measures to get pizzas delivered on time. Being realistic about what you can deliver is critical to setting good SLAs. And keeping pizza safe (even Domino’s pizza) is just as important, if not more.
Underpromise and overdeliver. By setting separate SLAs internally and publicly, you can build in a buffer zone for busier periods. For example, even if you publicly agree to answer all emails within 8 hours, internally your team should be shooting to answer in 6 hours. Missing an internal SLA is disappointing, while missing a contracted SLA could cost your team a contract, or fees.
Internal SLAs can also help identify when it’s time to start hiring. If you’re consistently missing an internal SLA, it’s time to think about recruiting before you start breaking promises to customers.
You can create both internal and external SLAs to track breaches. Just make sure you use the right ones for reporting and workflow building (more on that later!)
SLAs can be run on either business hours (which are set by your company) or on calendar hours. Business hours are great for measuring how teams perform when they are on the clock, and work well for business to business companies.
However, calendar hours are great for knowing how long your customers are waiting in real time. To your customers, it doesn’t really matter if you’re in the office or not. If they live in Australia, and have to wait until American business hours every time they have a question – that’s an issue you’ll need to fix. We just don’t know yet how many times “maybe the dingo ate my initial reply to you” will work 🥁.
SLA achievement is measured in percentages for each policy. Achieving between 90-95% is very good. Achieving less than 80% means that you should start looking into ways to improve on service delivery. It’s like being in school again, but this time the person who pays you is checking your report card 🤪.
If you have contracts requiring a standard SLA, it might make sense to set up each of them on a separate SLA. That way, account managers can easily check to ensure their client’s SLAs have been consistently met.
It might be a tired cliché, but it’s true: what gets measured, gets managed. Building in SLAs to your help desk will help build trust with customers, set expectations with agents, and improve efficiency. Halp provides many ways to set up your SLAs in order to capture any agreement you might have with your internal and external clients.
Now, if you haven’t refined your SLA policies already after reading this, it’s time to dive in!
Liked this article? Sign up and subscribe for more tips!
As Halp’s Microsoft Teams integration has developed, we’ve switched from installing our apps in Teams’s App Studio to a sideloading. Basically, sideloading is the process of uploading a custom Teams app by uploading said app’s zip package to the Teams Store.