Why SLAs don't work correctly – most popular mistakes in Jira Cloud

[#1]

Service Level Agreements (SLAs) are required to maintain customer satisfaction, and setting them up properly is essential for effective and timely problem resolution and avoiding overruns. However, probably everyone who tried to set up SLA and automation in Jira Cloud at least once at some point sadly looked at the screen with the words "What's wrong, why don't you work correctly?!".

 

I did this more than once :), so I decided to help prevent these mistakes by writing this article. Below you will see a list of the most popular errors according to the version of the ChatGPT, my personal experience, and quite a long time of monitoring the community about SLA. I will show examples of "how it should be right" using the SLA Time and Report for Jira add-on. Enjoy reading.

Options of “Why”

1. Misconfigured Working Hours for SLAs: if you would rather not get a notification about breached SLA goals at night on Sunday, check the Work Calendar to be sure there are correct working days and hours. Create different Calendars for each time zone, 24/7 or for “out of office hours”, and for regular working hours to avoid date format inconsistencies.
2. Inconsistent SLA Enforcement: In some cases, SLAs are not consistently enforced due to misconfigured or conflicting automation rules. It's important to review and test the automation rules associated with SLA management to ensure they work as intended and don't interfere with each other.
3. Misconfigured SLA Goals: One common mistake is setting unrealistic or incorrect goals for SLAs. It's essential to carefully define and set the correct response and resolution time targets based on your team's capacity and business requirements. For example, if your support team takes an average of 1-2 hours to respond to a customer, there is no reason to set the first SLA goal with notification 15 minutes before the Time to First Response deadline is breached. Set several SLA goals with triggers at 1 and 2 hours so that they definitely have time to give a competent answer. 
   
4. Creating SLA with too many SLA goals: sometimes, separate SLA configurations for different priority levels or issue types are advisable to maintain better control over SLA compliance. This approach allows teams to effectively manage the time taken to address each specific priority level or issue type independently. 
   
   In the article "How to configure SLA Time for the Support team in Jira Cloud" we already show a good example how to configure SLAs for all Priorities for the Support team.
   
   
5. Mistakes in JQL: this is an eternal problem for configuring SLAs and trying to get a list of tasks according to the SLA. Unfortunately, there is no magic solution except to refer to the Atlassian documentation and more experienced users. The only thing that helps me avoid this problem is using the SLA Time and Report add-on, where the expanded functionality does not require knowledge of JQL and allows you to choose the desired values in the fields of configurations and filters.
   
   
   
6. Insufficient Training and Documentation: Team members need to be adequately trained on SLA configuration and usage in Jira Cloud to avoid making mistakes or overlooking important settings. Remember, it's always a good idea to refer to the most up-to-date resources available, such as the Atlassian Community or official documentation, to stay informed about any changes or updates related to SLAs in Jira Cloud.

Conclusion

Properly configuring and utilizing SLAs in Jira Cloud is crucial for effective issue management and customer satisfaction.

If you feel that some difficulties are not being solved quickly enough, consider using third-party applications to simplify and improve the work. Problems with the SLA can cost you losses or even a client, which is more than the price of subscribing to add-ons. In addition, there is always a 30-day trial period during which you can weigh all the pros and cons.

[Jimi Wikman]

It is also important to make sure you have a SLA strategy since all SLA's created are custom fields and they have a tendency to pile up a lot of custom fields when left unchecked.