Custom Jira SLA's part I - Time to SLA for Offline Services
Door Patrick van der Rijst / jul 2020 / 1 Min
Door Patrick van der Rijst / / 3 min
In part 1 of this blog, we described that the SLA solution Jira Service Desk offers does not work for everyone. Certainly not for cases where you deliver support on-site and offline. As explained, for cases like these, we use the app "Time To SLA".
In this part of the blog, we will further explain how we managed to implement SLA goals using elapsed minutes instead of time between transitions, by using another app: "Insight Asset Management".
Most often we see requirements for SLA goals like these:
Priority | Reaction | Scheduling | Resolution |
---|---|---|---|
High | Within 1 service hour | Within 2 service hours | 98% within 8 service hours |
Medium | Within 4 service hours | Within 8 service hours | 95% within 24 service hours |
Low | Within 8 service hours | Within 40 service hours | In consultation |
For our use case, we're working with SLA goals that look like these:
Device type | Available minutes per period | Fixed/per device |
---|---|---|
Phone | 500 | Per device |
Computer | 1000 | Per device |
Network | 5000 | Fixed |
When a location has 3 phones and 5 computers for example, you have a total of 1.500 phone minutes, 5.000 computer minutes and a fixed total of 5000 network minutes available per period. So how can you store this in Jira...?
We've chosen the app Insight - Asset management to store this kind of information.
Another way to implement this would be to use custom Jira issue types and the relevant custom fields. The problem is then that you'd have to find another solution to show remaining SLA minutes within support issues and such.
Insight Asset Management allows you to create your own custom Objects with your own defined Attributes... We use it for many cases but found it very useful for this one.
Here are the Object Types we've configured;
Type group
Site
Service Level Agreement
Based on the information we have available, we can create custom fields that are used as references to these Insight Object(s). By using auto-assign options or scripts, the correct Objects are automatically shown within the support issue. This saves you a lot of manual work and time!
When an issue is moved from Resolved to Closed, the issue becomes immutable and we can gather the information from the ticket to calculate the time we need to deduct from the Service Level Agreement object.
We've set up various Custom fields to determine the number of devices that are impacted and Scriptrunner Script Fields (yes, this is another app) to calculate the total number of minutes that should be deducted. This provides some live insights in what will happen once the issue is closed.
Both of the apps 'Time to SLA' and 'Insight' offer API's for 'Scriptrunner' to integrate with a simple Groovy code snippet. In this way, we are able to fetch the total minutes elapsed and we can deduct that from the Insight's object (available minutes) attribute.
The total of minutes remaining is still not 100% live as you're working with tickets that are in progress, but it gives a good idea of contracts that are about to breach.
We know this is a bit of an unusual case, but we hope this will be useful to some. It does show, in any case, the flexibility apps can add to the Atlassian products.
If you're interested in this particular use case or would like to see how we can help you tackle your own tough cases, then get in touch with us!
| Atlassian
Door Patrick van der Rijst / jun 2023
Dan denken we dat dit ook wat voor jou is.