Implementing Service-Level Agreements in Jira Service Management

SLAs in Jira Service Management Header Image

Service-level agreements (SLAs) are a way for support teams to ensure that they are delivering good customer service, and for a customer to ensure that they are getting it.

Unfortunately, many service desks don’t make it easy to configure, track, or change SLAs, and offer little flexibility for reporting on them. In this article, we’ll discuss the importance of SLAs and good SLA reporting. We’ll also discuss why Jira Service Management is a better option for making, managing, and tracking SLAs than many of the prescriptive and over-engineered IT service management solutions out there.

What is a service-level agreement (SLA)?

A service-level agreement is an agreement between a service provider and a customer (internal or external) that identifies the services the provider will deliver and the level of service the customer can expect.

Most often we hear about SLAs in the context of IT service management (ITSM), specifying things like uptime, performance, and time to recovery after an outage. But they’re also used in other service industries, like facilities, specifying things like maintenance of lighting and heating and making sure rooms are properly stocked. And across all industries, SLAs define realistic deadlines for response and resolution and what the customer can do when requirements are breached.

The importance of SLAs

SLAs facilitate mutual understanding of service expectations. Implementing them can benefit service management teams in a variety of ways, including:

  • Easing concern over risk by defining what happens in the event of a breach, thereby reducing uncertainty and improving trust between parties
  • Enabling stakeholders to have structured conversations based on already-agreed terms, rather than letting customers stew over unstated expectations
  • Defining the urgency of incoming requests so that support teams can focus on the issues that matter most.

The importance of reporting on SLAs

SLAs are basically useless if your teams aren’t checking whether they’re complying with them. The only way service and customer satisfaction can be improved is by looking at what it is that needs improving.

Tracking whether you’re performing against your SLAs involves looking at reports. Reports on metrics like time to resolution, time elapsed, and SLA success rate enable you to identify areas for discussion and improvement, e.g. prioritizing certain types of tickets or allocating more resources to responding to them.

The importance of reporting on not just SLAs

Meeting your SLAs doesn’t necessarily mean you’re giving the customer what they want. It’s important for support teams to avoid the watermelon effect. This is when metrics appear ‘green’, suggesting that you have everything under control, yet digging beneath the surface reveals ‘red’, i.e. your consumers aren’t happy.

Illustration showing the watermelon effect, with a green metrics facade and a red true state of the operation

For example, you could be resolving issues within the time frame set out in the SLA, but perhaps you’re not resolving them satisfactorily. Metrics like time to resolution can sometimes have undesirable consequences because they incentivize teams to close tickets quickly, sometimes without addressing whether the customer is actually happy with the resolution.

This is why it’s important to look at customer satisfaction (CSAT) ratings alongside your SLA reports, to check whether customers are happy once their tickets have been resolved.

The problem with reporting on SLAs in most ITSM tools

For many service management teams, tracking SLAs is difficult. Managers often have to wade through tons of raw data, write custom queries, and build elaborate Excel formulas and reports to see how they’re performing against them.

The SLA reports that do come with many traditional ITSM tools and service desks don’t easily account for all the unique circumstances that influence SLA attainment. You met your SLA, or you didn’t. They don’t offer context as to why, which is the very thing support teams need to improve. Another reason why managers end up producing complicated spreadsheets that aren’t very effective because they require support teams to interpret the data.

Why Jira Service Management is great for making, managing, and reporting on SLAs

One of the best features of Jira Service Management (JSM) is being able to create the SLAs you want, the way you want them. In other ITSM tools and service desks, SLAs have to be custom- or hard-coded in, and it can take days of development to change them.

You can configure a new SLA in Jira Service Management in just a few minutes. You select the type of issue you want to track, how quickly you want to resolve it, and the conditions that will trigger the SLA timer to start, pause, and stop. For example, when you’re waiting for a response from the customer, or when you’re waiting for the customer to accept/reject a solution.

In JSM you’re able to set goals based on ticket priority levels and specify working hours accounting for holidays, lunch breaks, and weekends, so that the clock stops when your team is away. You’re also able to edit your Jira SLAs easily so that your team’s priorities remain completely aligned with changing business and customer needs.

Jira Service Management comes with several out-of-the-box SLA reports, but you can also create your own in the JSM Custom Reports tab. In a few clicks, you can make a good, basic line chart on any SLA you’ve created for a particular service project. And if you want to view the data across multiple projects, and visualize it in different ways (e.g. stacked bar charts), then our JSM dashboard reporting tool, Custom Charts for Jira, is just the ticket.

In a future article, we’ll talk more about the best SLAs for JSM support teams and how to implement them in Custom Charts.

Christopher is a self-confessed nerd who’d probably take the cake on Mastermind if Star Trek: Voyager was his specialist subject. He writes fiction about time travel, conspiracies and aliens; loves roller coasters, hiking and Christmas; and hates carpet, rom-coms and anything with chilli in it. He’s written extensively for technology companies and Atlassian partners and specializes in translating complicated technical concepts, specs and jargon into readable, benefits-driven copy that casual readers will understand.