Custom Jira SLA's part I - Time to SLA for Offline Services

What if you offer service level agreements (SLA's) but you can't act on them in real-time? In this blog, we want to tell you about one of our customers that is maintaining hardware in pretty extreme circumstances. In their case, on-site repairs cannot be logged directly due to internet restrictions (think highly secure and/or remote locations). 

Also, the SLA goals, in this case, are not related to solving X number of issues within Y % of time, but rather, they relate to hardware being offline for a maximum of X minutes per period.

Jira Service Desk SLA's

Let's first see how Jira Service Desk determines it's service level agreements;

With Jira Service Desk, you can keep your team on track by setting goals for how quickly you manage customer issues. If these goals are set by your customer contracts, you might know them as Service Level Agreements, or SLAs.

SLAs track the progress of things like:

• Respond to all requests within 2 hours.
• Resolve high-priority requests within 24 hours.

In short, in Jira Service Desk, SLA's are measured with the time between transitions. As a consequence of this tracking method, SLA's cannot be changed afterwards, e.g. changing the date/time after an issue was resolved. 

So, back to our use case... An engineer goes on-site and fixes some equipment that wasn't working properly. The engineer, however, does not have internet access and cannot resolve the issue yet. He has to wait until he can access the internet again, or even for when he's back at the office. Therefore the  SLA report won't be accurate and it is probable that the SLA goal in Jira is exceeded because of this.

Measure on date & time custom fields

For this specific use case, we're talking about SLA goals that go down to the minute. Not meeting these SLA goals could result in serious penalties. To solve the issue, we want to measure on the time elapsed between two date & time fields:

• Incident occurred since (date & time)
• Incident occurred until (date & time)

We also want to keep track of the time an issue has been paused (as in "waiting for the customer"), so that time gets deducted from the time elapsed between the report and resolution.

Time to SLA

To solve this specific case we've implemented the app Time to SLA which works for any Jira project type (Software, Business and Service Desk).

Because the customer wants to keep track of elapsed minutes and because the standard SLA goals are unusable in our case, we've set it up like this:

Great! We can now track the elapsed time, based on two date & time fields, which can be filled in by an engineer after the work is done (and verified/approved by the customer). 

We've mentioned earlier that for this case, the standard SLA goals are unusable because they are calculated on transition... are you curious to know how we've managed to keep track of SLA goals by determining the remaining minutes available within the SLA? Then read the upcoming part 2 of this blog series! 

Do you need Atlassian expertise? We're here to help you with all your Atlassian challenges!

Get in touch!