Set up On Hold Status Reminders

40 コメント

  • Linda Larsson

    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.)




  • Conza

    Hi everyone,

    Any updates to these methods - 6 years later? 

    What is current best practice? 


  • Jessie Schutz
    Zendesk Team Member

    Hi Conza!

    The functionality around the On Hold status hasn't changed, so this is going to be your best bet for setting up reminders for On Hold tickets. :)

  • Sophie H


    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.

  • Chris Bulin
    Community Moderator

    Sophie H 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.

  • Kay Heunen
    Community Moderator

    - Edited

    👆 What Chris Bulin said

  • Brandon Tidd
    Community Moderator

    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!


  • Sophie H

    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?

  • Chandra Robrock
    Community Moderator

    Sophie H 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:

    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. 🤞🏻

  • Sophie H

    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!



Powered by Zendesk