Why does Zendesk auto-close tickets when I tell it not to?

10 Comments

  • Andrew J
    Comment actions Permalink

    Hello Charles, there is a maximum 'colved' but not 'closed' time of 28 days.  This operates regardless of tags etc.

    I did come up with an automation to work around this, but it hasnt been tested recently.  This involved tagging an item to prevent it closed 'do-not-close', then an automation picked up this ticket after being open for 26 days and reassigned it to another tech, then a followup automation assigned it back to the original team.  This was used some years ago now, and if I remember right, there was  a suggestion that unless there was an agent comment, the close automation would still be apply.

    Once the 'on hold' status was released, we implemented systems that utilised this, and we also added warning reminders to tickets that were risking being closed (25 day email to assignee to check it)

    0
  • Charles Magnuson
    Comment actions Permalink

    @Andrew Mills - Interesting. It blows my mind that such a hacky workaround is required to keep tickets in the solved state. I'll give that method you recommended a try.

    0
  • Diane Albert
    Comment actions Permalink

    HI Charles - this is for my own benefit, not for anyone at Zendesk...since i've never come across a "theory of help desk" manual, it's just neat to see who does what and why.

    In your help desk, what is the reasoning behind keeping tickets Solved but not Closed?

    I realize a response to a Closed ticket prompts a "follow up" ticket instead of reopening the original.  It also does not allow changes to tags or other information on the Closed ticket, whereas if you notice incorrect tags or pieces or data, you can still change them on a Solved ticket.

    I could see having a ticket hang out in Pending or On Hold, but in our situation, Solved really is "we are done with this".

     

    Diane

    0
  • Charles Magnuson
    Comment actions Permalink

    Hi Diane,

    The company I work at distributes video games. Because we do not develop any of the games we sell, we rely on the developers we work with to send us updates to the games that are not working correctly. This process can take days, weeks, or even months.

    We don't want to keep tickets in an open or pending state for long periods of time while we wait for a developer to send us a new build. For this reason, we tag related tickets, solve them, and then document the issue on our wiki. Once we then receive a new build, we reply one last time to the tagged solved tickets to remove the tag and allow them to enter the closed state.

    I was previously unaware of the On Hold status. I've done a ton of reading about Zendesk and I can't figure out how this feature has eluded my view. I'm going to do some research into the feature to see if it works for our purposes. Thank you for the recommendation!

    0
  • Diane Albert
    Comment actions Permalink

    https://support.zendesk.com/hc/en-us/articles/203661576-Adding-the-On-hold-ticket-status-to-your-Zendesk

    Regular, Plus, or Enterprise plans...if you're on the Starter, it's not available. 

    I love it - that one means "a third party is in charge of this one right now".  We use it when we send our media to our production facility (yearbooks).  Even though they are the same company, we have a shared separate instance for them, so they really are a different entity.

    0
  • Andrew J
    Comment actions Permalink

    Hello Charles,

    Sorry, I did not think of the possibility you may only be on starter.

    The On Hold status is I think the solution.  This means that the client see the ticket as open (which it really should be if the issue hasnt been resolved for them), and your agent sees it as 'on hold'.

    There is a tutorial on how we set up Macros to apply different on hold periods and automatically reopen them for the agent to review - see https://support.zendesk.com/hc/communities/public/posts/203457756-Set-up-On-Hold-Status-Reminders

    0
  • Peter Haller
    Comment actions Permalink

    This is yet another example of Zendesk having tools to configure the instance as you need it, but then having hidden rules that make those tools useless. 

    I can understand forcing admins to have all their tickets close at some point, but why not have an account setting where you have to enter _some_ value, even with limits to force people to be reasonable. Does everything need to roll to Closed within a year? Sure... that's probably reasonable. 

    28 Days??? How do you pretend to know what is the right delay for my business? So now I have to devise and employ some kludgy workaround mechanism because we offer our customers 90 days to report that a critical issue didn't stay resolved. This is the opposite of helpful. You have Automations to do exactly what needs to be done, but then you ignore them ... secretly! 

    So 28 days after I set it up correctly I find out it is broken. This is literally setting me up to fail. Setting me up to announce a feature that's working right, and then FAIL. So now I have to scramble to put in a fix because I have users already using it. 

    0
  • Jessie Schutz
    Comment actions Permalink

    Hi Peter!

    I'm really sorry you're frustrated by this limitation. I totally understand how upsetting it is to think you've solved a problem, only to find out later that there was a caveat you didn't take into consideration.

    The 28 day limit is not really about what we think is best for your business; we put that limit in place to ensure that our servers will be able to optimally handle the workload for all our customers. The more tickets that need to get loaded up, the more the performance of your Zendesk could be slowed down. We don't want that to happen for you, or any of our other customers.

    Also bear in mind that, if one of your customers responds to a ticket that's in closed status, a follow-up ticket will be created that links back to the original ticket. So it'll be easy for your agents to find the original conversation.

    The other thing you might think about leveraging is the On-Hold status, which is available on the Team plan and higher. When you have tickets where customers may need to leverage that 90 day window, you could set those tickets as On-Hold instead of solving them. Then, if the customer hasn't responded to the ticket within the 90 days, you can have an automation change the ticket status to Solved.

    Hopefully one of these options will help you to get your workflow straightened out! Please let us know if you need anything else.

    0
  • Peter Haller
    Comment actions Permalink

    Hi Jessie -

    I already use On Hold for various workflows; it is going to be a weighing of impact to decide whether to kludge around this 28-day limit or revise the On-Hold process we already have. I appreciate the suggestion nonetheless.

    As for 28 days being some perfect number to make sure your systems aren't overloaded I have to admit I'm not buying it. As a customer if there is a default of 28 days and I have some need to revise this to a longer delay, how many customers will do that? Make it so after 28 days automations no longer run on those tickets, or some other nonpermanent effect. Point is, there are ways to solve this that do not force customers to accept arbitrary limitations. 

    Admittedly, I'm currently suffering from both this limit and the 100 automation per ticket cap, and the effect in combination is very frustrating.

    0
  • Jessie Schutz
    Comment actions Permalink

    Hey Peter, 

    I'm sure that's a pretty major double whammy. I can't do anything about the 28 day limit or the API cap, but if there's anything else I can do to help, please let me know!

    -1

Please sign in to leave a comment.

Powered by Zendesk