SLAs explained
Some service contracts involve agreements on response times, or SLAs (Service Level Agreements), to solve requests. Teams and customers need this information for each request in order to better handle priorities and guarantee optimal service quality. But that’s not all – SLAs can also help identify areas for improvement.
The good news is that JIRA Service Desk has got you covered. Why? Because it allows you to set SLAs per project, and display them on your tickets in the form of a little timer counting down the remaining time.
Note:
- If the SLA is defined at 1 hour, for example, then the icon colour will be grey when they are 30 minutes left, and change to orange when only 15 minutes remain.
- It’s possible to display as many SLAs as you want on the ticket (yeah, as many as you want!)
Before I tell you more about the set up, let’s have a look at different views, and how SLAs display on them.
View on the request
View on the portal
Natively, JIRA Service Desk does not allow you to see SLAs on the portal. With Valiantys IT Service Management solutions however, you can preview SLAs directly from the customer portal. Awesome, isn’t it? To obtain this render, you’ll need the additional component called Extension.
Setting up an SLA
Now, let’s talk about the serious stuff – SLA settings.
An SLA first possesses a nam, which will be displayed on the JIRA request. It’s important to pick its name carefully so that it’s accurate and easy to understand for everyone involved.
An SLA is calculated between two events. It can also be paused when the request enters a particular state.
Events are not configurable. Triggering and stopping events can be:
- Entering a state in the workflow
- Filling or clearing the Resolution field
- Unassigning a ticket
- Assigning a ticket – whether the request was previously unassigned or assigned to someone else
- Adding a comment for the customer
- The addition of a comment by the customer
Events that can pause an SLA are:
- Entering a certain state in the workflow
- Filling or clearing the Resolution field
- Unassigning a ticket
- Assigning a ticket (only when the request was previously unassigned)
It is then possible to define as many SLAs as you wish. The execution criteria are defined in JQL and can thus be based on native or custom JIRA fields values. Usually SLAs are configured on a specific request type and on a specific priority.
The amount of time during which the SLA is running is defined by the calendar. You can create as many as you need.
Remember to give it an easy-to-understand name so that all of your agents and customers get it instantly when they see the icon calendar on the SLA displayed on the JIRA ticket.
Specific cases
Change in a criteria linked to the SLA
If a change occurs on a ticket’s criteria which is also an SLA criteria (for example, priority), then the SLA will be actualised:
+ The priority was high…
+ … and is now low
SLAs measuring a loop
If the SLA is configured to measure the time between two states, for example ‘Open’ and ‘Waiting for customer feedback’, it can sometimes be measured several times. Indeed, this transition can occur several times on the same request.
The SLA is designed to handle multiple measurements. A little icon that you can run your mouse over allows you to see the different times captured.
Reporting on SLAs
SLAs are like any other fields, and can be integrated to your searches.
In your requests:
And in your queues:
JQL queries
In search, you can find specific instructions regarding SLAs and apply them to any SLAs you are creating (e.g. “Time to resolution” = paused().
Here’s a list of the commands you can run:
running(): find JIRA tickets on which the chosen SLA is currently running.
paused(): find JIRA tickets on which the chosen SLA is paused.
completed(): find JIRA tickets on which the chosen SLA has been reached (the terminating event has happened), whether it has been respected or not.
breached(): find JIRA tickets on which the chosen SLA has not been respected, whether the SLA is still running or terminated. If the SLA has been restarted several times (specific cases seen before) , only the JIRA tickets in which the SLA was breached in the last SLA cycle will be displayed.
everBreached(): find JIRA tickets on which the chosen SLA has always been breached (same as breached() but on all “JIRA cycles”).
elapsed(« <Time> »): find JIRA tickets on which the chosen SLA has been running for X time, for example: Time to resolution < elapsed(« 2h »)
remaining(« <Time> »): find JIRA tickets on which the remaining time for the chosen SLA is of X time, for example: Time to resolution < remaining(« 20m »)
So there you have it – everything you need to know about SLAs! Any questions or comments, leave them below and I’ll get back to you.
