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.
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
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.
You're able to Reset "custom fields" and therefor also SLA:s in Workflow transitions using Post Functions.
Does this work for someone? :)
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.
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.