Michael Southwell

We have had to rely on the auto-refresh third-party Chrome extension to provide what should be native functionality. This has side effects though that can cause erratic behaviour in the browser.

The tickets also stopped auto-refreshing along with the views in the last few months and now requires a browser refresh "F5" (this is even without the third-party auto-refresh extension installed or any other extensions for that matter).

That is a lot of manual work from support staff to make sure we don't miss tickets.

We should not have to be installing 3rd party extensions, constantly clearing cookies and cached data and refreshing the browser, just to achieve what should be a base level of functionality.

We are on an enterprise license and deal with a high volume of tickets and can't afford to be relying on manual refreshes to keep on top of tickets, that is what a ticketing system is for!

Please address this issue as this should be standard functionality for a ticketing system, especially one that has been around as long as ZenDesk.

This is still an issue for us as it has been for many years. Why hasn't this been implemented yet?

We have had to rely on the auto-refresh third-party Chrome extension to provide what should be native functionality. This has side effects though that can cause erratic behaviour in the browser.

The tickets also stopped auto-refreshing along with the views in the last few months and now requires a browser refresh "F5" (this is even without the third-party auto-refresh extension installed or any other extensions for that matter).

That is a lot of manual work from support staff to make sure we don't miss tickets.

We should not have to be installing 3rd party extensions, constantly clearing cookies and cached data and refreshing the browser, just to achieve what should be a base level of functionality.

We are on an enterprise license and deal with a high volume of tickets and can't afford to be relying on manual refreshes to keep on top of tickets, that is what a ticketing system is for!

Please provide a recent update on the progress of this issue as the last communication from the  ZenDesk development team was almost a YEAR ago from Salvador Vazquez on October 6th 2021.

Any updates on this?

It is incredibly frustrating to miss responses in tickets that are in an open state and get responded to by a customer and then stay in an open state.

We desperately need an additional status for tickets that are open but are waiting on a response from an agent.

Hi Nicole,

I am aware of this, but the issue is not that we can't change the status to pending, the issue is that if someone is working on a ticket (open) and then a customer responds to the ticket (stays in open state) and then the agent sends a response to the customer and puts the ticket in a pending state, they may not see the response from the customer that was sent while they were working on it.

In this case, it would be good to have a state where the agent is working on a ticket, which is different from a state where a customer has responded to a ticket and is pending an action from the agent.

Please le me know if you need more clarification on this.

It would be extremely helpful for us to be able to distinguish between tickets that are Open (and being actively worked on by a technician) and tickets that are Open (and the last communication in the ticket was from the end-user eg. waiting on response). 

Without this, it is very difficult to see when an end-user asks a follow up question on a ticket that is in an open state.

Even something as simple as being able to just change the colour of the Open status icon from a red O to a green O or better yet, having the green O being the default colour when it's being worked on (instead of red for the traditional open state) and have the red O for when a customer responds to a ticket being worked on to let the technician know that they need to reply back to the end-user.

Completely agree with everything Colin said above! This would be a vital improvement to the current setup. We are currently trying to figure out how to integrate alerts based monitoring for this, but we are having trouble figuring out the best approach, because emails are only being sent to the agents. which can often get missed, meaning it can be hours before the issue is resolved and there is no option to retry any previously failed attempts, short of manually going through all tickets since the outage!

Very well said Josh!

This is the exact same issue we are facing! If we can't disable follow-ups then your alternative solution seems like a very good one. Let's hope ZenDesk come to the table on this matter!

Very well said Martin!

This is the exact same case for us and it is incredibly frustrating!

Can we please have the ability to disable follow ups or at least some options to assist in triaging the damage caused by this oversight?

Has there been any movement on this functionality?

Re-training users is not practical. 

Either having the option to change a ticket from follow-up to a new separate ticket or having an approval process before a follow up is created would be ideal.

It is rare that we have users intentionally creating a follow-up ticket on a related matter (more often they are just creating a new ticket using the old, unrelated ticket's ID), and the idea of emailing users back and saying they are not doing it right and should try again is not a good look.

Please provide us with an update on any proposed solutions to this issue.

We would also find the ability to set this default setting incredible useful! Especially to mitigate the damage caused by an accidental merge of two calls from different clients, seeing as it appears it is unlikely that ZenDesk are going to implement any "undo" merge function.