Setting up SLAs
Jira Service Desk provides powerful built-in Service Level Agreement (or SLA) management so you can track your team's progress against agreements you've set for customers. An SLA is made up of two settings:
- A time metric, which lets you define how time will be measured for this SLA; and,
- A goal for selected issues, which lets you define a target for the time metric. Different sets of issues can have different goals.
On this page:
Jira Service Desk comes with a few pre-configured SLA metrics to cover some of the most common IT requirements; however you can modify or create custom SLA metrics to reflect the SLAs you use in your business. Jira Service Desk also provides robust reporting tools that you can use to track your team's performance against your SLAs. Check out Reporting on SLAs for tips on tracking your SLAs.
You must be logged in as a Jira Administrator or Project Administrator to configure SLAs.
Setting up SLA time metrics
You can think of the time metric as a stopwatch that tracks time between two points in an issue's life-cycle. Jira Service Desk lets you control exactly when time is tracked, letting you start, pause, and stop based on selected issue conditions. For example:
- In an SLA that guarantees issues are resolved in a certain amount of time, time starts when the issue is created and stops when the issue is resolved. You can choose to exclude time spent waiting on a customer by pausing the SLA on the Waiting for Customer status.
- In an SLA that guarantees a fast response time from your team, time starts when the issue status is Waiting for Support and stops when the status is Waiting for Customer. Each time the issue meets the start condition, a new cycle of the SLA will begin.
From your service desk project sidebar, select Project settings > SLAs > New Metric to fill in the following conditions:
| Condition | Description |
|---|---|
| Metric name | This name (e.g. Time to resolution) will appear to agents in the SLA section of issues, and should indicate what you're tracking. Note that you can't change the name of an SLA metric after you've saved it. |
| Start | Time starts being counted against the SLA whenever the issue has this condition (e.g. Issue Created) |
| Pause on | Time doesn't get counted against the SLA whenever the issue has this condition (e.g. Status: Waiting for Customer) |
| Stop | Time stops being counted against the SLA whenever the issue has this condition (e.g. Resolution: Set) |
Here's an example of the New Metric form:
Notice that you can set multiple conditions for the start, stop, and pause time. Check out Example: creating an SLA with multiple cycles for an in-depth look at how you can use this functionality.
Setting up SLA goals
While the time conditions on an SLA specify what your team considers to be trackable time, the goal section of the SLA metric lets you set the amount of time that's allowed for different scenarios. SLA goals can be in hours or in time increments less than an hour. For example, an SLA that guarantees issues are resolved in a certain amount of time could have the following goals:
- Blocker issues are resolved within 24 hours and Critical issues are resolved within 36 hours
- Blocker issues created by a member of the Build Engineering team are resolved within 12 hours, while Blocker issues created by a member of the Accounting team are resolved within 36 hours.
In the New Metric or Edit Metric screen, you can fill out the following fields to define a goal:
| Field | Description |
|---|---|
| Issues | You can enter specific issue criteria using Jira Query Language (JQL). Base goals on criteria that remain relatively constant throughout an issue's lifecycle (e.g. an issue's priority rather than its workflow status). |
| Goal | This is where you specify the target time for the SLA conditions you previously set. When specifying SLA goals that use a fraction of an hour, write the time as Xh Ym (e.g. 3h 30m). You can write SLA goals as hours and minutes, but not days. |
| Calendar | The calendar allows you to specify working hours when time can be counted against SLAs. |
You can drag goals in order of importance. An issue is tracked against the first goal criteria it matches on this list:
Creating SLA Calendars
By default, SLAs are measured against 24/7 working hours; however, you can use SLA Calendars to specify your team's working hours. For example, SLA calendars let you exclude lunch breaks, holidays, or weekends from the time that affects the SLA metrics.
Once you have saved your new SLA metric, select the Calendars button to add a calendar with your team's work schedule. The Sample 9-5 Calendar shown here can be edited to allow for a 1-hour lunch break that does not count towards the SLA goal. Simply delete the 09:00-17:00 line item and replace it with two line items (before and after lunch) for the same day:
Save your calendar and open an SLA metric to associate the calendar with one of your metric goals. Note that SLA calendars are unique to each service desk project. See Example: creating a basic SLA for an example of setting up an SLA that uses a 9-5 working day SLA calendar.
How your team sees SLAs
Your team members can see a read-only version of the SLA tab so they can view how the SLA is configured. In the detail view of issues, the SLA section lists even more detail about the SLA that the issue is being measured against:
Review the following sections for more detail on what the SLA tracker conventions indicate.
Ongoing SLAs
The SLA tracker uses colors to indicate the urgency of a given SLA for an issue based on the time remaining.
 | SLA has greater than 1 hour remaining. |
 | SLA has less than 1 hour remaining. If the SLA goal is one hour, the SLA has 30 minutes remaining. |
 | SLA has less than 30 minutes remaining. If the SLA goal is one hour, the SLA has 15 minutes remaining. |
 | SLA has breached the target. The amount of time past the goal is shown as a negative number. |
 | SLA has been paused. |
