Service-level agreement or SLA defines the agreement between the service provider and end user in terms of aspects of the service provided, such as its scope, quality, or turn-around time.
In the context of support service, an SLA will define different response times for different types of support requests. For example, severity 1 requests will have a response time of 1 hour, and severity 2 requests will have a response time of 4 hours.
JIRA Service Desk lets you define SLA requirements based on response time. You can set up the rules on how response time will be measured, and goals for each rule.
JIRA Service Desk's SLA is divided into two components, the time measurement and goals to achieve. Time can be measured for a variety of purposes. Common examples include overall time taken for request resolution and response time to customer requests. To set up SLA metric, follow these steps:
- Browse to the project administration page for the service desk you want to set up the SLA on.
- Select the SLAs option from the left panel and then click on the New Metric button.
A simple example will be JIRA Service Desk starting to count time as soon as the request is created. Every time an agent requests for more information from the customer, the count will be paused until the customer responds back. Once the request is finally closed off, the count will be stopped. The following points shows you how to set up an SLA time measurement for the simple example:
- For the Start column, we will select the Issue Created option, indicating that it can start counting time as soon as the request is created
- For the Pause on column, we will select the Status: Waiting for Info option, indicating that the counting can be paused when the request enters the Waiting for Info status
- For the Stop column, we will select the Entered Status: Closed option, indicating that the counting will be stopped once the request is closed
As you can see in the following screenshot, for each of the three columns, you can select more than one condition:
This allows you to set up multiple entry points to start and stop time. An example of this usage will be to measure response time. For example, you will need to guarantee that an agent will respond to a new request within an hour. If the request is sent back to the customer for further information, a response time of one hour is also required as soon as the customer updates the request with the requested information. The following points shows you how to set up the time measurement for this SLA:
- For the Start column, we will select both the Issue Create option and Entered Status: In Progress option. Therefore, we will start counting when the issue is first created, and also when it is put back for our agents to work on.
- For the Stop column, we will select both the Entered Status: Waiting for Info and Entered Status: Closed option. Counting will stop when an agent sends the request back to the customer for more information or when it is closed for completion.
The difference between the two examples here is that, in the second example, we do not pause time counting when the request enters the Waiting for Info status; instead, we stop counting completely. This means that when the request enters the Waiting for Info status, the current counting cycle ends, and when the request enters the In Progress status, a new counting cycle will begin, as shown in the following screenshot:
Once we have defined how time should be measured, the next step is to set up the SLA goals. The SLA goals define the amount of time allowed for each of the scenarios we have just set up. If we take the aforementioned response time example, we may set up our goals as shown in the following screenshot:
In our example, we defined that for requests with priority set to Highest, the response time will be 1 hour (1h); High requests and Medium requests will have a response time of 4 and 8 hours, respectively. Everything else will be responded to within 12 hours.
As you can see, there are several components when it comes to define an SLA goal, which are as follows:
- Issues: These will have the goal applied to them. Use JQL to narrow down the selection of issues.
- Goal: This is the time value for the goal. You can use the standard JIRA time notation here, where 3h means 3 hours, 45m means 45 minutes, and 2h30m means 2 hours and 30 minutes.
- Calendar: These define the working days and hours SLA will be applied to. For example, 24/7 Calendar means that time will be counted every hour of every day. As we will see later, you can create your own custom calendars to define your working day, hours, and even holidays.
When defining SAL criteria, we will need to use JQL. Just like doing advanced search, JIRA Service Desk provides syntax autocomplete to help us validate our queries, as shown in the following screenshot:
As we have seen, when setting up SLA, you can select a calendar that defines the working days and hours, which can be counted toward the goal. JIRA Service Desk comes with a Sample 9-5 Calendar out of the box, which will only count the time between 9 AM to 5 PM, from Monday to Friday.
You can create your own calendars as follows:
- Browse to the project administration page for the service desk you want to add a calendar for.
- Select on the SLAs option from the left panel.
- Click on the Calendar button, and then click on the Add Calendar button from the dialog box.
- Enter a name for the new calendar and configure the options.
- Click the Save button to create the calendar.
JIRA Service Desk lets you configure your calendar with the following options:
- Time zone: This selects the time zone that will be used for the calendar
- Working days: This select the days that can be counted toward the SLA
- Working hours: These are the hours of each working day that can be included in SLA
- Holidays: This adds holidays such as Christmas to be excluded from the SLA
As shown in the following screenshot, we have set up our calendar to have working time between 9A.M. to 5P.M., from Tuesday to Friday; this means Monday, Saturday, and Sunday are excluded when calculating SLA metrics. We also added Christmas Day and New Year Day as holidays, so the SLA will not be applied on those days:
