Adding business hours to an automation

[Cody Stevens]

Hello everyone, 

I have started this discussion because I opened ticket JSDCLOUD-6062. This is about adding an option to have the Time in Status automation count days as business days rather than business and none business days. 

The way we have our automation set up is after 2 days of the ticket being in Waiting for Customer it will transition to Inactive and then followed by Inactive 2 and Canceled.

This is a great feature and helps us not have to manage inactive tickets but the one drawback is if a ticket moves into an inactive status on a Thursday or Friday the process continues over the weekend when the person who has gone inactive is not working and it is not possible for them to reply. 

 If you agree that there should be an option for it to be counted over business days please go to the ticket and vote on it. 

[Meg Holbrook]

Hey there, Cody

This can easily be accomplished by tying your automation to an expiring SLA (tied to a calendar of hours):

[Meg Holbrook]

In this example, my calendar is set up with a typical spread of our business hours (7-5), and the clock starts each time the ticket enters that status. 

You could definitely set up a new SLA that starts each time the ticket transitions to make this work in your case. 

I'm not sure what the value add is for each of your status transitions through inactive. I set up 2 SLAs for our team, one of which is a ticket expiry notification at 8hrs in waiting for customer status and the other is the auto ticket closure at 16hrs in waiting for customer status. 

[Cody Stevens]

Hey Meg,

After setting up 3 different SLA's and automation this has successful worked. 

Thank you for showing me the correct way to do this!

[Meg Holbrook]

WOOHOO!

[Cody Stevens]

Hey Meg,

That is great information and I really appreciate it! I've started working on this and I am wondering if you have to make individual SLA's for each status change or if it can all be in one? 

So far I got it to work with a single status change but I have a total of 3. 

[Meg Holbrook]

I use one SLA for each status change. You could probably get it to work with one SLA, but it would have to 'restart' each time it hit your new status. 

Altogether, I'd say it's easy enough to manage for me in the multiple SLA route, but you may get some complaints about the SLA bar looking cluttered. Not a priority for me, but a consideration for others. 

[Corey Jepson]

My biggest problem with this solution is that I need the SLA to reset to 0 every time it has completed, otherwise when I use the SLA to ensure that customers respond in a timely fashion to any questions we have, the amount of time that the customer gets  to reply goes down each time because the SLA picks up right where it left off and not back at 0.

[Meg Holbrook]

Hey @Corey Jepson - Not sure what you mean by this solution incrementing the customer's response. 

The way I have this implemented, the 'timer' resets each time that status is changed. 

I'd recommend checking on your SLA criteria and making sure it's set to 'stop' and not 'pause' the SLA when it changes status.