Completed SLAs
A completed SLA displays the time remaining when the SLA was completed (or the amount of time breached) and an icon to indicate whether the SLA was completed successfully or unsuccessfully.
 | SLA completed successfully. |
 | SLA completed unsuccessfully (it breached the target) |
Multiple SLA targets
If the issue meets the criteria for multiple SLAs, trackers for each SLA will appear. In addition, if the SLA has had multiple cycles, you can hover over the symbols for more details on how the SLA was met for that particular cycle. (For example, in an SLA that is measured based on when an issue is waiting for support, you can see whether the SLA was met each time the issue started waiting for support.)
SLA sorting
When you view a list of issues (in a queue or elsewhere), you can sort them by their SLA resolution times. Ongoing issues are listed first, with the shortest time remaining at the beginning of the list. Completed issues are ranked last but aren't sorted by the remaining time.
Managing SLA data
When new SLA metric names are created, new custom fields are created in Jira to store them. The type of these custom fields is SLA Custom Field Type. As a Jira administrator, you have the following options to manage the SLA custom fields.
Allow project administrators to create SLA metric names
New metric names create new custom fields. You can restrict the creation of them to only be available for Jira administrators.
- Choose
> Applications. Scroll down to the Jira Service Desk section and choose Configuration. - Use the Allow project administrators to create SLA custom fields option. If the setting is disabled, service desk administrators can only select from existing metric names when creating SLAs.
Clean up unused custom fields
You can find out if there are SLA custom fields that are not used by any SLA metrics and clean them up with one simple click. On the configuration page, the Number of SLA fields currently not in use menu shows the number of unused custom fields, if any. To delete them, click the Clean up button.
SLA usage notes
- Having the same user assigned to both the reporter and assignee roles may cause your SLA to work incorrectly.
- If you edit an existing SLA, Jira Service Desk will re-index all the existing issues in the project; the re-indexing will ensure that the SLA status on the open issues reflects any changed criteria. All the historical SLA data for elapsed time will be recalculated to measure against the new metrics. Note that the SLA status is only recalculated for open issues and not for resolved issues.
For example, when the goal for Blocker issues changes from 6 hours to 4 hours, all the closed issues are still considered having met the goal as long as they were resolved in less than 6 hours. This ensures that your reports on closed issues remain accurate for the issues' lifecycle. - If issue data changes in such a way that the goals for the issue change (for example, the priority changes from Critical to Blocker), the time against the previous goal will be tracked against the new goal. In other words, if the support team spent an hour on a Critical issue, when the issue is escalated to Blocker, the hour still counts against the new goal, even if it causes the SLA to be breached.
- Setting up a goal to be dependent on a different SLA is not recommended.