Practicality of having a 24 hour SLA for "task update" goal.

[David Quiram]

My boss would like to have a 24 hour SLA to help the team keep on top of performing a daily update on tickets. He likes the visual of having the SLA timer on the screen when you are looking at a task and seeing how long you have on the timer. 

He would like the feature to function in a way where when the agent performs an update on the task, the timer gets reset and a new 24 hour timer is started. 

This works in the scenario of just performing a reply to the end user within 24 hours and having automatic status transitions. Using statuses like "Agent Updated" and "Employee Updated" for direct examples. 

What makes this a little more complicated is sometimes we have to perform research, testing, and some planning on some requests. In those instances we wouldn't have an update for the user to perform that status change. We might end up using a couple of different statuses to indicate what's going on with the task, but he would still like an update on the task every 24 hours. 

I tried some testing using internal/external comments to flag the SLA to start/stop, but it would require two SLA timers to juggle which one was counting. A single comment trigger couldn't be used to both stop an SLA and start a new instance of the same SLA. 

Right now I have a temporary solution of automated comments if a task wasn't updated in the past 24 hours, but isn't not the mechanical SLA function that he would like to utilize. 

Is there a way to achieve what my boss is wanting with the native SLA functionality? 

[Gabriela - LeanZero]

Hi @David Quiram, you can get there natively, but it has to run on status changes. In the research case there's no customer-facing update, and every comment condition keys off the customer, so nothing fires. Internal notes aren't selectable at all, closest request JSDCLOUD-11212 is still Gathering Interest. Custom fields can't drive conditions either, JSDCLOUD-2297, Reviewing with 413 votes since 2015.

Your status half already works, so build on that. Start it on entering every status that means the ticket's with you, research and testing included, and stop it on a throwaway Reset status. Then a rule on any comment, internal included, that saves the current status to a variable, transitions to Reset, and transitions back to the saved one. That's the two events one comment could never give you.

Your comment-driven transitions fire on the same comment, so check they don't fight over the status. I'd try it on one request type first. JSDCLOUD-194 is closed as fixed, but that shipped as a Recalculate SLAs button, which recalculates against your config. It doesn't restart a timer.

Pause conditions are the other half, or the clock runs down while you're waiting on the employee. Which of your statuses are those?

[David Quiram]

We would want a pause condition on the SLA timer. The 24 hour countdown is just to keep us on top of our own work. Your process for status juggling is clever! When time allows I'll implement that in my test project to see it in action. 

With the status juggle in action, I have the idea now to repurpose my current 24 hour update automation to be user facing. Automatic reminders to them, instead of us, that there was a pending update, re-paste the last comment we gave, then maybe using labels implement a three strike and auto-close process. 

[Gabriela - LeanZero]

When you run it in the test project, the reset lands as a new cycle rather than a continuation of the old timer, which is where the fresh 24 hours comes from. The old ones aren't lost. Expand the SLA name in the SLAs panel and each past cycle sits there with its elapsed time and whether it breached, so the juggle leaves you a reset history on the work item. Agent view only though, customers don't see past cycles.

https://support.atlassian.com/jira/kb/can-slas-have-multiple-cycles/

[Alina Kurinna _SaaSJet_]

Hi @David Quiram 

The native workaround suggested above can work, but it does require an additional Reset status and automation transitions each time an update is added.

Another option is to use an SLA app that supports resetting the same timer based on a comment. For example, in SLA Time and Report, which my team developed, you can use the app to configure:

• a 24-hour time-limit SLA;

• Start conditions for the statuses where the task is actively owned by the team;

• Pause conditions for statuses such as Waiting for Customer;

• Comment from Assignee as the Reset SLA condition;

• Add automated actions when SLA is breached, such as changing status, priority, etc

With this setup, an internal or public comment from the current assignee resets the existing timer. If the task still matches the Start conditions, a new 24-hour countdown begins immediately. This means the team can record a meaningful progress update during research or testing without moving the task through a temporary Reset status.

If you have any additional questions, I will be happy to help!)

Regards!