How Atlassian Support configures SLAs in Jira Service Desk

Atlassian Support is a global operation. With six regions, 24/7 availability, 15 products, cloud and server deployments, and different support tiers, we have a complex set of rules and logic about ticket routing. But even with our complex ticket routing system, getting the right engineer on the job in a timely manner for round-the-clock support requests can be difficult.

We started using service-level agreements (or SLAs) in Jira Service Desk to improve this process. Here’s how we did it.

Finding the balance between key response time metrics

Every customer wants quick response times and resolutions in as little time as possible. That’s why a lot of companies offer Initial Respond Time (IRT) commitments and 24-hour support (like our comparison chart). However, we also know measuring only response times can lead to sacrificing quality, and what customers really care about is a full resolution. That’s why support organizations measure Overall Resolution Times (ORT) as well.

We use three key principles to achieve a healthy Overall Resolution Time:

1. Getting the ticket assigned to an engineer in the same timezone as a customer
2. Assigning a ticket to a support engineer with the knowledge and skills to help
3. Maintaining the assignment throughout the lifecycle of the ticket.

We recently discovered we could do this more effectively by changing our IRT commitments to a 9-by-5 schedule. We allow a ticket to go unassigned if we miss it in the initial shift. Our Select Support offering optimizes getting to the right assignee, rather than responding quickly but without the right solution.

Making the switch to in-timezone support

Our 9-by-5 support offering is actually a global offering. Rather than a simple 9 by 5 from one office, we offer 9 by 5 by timezone.

For example, if you’re in Sydney (GMT+11), you’ll get timezone support between the hours of 8 a.m.-5 p.m. local time. Similarly, if you’re in Western Europe, or Central US time, you’ll get 8 a.m.-5 p.m. support in your local timezone as well.

We’re doing this is to improve the smarts, to optimize for the likelihood you’ll get a support engineer in your timezone (which we know will help for a faster resolution).

As an example, let’s say a customer opens up a non-critical ticket towards the end of their day. With our prior 24-hour counter in place, the IRT counter would start ticking right then.

For Level Three tickets that had an eight-hour time commitment filed at the end of the day, those tickets ended up in a no-win situation. Either they get picked up by the wrong team (a team in the next geo over, not co-located) or wait until the next day and breach the initial response time. 

Through experimentation and research, we learned that customers in this situation were better off waiting until a support engineer in their geo was available to take the ticket. So, we changed our IRT commitments to optimize for this. With Select Support, the ticket gets designated for the right timezone, and the IRT clock will start ticking relative to that geo. 

The key insight is this: if we’ve missed a critical window while our customer is available and ready for a response, we are better off waiting to assign the ticket to someone who with the right skills in the right timezone than we are getting a quick answer. By changing the expectations on the initial response time, we’re better able to optimize for this ideal setup for the lifetime of the ticket.

Additionally, we optimize for people who work non-standard shifts. We’ve added a question to our contact forms asking customers to select their working hours. If they indicate non-standard hours, we’ll map their working hours shift to our shift that’s closest, thereby increasing the odds of working hours overlap.

The SLA configuration

Here’s how we’ve implemented it. First, we figured out the timezones where most of our customers are located.

9/5 Support – Hours of coverage include 8am – 5pm for the following timezones: Pacific (UTC-8), Mountain (UTC-7), Central (UTC-6), Eastern (UTC-5), Western Europe (UTC+0), Central European (UTC+1), Eastern European (UTC+2), Eastern Europe Forward Time (UTC+3), Australia Western Standard Time (UTC+8), Australia Central Standard Time (UTC+9), Australia Eastern Standard Time (UTC+10). India is covered 10am-7pm (UTC+5.5). Japan is covered 9am-6pm (with Japanese language support). Tickets will be handled in the office corresponding to the geo in which they are submitted.

Once we did that, it was simple to configure the SLA:

After figuring this out, setting up the SLAs was a breeze.