Set up On Hold Status Reminders

Hi DJ,

Thanks for the additional information on your workflow! I definitely understand the desire to be able to use a due date. As of right now, the only way you'll be able to achieve what you're looking to do with a due date is to use the Task ticket type, as the due date field that's associated with that ticket type is the only one that you can use in Automations the way you want.

Hopefully that can work for you! Please let me know if you have any other questions.

I'm using a macro to set the timer.

Most of the tickets set as On hold are tickets waiting for hardware to be returned to us and we don't want reminder of them as they get handled when the hardware arrive whether if it's in three days or three weeks.

But for the customers who want us to contact them in x days we need better options. I don't want to set up macros and automations for to many different time spans.

Is there any way of letting the conditions in the automation pull the number of hours from a custom field in the ticket instead of a hard coded value in the automation.

Say I have a drop-down with different timer values, a great solution would be if I cad use Ticket: Hours since on hold > Ticket: Timer 

Is this possible?

Hello Linda,  I haven't found a way to do that, though it would be a good option.  You cannot use a placeholder in the hours field of an automation condition.

I've created several macros and automations, creating them all is a pain, but using them is fine.  If you are thinking that drop down options would be ok, then I suspect that your option list won't be terrible.

We use 2hr, 4hr, 8hr, 1day, 2 day, 5 day, 7 day, 10 day, 14 day... wouldn't be hard to add several more.

Your thoughts?

Hello Andrew,

I'm just now trying out how it would work using a date field on the ticket. I have created a couple of test ticket and set them to fire on different days. If if works, that might be our solution or I will have to bite the bullet and create all the macros and automations.

Hello Linda, let us know how you get on and how your solution works.  A date field might work - if not a custom one, try a task with a date setting.

Seems to work as intended. I've testes it on a few incident and it works as intended. When we decide on what actions we wants, I'll add it to the rest.

First I added a custom non mandatory date field in the ticket form, only visible to agents. (This lets the agent pick a date from a small calender that pops up.)

Then I created an automation with the conditions:

Ticket: "name of date filed" Is within the previous 1 days

Ticket: Assignee is not -

Ticket: Status Is On-Hold (This is because I only want to use it for these tickets)

And performs actions:

Notifications: Email user (assignee), email subject and body

Ticket: Status Open (To move it back into the queue.)

Hi everyone,

Any updates to these methods - 6 years later? 

What is current best practice? 

Cheers

Hi!

I've been using this method as a workaround for deferring tickets for x hours. I have a couple of questions though.

1. Let's say I have a macro which will hold the ticket for 3 hours. What do you do if the ticket has been held for 3 hours, reopens, but we still don't have an update so we need to hold for another 3 hours? Am I correct to believe that the automation can only run once per ticket, so I could hold it for say 15 hours (if I had a separate automation built for that), but not for another 3 hours?

2. If this is true, is there at least a way to prevent an agent from using the 3 hour macro a second time? If agents didn't realise the macro had been used once already, then the ticket would just sit unnoticed for quite a while.

@Sophie Harris the automation can run more than once, you just have to remove whatever the stopping point is for it. So, for example, if the automation fires and then sets a macro called holdmet, then the second hold macro could remove that tag from the ticket and the automation would run again in 3 hours. Here's what the sequence would look like:

• first hold macro sent
• 3 hours later ticket reopens with a tag holdmet
• second macro sent removes tag holdmet
• 3 hours later ticket reopens with tag holdmet

You could remove and reapply the tag as often as you like.

- Edited

👆 What @Chris Bulin said

Hi Sophie,

Another option

You could use additional tags to condition against these scenarios.

1) So long as you are conditioning the tag that's applied, you should be okay.  In this instance, you would want to look for the applied tag in the condition of the automation.

2) So you could create a trigger that looks for the tag history and automatically kick the ticket back to open, preventing the ticket from being put on-hold with that tag if it already has been applied.  Hope this helps!

Brandon

Hi there, me again :)

We're having issues ensuring that our SLAs (first and next reply time) aren't impacted by these tickets. We were finding that if a user replies to us and we then (rightly) put the ticket on hold, the SLA keeps running and it looks like we're 60+ hours over our target time, even though we intended to reply much later on.

We then excluded these tickets from the SLA by using a specific tag for tickets that were re-opening from the on hold status, but this means they don't have an SLA at all. Our team therefore always prioritise tickets with an SLA over the tickets without an SLA, meaning these tickets can get missed if we're busy. Is there a solution to ensure that our SLA can start again when the tickets re-opens from the on hold status?

@Sophie Harris We have this problem at my company as well where we communicate when we'll be back in touch and the customer responds with a simple thank you. Of course, you could respond to the customer with a simple little message, but then you risk the customer responding back yet again with a simple "thank you" which would then reactive the SLA all over again - I refer to it as the "no you hang up" scenario with my team. 😂 

Unfortunately, Zendesk doesn't support the ability to pause or reset the First/Next Reply Time. These targets will always be based on the end user's last public comment. However, there is an open feature request that I'd recommend upvoting and adding your use case to: https://support.zendesk.com/hc/en-us/community/posts/115009712828-Functionality-to-pause-an-SLA.

IMO, the best option right now is to use an SLA policy that excludes these tickets from having the SLA applied and then find someway to help make it easy for your agents to remember to prioritize these tickets as well.

What that looks like would really vary based on what works best for your team, how your team handles tickets (1:1 ownership of tickets or general group assignment) as well as what other softwares your team might use (i.e. if you use Slack, perhaps a Slack notification to a private Support channel would be preferred over an email notification should you go down that route).

A few ideas off the top of my head could be an email notification to your team or the assignee (if your agents have 1:1 ownership of ticket) after X number of hours, a separate group or otherwise bucket for these tickets in the view your agents already work out of, a different view for these tickets entirely, etc. 

Of course, there really isn't a right answer here & it's ultimately what makes the most sense for your team, but hopefully that helped spark a few ideas. I've got my fingers crossed that the ability to pause or reset SLAs might be supported by Zendesk in the future. 🤞🏻

Thanks for the advice Chandra! It's so frustrating, as I'm sure many companies need to update the user again in X hours, and without SLAs that reset or pause, it's impossible to track performance. Hopefully Zendesk will fix this soon!