Resetting the SLA clock in Jira Service Management (Service Desk)

[Matthew Rochman]

Hi All,

I have seen some different posts and questions and feature requests for resetting the SLA clock. There's lots of different scenarios for resetting the SLA timer and I'm sharing mine and the solution I developed which could be adapted to help others with similar scenarios. 

We have two teams using the one service desk. One team (TEAM A) looks after core hardware and desktop software, the other team (TEAM B) looks after internal apps like HR and data reporting systems. 

Sometimes, a request ends up with the wrong team, typically from the user accidentally using the wrong form. The first response SLA is 8 hours for both TEAM A and TEAM B. 

We had situations where TEAM A received a ticket, picked up for the queue after 6 hours then sent it over to TEAM B. In this scenario, it meant TEAM B had 2 hours to do their first response because it sat with the wrong team for 6 hours of the 8 hour SLA. 

This was not fair to Team B because they lost a chunk of their response time while it was with Team A. 

Accordingly I needed a solution whereby one team could somehow push the ticket to the other team and when this occurs, a new 8 hour clock begins. 

Because the start and stop of the SLA clock is driven mostly by workflow status changes, the solution involved adding new statuses. 

1. The starting status after the ticket is created is "Waiting for Support"

2. I added three new statuses:

   (i) Send to Team A

   (ii) Send to Team B

   (iii) Pending

3. I added transitions: 

   - Waiting for Support can transition to Send to Team A or Send to Team B (you can use conditions to sharpen and tweak things and I also include included a post function to change the custom field specifying the team assigned to the ticket which makes it then pop up the team queue). 

   - Both Send to Team A and Send to Team B transition to Pending. 

   - Pending transitions back to Waiting for Support. 

(yes it is circular)

4. I built an automation which is triggered when a ticket transitions to Send to Team A and another for Send to Team B. This automation moves the ticket to Pending and then moves the ticket back to Waiting for Support. 

5. I configured the SLA so the clock starts when the ticket is created OR when the ticket transitions to Pending. The SLA clock stops when ticket is assigned, commented on, transitions to Send to Team A or transitions to Send to Team B 

With all this in place, the SLA clock starts at 8 hours when ticket is created. If a team does a "Send to Team A" or "Send to Team B" transition, the clock then stops. When it auto-transitions to Pending, the clock resets to 8 hours and it is effectively in the right team's queue due to a post function change to a custom field specifying team assigned. 

Thought it was worth sharing - it's a bit long winded but the solution could be adapted and altered to different scenarios where the user needs the ability to reset the clock. Ultimately, workflow status additions are required.

[Dirk Ronsmans]

Hey @Matthew Rochman ,

This looks like a good solution on a technical level.

For me the main issue with the requirement/logic here is:

We had situations where TEAM A received a ticket, picked up for the queue after 6 hours then sent it over to TEAM B. In this scenario, it meant TEAM B had 2 hours to do their first response because it sat with the wrong team for 6 hours of the 8 hour SLA. 

This was not fair to a team that breached SLA when they lost a chunk of their response time while it was with the other team. 

reading this statement it just feels like you are using the age old way of looking at SLA's as a stick to beat the team that the ticket was with at the time of breaching. 

An SLA should be a "contract" you have with your business/end-users so they know what they can expect when it comes down to response times/resolution times/...

when a business/end-user chooses the wrong form/team this should not have any impact on the way the SLA is handled. Yes, most likely the SLA will breach and you would communicate this then to your end-user that the reason why this happened is that they have chosen the wrong form and thus you cannot guarantee the same (agreed upon) timeframe for response/resolution.

later in you reporting when you look at the breached cases you'll also be able to see why this was breached and either talk to Team A as to why it took them that long to re-assign or be able to refine your forms/investigate why the wrong form was chosen at the beginning at all.

If you keep resetting the SLA's, sure then you won't breach but then you are just fooling the system/yourself/the reports by just always making sure you reach the target.

I keep wondering to myself then, how will you have better customer service over time if you ignore what causes the breaches (since you don't have them). And also normally your SLA is agreed upon with the customer so if they need to wait another 8 hrs then you are dynamically changing that contract. Which doesn't make sense either. 

I feel like this should breach and the reason why/how this can be prevented in the future should be a collaboration and learning experience between your internal team and the customer.

But all in all, good technical solution :)

[Matthew Rochman]

Hi Dirk,

Yes very good and I left out one thing: 

I introduced a second SLA on all tickets which is time since ticket created with an 8h limit.

We were aware that the SLA is really when the customer gets the first response, not when the right team responds after it correctly makes its way to their queue, which could be 10-12 hours. 

And yes indeed - we look at tickets at end of month where the "overall" SLA was breached, but when Team A or B met their 8 hour response time from the moment in hit their queue. 

Bit of a double edged sword - if we make no allowance for resetting the clock in this scenario, one team looks like they breached when they really only had visibility for (sometimes) under an hour. But by resetting the clock, the responding agents feel like they're meeting their SLA even though the customer's overall SLA was breached and in the end, most customers don't care and don't want to hear about tickets being "stuck floating between two teams." 

It's kinda interesting how the discussions, thinking and works behind SLA implementation is much bigger and has many more curious scenarios that it seems at the outset.

Cheers Matt

[Jonathan V.]

I totally agree with regard to the approach, but as mentioned by Dirk, this can be a very slippery slope to go down and you can start to run into the "I only care about my queue" mentality, rather than an "I care about our customers" one.

If you have a lot of cases that fall into this situation, I would recommend implementing a user training program based on the findings of the monthly stats.

In one of my previous organizations, we had this occur and we implemented a process where "user error" cases were identified and then followed-up on, and additional guidance or training was provided. If the same person continued to make the same mistakes, even after multiple training sessions, we would escalate to their line manager so they could better guide/assist them, or coax them into doing what was really needed.

[Andreas Lärkfeldt]

You're able to Reset "custom fields" and therefor also SLA:s in Workflow transitions using Post Functions.

Does this work for someone? :)

[Jeff Gordon]

I'm curious how resetting a custom field value in a post function will feed into resetting the SLA timer.  I don't see that type of event listed under the choices for "Start" when defining an SDM SLA.

[Matthew Rochman]

Agree with Jeff - there aren't settings that allow you to reset SLA clocks on the basis of custom field changes. However, I suppose you could build automations or post functions based on custom field changes that do complete other actions that change the SLA clock, but that's a long way to go. Think about a new Jira administrator who may need to reverse engineer and maintain it down the track.