Just for fun, I typed, “I hate SLAs” into Google. Don’t try it at home. Google auto-populated my search bar with “I hate Slash” instead, and I spent five minutes reading articles like “Slash: Axl Rose Hates My Guts."
In a way, it's actually the perfect lead-in to today’s topic. Axl and Slash have been at it for years, but so have IT managers and SLAs. It's not that we hate SLAs, or refuse to be seen on the stage with them in matching leather pants. It's just that SLAs are notoriously difficult to measure, report on, and meet. They're even harder to configure and change in many of today's service desks, too. We know we need a way to track our performance against our top business objectives, but the current way just isn't cutting it.
What can JIRA Service Desk do about it? We’ll get to that, but the tooling is less important than the concepts. So first, let’s cover some basics.
What is an SLA anyway?
As a service provider, a Service Level Agreement (SLA) is a plain-language agreement between you and your customer (whether internal or external) that defines the services you will deliver, the responsiveness they can expect, and how you will measure performance.
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.
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 “just because.” Frustrating, isn’t it?
- There is zero 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.
If you’ve experienced one or more of the challenges above, I feel your pain. So let’s start with a few simple tips for setting smarter SLAs. Then, we’ll cover three ways you can use JIRA Service Desk to build them easier and make them more flexible and effective.
First, revisit your SLAs and create the best ones possible.
Above, we talked about how SLAs can feel a bit arbitrary – like we’re not always measuring something that directly supports your company’s bigger business objectives. To make sure you’re not only measuring the right things, but also meeting the expectations that other parts of the business have of you, we recommend revisiting your SLAs at least once a year. Follow this simple process:
- 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.
- 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?
- Build a draft of new SLAs based on 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.
- 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.
Once you’ve brokered the best SLAs for your current business and customer needs, you’re ready to implement them. So here we go: three tips for taking SLAs to a whole new level of ease and effectiveness. I'll use JIRA Service Desk to demonstrate how it's done (special thanks to Atlassian Experts Valiantys for the great video tutorials).
Tip #1: 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. It isn't as easy as it sounds, either. 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. Unfortunately, many measurement and reporting systems can't accommodate exceptions like these, so the service desk team ends up looking far worse than they are actually performing.
In JIRA Service Desk, we added a clever little feature that makes it easy to get far more accurate reports. In a nutshell, you can configure any SLA to pause automatically based on any trigger you define, from a simple ticket status change to a change in assignment or escalation.
Here's how it works:
In about a minute, you’ve created an SLA – and the clock will stop ticking each time the ticket status is updated to reflect that you are waiting on more information from the customer, which keeps the reporting on your performance accurate.
Other protips for creating successful SLAs:
- 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.
- Break large, complex SLAs into 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.
Tip #2: Set different performance goals based on ticket priority levels
On an average day, your service desk team won’t consider a printer failure it’s highest priority ticket. But the CEO’s printer? That’s another story.
In practice, you 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 should expect the same flexibility from your service desk software, and we’ve got you covered. In JIRA Service Desk, you can create SLA performance goals based on just about any combination of parameters you define. Configuring these SLAs is easy, can be done in-house, and requires absolutely zero customization or software development – i.e., you can change them as needed without spending a fortune.
In this example, a customer wanted to create different SLA performance goals based on whether the ticket was a P1 or a P5. Here’s how they did it:
Now, each time a new ticket is opened, JIRA Service Desk checks the ticket against all of the goals you have defined in your SLAs, and assigns the appropriate SLA time target based on the first matching JQL statement.
Plus, you can create new goals for just about any parameter, and change or edit them easily to keep your team’s priorities completely aligned with changing business needs.
More tips for setting great goals:
- Get creative. You can use any custom field or criteria within your JIRA Service Desk project. Basically, if it’s stored in JIRA Service Desk, you can create and measure SLAs with it.
- Resist the urge to create too many goals, though. 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.
Tip #3: 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.
The problem? It can be difficult to configure some service desks to "stop the clock" from ticking on Saturdays and Sundays, and even more complex if you want to create customized rules for things like company holidays.
To handle situations exactly like this, JIRA Service Desk allows you to build and select different calendars for each goal you assign to an SLA. This way, you can assign a 24 x 7 service window to all P1 tickets, and a “business hours only” service window to all other tickets.
Here’s how you do it:
Now, your SLA’s will only run during working hours, unless the ticket is a P1. They’ll resume running again at the start of the next workday, just as you’ve defined — and P1 tickets will run around the clock until you resolve them.
Other tips for using calendars:
- Create calendars to support teams in different locations
- Don’t forget to add public or company holidays, and remember to check them yearly since some holidays change
How else can you do more with SLAs in JIRA Service Desk?
To wrap up, I’ll leave you with a few ways to use SLAs even more effectively in JIRA Service Desk.
First, check out the Atlassian Marketplace. It’s the second biggest enterprise app store in the world, and you’ll find tons of powerful add-ons for JIRA Service Desk that provide easy answers to some of your most complex needs. We recommend starting with the notification assistant add-on to do things like sending automatic notifications to the incident manager if an SLA is breached. It runs on JQL, too, so you can fire off notifications for just about any query result you like. You can also use Twilio’s API with JIRA Service Desk to create very powerful, easy-to-implement workflows, like sending an SMS to your service desk team every time a P1 ticket is created.
There: don't you feel a little better about SLAs already? Now if only we could do something about Slash and Axl.