Kennis Blogs Custom Jira SLA's part 2 - SLA Goals using elapsed minutes instead of resolution times

Custom Jira SLA's part 2 - SLA Goals using elapsed minutes instead of resolution times

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".

 

SLA goals

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.

 

CMDB with Insight

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;

  • The customer location, named Site, also containing the number of devices a site has
  • The Customer itself, which are actually Jira Service Desk Customers. This object can be used to have Customers select their associated Site
  • Type Group, which are the devices we've mentioned like Phone, Computer and Network. This makes it possible to keep track of the available minutes per device type.
  • Service Level Agreement which holds a calculation (for example: site.number of phones * type group.phone.available minutes and a start / end date). The start/end date is also used to generate new Service Level Agreement objects once the end date is due and the contract is reset. 
test

typegroupType group

site typgroupSite

SLAService Level Agreement

 

The agent perspective

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!

 

phones not working issue type

 

Calculation

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.

 

calculate scriptrunner field

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!

 

Get in touch!