Setting up SLAs

Keep your team on track by setting goals for how quickly you respond to and resolve tickets. If these goals are set by your customer contracts, you might know them as Service-Level Agreements, or SLAs. For example, they may track goals to resolve high-priority requests within 24 hours or to respond to all requests within 2 hours.

Once you set SLAs, you can view them in queues and on issues. You can also get alerts for SLAs that are about to breach and create reports to track SLAs over time.

Set SLAs

When you set an SLA, you choose two things:

  • A goal.

  • How you count time to the goal.

Service desk project administrators can set SLAs.

To set an SLA:

  1. From your service desk project, select Project settings () > SLAs.
  2. Click +New Metric.
  3. You won't be able to change the Name of your SLA, so enter one that clearly explains what it measures.

Set a goal

In the Goals section, choose the type of issue you want to track, how quickly you want to resolve it (the goal), and your working hours (calendar). Here are some examples of goals you might set:

  • Resolve blocker issues within 24 hours

  • Resolve blocker issues created by the Build Engineering team within 12 hours, and resolve blocker issues created by the Accounting team within 36 hours

It's a good idea to base goals on criteria that don't change throughout the issue's lifecycle. For example, don't create goals based on issue status.

To set a goal:

  1. Under Goalsuse JQL to define the Issues you want to track. For example, priority = Highest means that you're setting a goal for issues that have their priority set to highest.
  2. Enter the Goal in hours and minutes. For example, 30m1h15m48h30m, or 72h.
  3. Choose which work Calendar to follow. By default, SLA clocks run 24/7. If you want to exclude lunch breaks, holidays, or weekends, select Calendars to set your working hours.

For example, here's a goal to resolve issues in different time frames for different customers. In this example, you provide 24/7 support for Gringotts Bank, and 9-5 support for Stark Industries:

Note that when an issue matches the Start condition, the SLA starts counting time on the first goal that matches the issue. If an issue matches more than one goal, the SLA tracks the first one in the list.

  • You can create 30 SLA goals per project. If you need more, see if you can combine goals, or delete ones you don't use anymore.
  • If the same user is both the reporter and the assignee on an issue, then the SLA might not track it correctly.

Set a time metric

The time metric is like a stopwatch that starts and stops the countdown to your SLA goal. For example, you might pause time while you wait for the customer to respond, and stop time when the issue is resolved. The calendar counts time according to your team's schedule. For example, you might pause it outside of business hours, or during holidays.

To set a time metric, choose conditions for StartPause on and Stop to determine when you start, pause and stop the countdown to your SLA goal. These conditions are read as or, not and. For example, if you add two Start conditions, the SLA will measure time when an issue meets either of these conditions. 

For example, the goal of this SLA is to respond to Access issues within two hours. This includes responding when the issue is created, as well as when the customer updates the issue:

Set your working hours (optional)

By default, SLA clocks run 24/7. If you want to exclude lunch breaks, holidays, or weekends, go to SLAs > Calendars to set your working hours.
For example, you could tweak the Sample 9-5 Calendar to add a 1-hour lunch break that doesn't count toward the SLA. Just delete the 09:00-17:00 timeframe and add a timeframe for before lunch (08:00-12:00) and after lunch (13:00-17:00). Here's what it looks like:

What happens to SLAs if they change

If you edit an SLA, Jira Service Desk recalculates time for all issues in the project that have ongoing SLA cycles but doesn’t recalculate time for completed SLA cycles.

For example, you might have a goal to resolve all Blocker issues in 6 hours. If you change the goal to 4 hours:

  • Blocker issues that have been open for more than 4 hours are marked as breached.
  • Blocker issues that were resolved in under 6 hours have still met the SLA.

What happens to SLAs if requests change

You might update a request in a way that changes which SLA it's measured against. If you do this, the SLA clock doesn't restart but adds any elapsed time to the new goal. In some cases, this might breach the SLA.

For example, imagine you have a goal to resolve Critical requests in 5 hours, and Blocker requests in 3 hours. A Critical request has been open for 4 hours, and someone changes the priority to Blocker. Because the request is now a Blocker request with 4 hours on the clock, the SLA is breached.

Manage SLA data

If you create a new name for an SLA metric, the name—not the metric—is copied to all service desk projects on your Jira site and stored as a custom field. For example, if you create a metric called Time to resolution by priority, other service desk projects can create metrics with that name:

Jira administrators can choose who has permission to create new SLA metric names. You can also view the number of fields being used and clean up unused fields.

To manage these settings:

  1. Choose  > Jira settings > Products.
  2. Under Jira Service Desk, select Configuration.
  3. In the SLA metric names section, you can change who can create new SLA metric names. If there are SLA custom fields not in use, click Clean up to delete them.
Last modified on May 15, 2019

Was this helpful?

Provide feedback about this article
Powered by Confluence and Scroll Viewport.