Originally published September 25, 2019, updated June 7, 2022

Great user experience doesn’t stand only for presenting an exceptional user interface, eye-catching graphics and helpful content. It also includes delivering high-quality customer service, which we can do by solving our clients’ problems within a specified deadline. Especially in industries like IT or telecommunication, companies define time-based goals for their support team and include them in the end-user license agreement. However, oftentimes, the customers are still clueless about how much time their service provider has to answer their requests, mostly because they omit reading that short piece of a contract they agreed to by clicking a Download or Try it for free button. That’s why, in this article, we take a closer look at what Service Level Agreements are and how to implement them in Jira Service Management.

Service Level Agreements define a time-based goal for a service provider, as well as the scope of actions a support team is obliged to perform whenever a customer comes to them with a problem. So, if a client finds a bug in our product and reports it, we have a specified deadline to meet. However, if there are any unrealistic time-based goals to accomplish, it may lead to a great hurry and mistakes like incorrect problem diagnosis, misleading solutions, thus resulting in an unhappy client.

A well-planned support process enables us to easily determine realistic deadlines for response, solution, etc. and set a doable SLA metrics comfortable for a support team and as fast as possible for customers. With this information, everyone will know when to expect a service desk agent to be assigned and even when a solution will be put forward. This way, we have a clear goal to reach, which will also help us deliver an expected customer experience.

Usually, ITSM software like Jira Service Management enables businesses to include SLA management in their processes and inform service desk agents how much time they have left to do a specific action. Below, is a short overview of how we can use it.

One of the key features of Jira Service Management is the possibility to configure SLAs as we see fit. In this case, we can define various SLA metrics for internal and external customers per project by going to the SLAs section in Project settings. In itself, it may be one of the ways to prioritize issues for each project. But, when setting up the time goals, there are also other conditions available, which we can determine using JQL criteria like assignees, components, creators and more. We can even define the triggers that will start, stop and pause the tracker, for example, as we wait for a customer to reply for a comment or when we transitioned the request and wait for a requester to accept or reject the solution.

Moreover, there are different units from years and months to days, hours and minutes, which we can use to make it easier on the users to read the timers, as well as include working hours and days. These settings are pre-defined by Jira, but we can change them to our preference in the Time tracking section of Issues settings in the admin’s menu. There’s also a possibility to extend them in the project settings by creating calendars, which will include business hours, holidays, and various time zones to ensure that all customers are provided with support on time.

The whole configuration of a new SLA takes only a couple of minutes. We need to:

Additionally, we can set a Keep on top of SLAs automation rule that will help us sort through all the tickets and focus only on those with less than 30 minutes remaining. Also, service desk agents can make good use of native Jira Service Management queues in which they can add specific SLA metrics to triage the customer requests within the queue. 

However, there are also limitations because SLA metrics are only visible for Jira Service Management agents on the issue view and queues screen. This means that customers and employees without an agent’s licence won’t be able to see how much time an agent has left to give them the first answer or provide them with a solution to their problem.

Even though the first response to the issue should be at most within 24 hours, a majority of clients probably isn’t even aware of that. That’s why such information like when to expect the answer for a request is quite important for service desk customers. We aren’t able to make SLA timers visible for them natively, but we can use such apps as Extension and My Requests Extension for Jira Service Management to extend the native possibilities.

With the Extension app, we can not only create more intuitive request forms and extend other Jira Service Management functionalities, but also display specific SLA metrics on the Customer Portal to chosen user groups with Visibility feature. This way, only users from the selected groups will be able to see the timers, and other users won’t. To extend the visibility of SLA timers to the Customer Portal:

Additionally, the app provides us with extra post functions dedicated to SLA, which we can add to Jira workflows. These include restarting the timer after doing a specific transition and updating SLA metrics based on values provided in Due Date, Satisfaction date, Date and Date Time Picker fields. To set up the post functions:

Similarly, with My Requests Extension for Jira Service Management we can display SLA field as default column on the requests list or enable customers to add it as a column there. Just like in case of Extension, we can also limit the visibility to specific user groups. The difference here is that this app gives users the power to decide which fields will be visible on their list and save their setup as a filter. To configure the app, we need to:

Also, we can extend queues functionality as well as conditions and actions for automation rules. The former is possible with Queues for Jira Service Management, which enable us to create cross-project queues, hide the unnecessary ones and use JQL criteria to specify what issues from which project should be included. This way, the list of customer requests service desk agents need to take care of gains structure and makes it easier to set priorities if tickets from one project are more important than from another or they’re scattered across various projects and we want to have them all in one place. Moreover, we can sort the tickets within the queue by remaining time to resolution to have all the pressing issues listed first. By default, link to the Queues is located on the global navigation bar and in the sidebar of all service desk projects. To add queues to the app, we should:

When it comes to automation rules, Actions for Jira Service Management adds conditions like Reporter language and Reporter Email Contains and actions to perform, including Assign User to issue, Set priority to issue, Add request participants, and more. Thanks to these, specific issues will be immediately assigned to the right agent or even to a support leader if the reporter’s email contains a value specified in the automation configuration. To add this specific rule:

As a result of extending all these functionalities, we gain well-structured queues containing information about the remaining time for a specific action, an automated process focused on SLAs close to breaching and informed customers.

Including SLAs into service desk processes may help us a lot in guaranteeing optimal service quality. Thanks to specific time-based goals, we can easily find areas which need improving, as well as better manage priorities with separate deadlines for selected issues. Moreover, Jira Service Management helps our agents not only with SLA metrics which they can view on their queues but also with their color that changes depending on how much time remains for a specific action to be completed. This way, whenever a service desk agent sees a yellow timer, they know they have to speed up to provide the requester with satisfying service. Just remember, realistic deadlines and SLA timers accessible for clients make for productive agents and happy customers.