suggested this on September 02, 2009 03:22
There are times that a closed ticket needs to be reopened and reevaluated. There should be a way to do this in Zendesk. I'm sure it's just a matter of updating 1 field in your database for that ticket's record.
I still really do not understand this. This is marked as "Done" but it clearly isn't done?
Every major helpdesk software we have researched allows opening an old ticket rather than having a new one opened only to have the old one "referenced".
Why not just allow tickets to be re-opened?
Over the years I have implemented hundreds of different helpdesk / service desks in Europe and US. Be able to open close tickets are a very hot topic. Zendesk took the step to implement the functionality. I think you should have done better than that. If you follow ITIL and other - it is not allowed to open a closed ticket!
Zendesk should have a configurable setting. "Do you allow agents to re-open tickets?" Yes/No. With this simple setting your toolset would have been more flexible.
How am I suppose to tell my customers that they cannot see a list of tickets they reported in the past and that are now closed? This is really absurd :-/ .
+1 for the Terje Moglestue's comment !!
This functionality is something that I unfortunately overlooked during evaluation of Zendesk. As the use of a helpdesk system evolves, there is a need (as we've encountered), to tweak the ticket schema to optimize the system based on how it's being used. If there is no means of doing this, it is impossible to get clean reports out of the system. You are basically locked into the schema that you decide on from Day 1 making the Zendesk solution much less flexible in the long run. Considering that there are so many votes for this functionality, I find it unfortunate that this enhancement has been ignored for such a long time. Please seriously reconsider listening to the needs of your users.
Ok. Just tried to re-open a ticket that was closed somehow, not sure how. Then I stumbled across this thread. Obviously zendesk sold us something without mentioning this major flaw. Seriously, who doesn't have a need to re-open a ticket. Major malfunction.
@Craig -- If you're new to this topic, get used to beating a dead horse. You'll eventually give up, because Zendesk has made it clear that they aren't going to do this. Perhaps your voice will be the tipping point that causes a change in direction, and if so, more power to you! I'll cheer you on! Just don't get your hopes up.
This is a major flaw with Zendesk. Why not give us the CHOICE if we want to implement this or not on our helpdesks? Why are you making us create new tickets instead of being able to re-open them? Why? Why! What is the reasoning for this? I think you owe us all an explanation. This has been requested for years yet you IGNORE your users. Why?
If they give you the same answer as me when actually talking to them live - it is ITIL compliance. Now, being fairly familiar with ITIL policy I would call this a convenient use of that cover excuse but that is the story they will tell you. Once a ticket is closed, it is closed. Not saying I agre, just telling you what they told me.
Like you said, give us a choice, "ITIL compliance" or "rational self managed ticket re-opening with the proper safeguards"
What is ITIL compliance? If that is the case, then why can every OTHER helpdesk system have this option? Kyako, Tender Support, Assistly, etc. Are they NOT in compliance?
Give users the option then LET US deal with the compliance issue. Give us a choice!
@rvlawrence - http://www.itil-officialsite.com/ or if that link gets blocked
www dot itil-officialsite dot com
You are right, most other tools will let you decide the level of compliance to implement, they are not.
Please don't shoot the messenger, like I said earlier, I don't agree either but that is the excuse I was given.
I just got blindsided by this. Why is it marked Done when it's still broken? (We had even disabled the 'moved to closed' automation, but there is a hidden system-initiated moved to closed at 28 days that you can't disable!)
I also overlooked this during the trial last week. If this feature is not going to be implemented, is anyone switching? and to who?
@ Univa - the DONE thing is a bit misleading considering the solution does not address the question.
As a workaround, there are a couple of options... in the close ticket trigger, add a check for a tag that you add to all tickets you want to remain open. If the tag is there... it shouldnt close. However, as you mention there is some Zendesk policy to close that I am unsure of. My fix for this was to create a trigger that checked for the tag and time since solved and reopens the ticket for a breif period, then solves it again. I think this works ok.
Re-reading this ticket the only thing I see that's even mentioned as a possible work-around is the "followup" thing. Is that why this was marked Done? Seems largely irrelevant to the issue of un-editable tickets.
Well this is a HUGE inconvenience. We are new to Zendesk and had I known I was not going to be able to reopen a ticket after it was automatically closed, I would have turned that automation off IMMEDIATELY. It's off now! To not allow a ticket to be reopened is the most ridiculous thing I have ever heard! I don't want to create ANOTHER ticket as a follow up, what a mess! I just want to reopen my original ticket, is that too difficult to implement into this software? I am definitely NOT loving my Zendesk at this moment...... I work for a software company and our policy is if people are "clammering" for it, then do something about it. I would say people are "clammering" for this so could you just FIX IT!
Keep in mind disabling that automation is not enough. There is a somewhat secret, hidden automation at the 28-day mark that cannot be disabled by the user.
Oh great. So I guess if we just never solve any tickets then we are good to go then?
@Stacey - You are getting it. Don't solve tickets, lol! Great helpdesk idea. Further back in the comments I outlined an automation that was designed to extend ticket closing time... There has been one user that suggested that this did not work for him once. May pay to test it before relying on it.
A big problem is that the hidden automation has already closed 1000s of tickets so it's too late for many of them.
Can someone remove the "Done" tag from this thread?
Open a request with Zendesk support, they helped me out regarding a similar issue and may be able to help you. I got caught exactly the same. I can see the risks with allowing re-opens... my arguement is for admins only to be able to amend. Really Zendesk should remove the DONe tag, it is totally misleading. If there is something that has been done, they should refer to a new topic for this. the correct tag for this is 'NOT PLANNED'
I am a little hazy on why this was implemented in the first place? Is there a law that cover some countries that means tickets need to be closed in a certain timeframe?
If so I doubt this law covers Australia (could be wrong) so why are we (or countries the law does not exist) being forced to have this? As many have said a simple setting to switch the behaviour on or off would suffice. It seems quite silly to force this upon on all customers and very against the general flow on the product that is generally excellent in most areas.
I'm glad I haven't upgraded to the full version yet. I don't understand why they have ignored all of you. The arrogance of some of the Zendesk staffers is just ridiculous. Please listen to all of these comments and add the option to reopen closed tickets, further more remove the systems auto close feature.
I'm not 100% sure why this is marked as done as it it not :-)
Is it possible this forum thread is stuck in the incorrect "Done" state? Perhaps the forums have a similar bug as the one in the ticket system, and once marked "Done" it's stuck in that state forever?
No, this is just a company repeatedly ignoring a need that MANY MANY of their customer are practically begging for, but they are too stubborn to do something about it.
It would be nice to have this feature.
NOT done... please Zendesk... change the title or remove the false 'done' tag... a bit more transparency please.
We desperately need to be able to edit and bulk edit closed tickets. As we more fully implement ZD we are using custom fields that we would like to include in historical reports; we are classifying tickets differently; just in general we need the ability to edit the fields in closed tickets.
Like others in this thread I have a custom invoice flag that sometimes can not be set within 28 days.
The followup ticket solution does not help for this case.
Is there a way to prevent completed tickets from being closed, for example by adding private messages?
I've read a fair number of comments and I am in the same camp as many of those that have commented before on the value that being able to re-open a ticket would provide. The most significant use case is that as a +user we are using GoodData to be able to create fantastic statistics. We are able to now track and follow all sorts of things. What completely sucks is the inability to go back and fix incorrect data. Let me elaborate with a use case:
Reporting off Text Field Data - let's say that I have a text field (i.e. Sales Person) in which our agent types a persons name (John Doe). Depending on the agent I may get: John Doe | John P. Doe | john Doe | john doe | Doe | doe - and so on.
So now I go over to GoodData and I create a top 10 report showing me the top 10 # of Tickets by Sales Person. If I actually had 6 variations of John Doe and each one opened 1 ticket, my report would now inaccurately report that John Doe only had 1 ticket. John now is likely not in the top 10.
What I wonder is whether it would be reasonable to have a "temporary re-open" for admins that permit them to modify non-system fields only? Where once the ticket has been edited it moves right back to a closed state.
Thankyou Zendesk for removing the DONE tag. Since Jake closed my similar thread if is good to have this one showing as active not as if it is completed.
Reopening a ticket is very much necessary. Our customers do not like a new ticket number when an issue gets reopened.
Most importantly, the reports dump does not have a way to relate follow-up ticket with it's original ticket!
Just sayin, Jake re-opened this forum thread due to an incorrect label, we should re-open tickets. LOL.
I don't understand why tickets get to a "no touchie" state. What is the usefulness of this feature?
I have a feeling that Zendesk needs to understand that "business requirements/standards should drive their technology". Not the other way around.
Our customers get annoyed when Support teams tell them that they cannot reopen a ticket and have to give them a new ticket number to track the same old issue -- which is leading to bad satisfaction score in many cases.
Zendesk, eing able to reopen tickets is a problem (no matter what the standards say). You gotta fix it. If you cannot make Zendesk configurable, let us know. We'll walk away.
Hello from Folsom Street!
Our app company is dedicated to driving development based on customer demand. We selected Zendesk as our ticketing system, and with it's grace, we provide helpful responses to our users in short time, even with a very small staff. We also use Zendesk's forums feature to provide our user's guide.
Since we are customer-driven, we like to periodically research our ticket history to see what the most frequent requests and demands are. Often times, it's hard to build a clear idea of what a trending demand is, and tag or categorize it accurately during the response.
After tickets are solved, they are automatically closed, then we can't modify the tags or categories, and no level of GoodData integration will fix that.
At this point, our only workaround is to export lists of tickets to .CSV and hand-build a spreadsheet outside of Zendesk. That is not a very convenient, accurate, or maintainable way of performing this task.
Is there any way, any way at all we can enable tag or category editing of a ticket after it is closed?
From what I can see from this thread, lot of us users, (especially other cloud-based service providers, like us) are stumped why you are taking such a firm stance on "freezing" this old data and providing a seemingly abstract solution (opening a follow-up ticket)
Thanks for your work in providing a kick-ass product!
I am wondering if this is a resourse based policy... do closed tickets (unmodifiable) use less database or system resourses? If there is no system resource advantage it beggers belief that our wonderful Zendesk (and I do like it) would hold it up on a point of 'policy' for so long...
It's ludicrous to think that 'data older than 28 days is no longer of value', and that 'over the period that data is valuable tags or internal helpdesk classifications will not change or need modification'...
I am aware that no-one has actually said this...but seems to be the logic that makes holding out on this plausible.
Followup ups DONT address the issue, they multiply it.
However; and this may be important... we have some users that ALWAYS reply to an old ticket to create a new one, at least with closed tickets, they cant actually keep adding to the old one...so, it would be mighty helpful to have an option on a follow up ticket that says 'NOT a followup' so that an agent can reset all the 'followup' type data.
@Zendesk: I think an explanation of what restricts your decision to enable the reopening of closed tickets or the ability to update them would go along way in managing your customer's expectations of the product. This is a fairly technically minded crowd who mostly have researched, chosen, implemented and administered Zendesk, and likely other systems, and would have an understanding of software design and architecture to varying degrees. Or perhaps it is a product decision which could also be explained in more detail. I'm sure if you explain why your hands are tied here we would understand.
My personal issue was that I wanted to update tags to help with reporting where a tag should have been applied but had wasn't. I have decided to turn off the automatic closing of tickets as I do not have firm requirement to have that status as it exists in Zendesk. Tickets will remain as solved unless reopened. If someone as a valid reason to reopen a ticket then great we should have fixed it better and it counts a reopen. If someone incorrectly reopens a ticket sadly it will also count as a reopen, but the same thing would happen with follow ups, and we will again solve the ticket and begin a new ticket.
At the moment, the agent guide defines the closed status as "the ticket is complete and can't be reopened. Requesters however can create follow-up requests for closed requests.". This tells as what happens when a ticket is closed, but not really why and that's what people are having trouble understanding. Can you please further explain the intended usage for the closed status and in what ways the current behaviour is beneficial?
@ben - disabling auto closing isnt possible - so dont get caught on this 28 days and its all over.
I agree with Andrew J "It's ludicrous to think that 'data older than 28 days is no longer of value', and that 'over the period that data is valuable tags or internal helpdesk classifications will not change or need modification'..." We're in software development which means sometimes people ask for features which we cannot immediately implement. The ticket may be closed, but I want the ability to go back and say "Hey, we were able to create this feature for you." I don't want a new ticket created, but should be able to go back and add the information to the old ticket, as it's still the same issue. This could be months after a ticket is closed.
Also with Travis Ames - "After tickets are solved, they are automatically closed, then we can't modify the tags or categories". Creating new tickets skews our data.
I've got a couple of other use cases that require re-opening or editing closed tickets. I get the feeling that this isn't going happen, but I thought I'd add my voice to the merry throng anyway:)
1. I have approx. 30 spoke accounts managed from one hub to support different markets. Tickets are submitted via each of these spokes and hit the hub via sharing agreements, which is great because I can see which markets need the most support and my agents can handle them all from one place.
When a user replies to a closed ticket, this creates a follow up on the spoke, which creates a new ticket in the hub.
So far so good.
The problem is that ticket numbers in the hub and spoke accounts don't match - essentially the ticket in the hub is just a new ticket that happens to have the subject "This is a follow up to ticket #12345" - the number assigned to the original ticket by the spoke account. Clicking the ticket number link takes you to whatever ticket has that number in the hub, which is completely unrelated to the case, so any association is broken. If the users reply was treated as an update to the original ticket, the "follow up" ticket work-around wouldn't be needed, and this problem wouldn't exist.
2. Like Cheryl, I want to reach out to users who have requested a specific feature when we implement it. For example, I have 220 closed tickets stretching back to April asking for a feature we've just launched. I want to be able to do a bulk update to say "hey, we've been listening and we've made that thing you asked for", but there doesn't appear to be any way to select multiple closed tickets, let alone update them or create follow up tickets in bulk. Because of hub and spoke model, end-user email addresses are not passed through when tickets are shared, so I don't have any way of extracting a list of those users and emailing them outside of ZD.
Like other users here, as we got better using ZenDesk and refined how we wanted to report on it we changed the way we tag tickets, used custom fields etc. I'm sure we aren't at the final iteration of how we use it now, either, it's always going to evolve.
I now have a load of closed tickets with old tags polluting my reports (I still need to report historically), and confusing my agents as they continue to appear as auto-suggestions when they're tagging. I really need to be able to strip those tags out.
I'm a big fan of ZD for most of our purposes and I've been advocating it to colleagues in other businesses, but the stubborn refusal to look at this issue when it's one of the most popular feature requests is a bit disappointing.
Well said Hugh. I think you hit the nail in the head when you said “ stubborn refusal to look at this issue”. This has been repeatedly requested since 2009 and nothing has been done about it. Maybe if everyone here abandoned Zendesk for another product they would scratch their heads and wake up to the fact that Zendesk DOES NOT listen to their customers contrary to the emails I constantly received from them on how to keep your customers happy.
This feature is needed.
Jake said: "There's been some good points about tags on closed tickets though, which I'd like to explore a little further. For example, is the problem with skewed metrics because the tags on closed tickets are wrong and need to be renamed? Or is it that they need to be removed (or added) to specific tickets? If the tags are more manageable, it sounds like that would release the need of opening closed tickets."
Any official roadmap regarding this?
Please turn off the auto-closing at 28 days. It is currently our biggest hassle with Zendesk. Please allow your customers to control the auto-closing timeframe (turn the hardcoded 28 days into a setting we can control)!
I'd like to throw my vote in on this. We've been trying out Zendesk for the last couple of days. We've removed the 4-day automation, but I noticed this thread and have to say that the hidden, unconfigurable auto-close at 28 days is a deal breaker for us.
Like many others in this thread, we have some bugs or feature requests that take longer than 28 days to fix or implement, and we'd like to be able to follow-up with the customer in the same ticket. Since we don't provide access to the public Zendesk portal for our customers, simply referencing the original ticket number in a follow-up isn't sufficient. We'd then be required to recap the original issue in the new follow-up ticket so that the customer knows what we're referencing.
Thanks in advance for your attention to this issue!
In a somewhat related problem the reply ticket ignores comment privacy defaults:
- Ticket is created by customer (Public Comment)- Light Agent Replies (Private Comment) - Agent Replies (Public Comment)- Agent Solves Ticket (Public Comment)- Zen Desk Automation Closes Ticket- Light Agent Replies (New Ticket With Public Comment)
Light Agents are by design not allowed to reply publicly. Their comments are supposed to be internal. We tell our Light Agents not to worry about language and customer tact as their contact is always private. With a closed ticket being re-opened this is totally broken. This to me is the worst part about this problem.
The closing of tickets (as opposed to solved) doesn't make sense and I can only assume this is so the closed tickets can be moved to a different database server for space conservation which is basically punishing ZenDesk customers for architecture flaws. Is there some other reason to close tickets?
Just my 2 cents on Nick L's issue:
1) The actual issue needs to be fixed and is NOT a result of the unable to reopen closed ticket policy that is in place. Again, it is a bug that needs to be fixed and likely needs it's own bug related report and thread.
2) Moving finalized data to different tables or DBs for archival purpase is GOOD DB design, not an "architectural flaw". I don't deny that the manner in which Zendesk does it (without allowing the end users to be the final say in what is "finalized" data), is questionable and needs a closer look. However, expecting any large scale DB to maintain all data put into it to it to be fully accessable forever is unrealistic and would actually be a HUGE "architectural flaw" in the long run.
Not saying I don't want this feature and that it isn't possible with some (possibly drastic) changes on Zendesk's end, I'm just pointing out that there are VALID technical reasons for what they are doing (but again, I don't like the way they are doing it).
Clark, that's a fair point. I guess the punishment of the customers comes in not being able to move that ticket back to Open/Pending/Solved. Moving it to a separate machine/database should help in most cases, but it shouldn't be a finalized move. That in addition with the bug with breaking comment privacy rules makes this a serious issue.
This debate has been going on for more than *4 years*! When will ZenDesk decide to listen to its customers???
@Brad Given the lack of action on this other critical ticket: https://support.zendesk.com/entries/14098 not anytime soon.
Both of these are possible but take some work. Both are pretty important for us and I'm not hopeful that either will be fixed any time soon as both threads are over 4 years old.
+1, I can't believe this has been a request since 2009.
Sure, archive the data off to another database, another server, there are many reasons for this! When the ticket is re-opened, move it back to the "main" database, which is essentially what is happening when you use the "re-activate" feature anyway!
Either way, I have customers complaining about my new help desk system because of this.
Hello Chris, I don't think there will be a change on this stance. Creating a follow-up request does work, and can reference back to the original request. Lengthening the close time may help.
There are several barely related topics popping in and out of this thread.
Someone mentions formatted text in tickets; but to be fair, this has had two releases recently with the ability to access original mail files, and with the release of rich text markdown.
I will readily admit that there are times when it would be useful to reopen an old ticket (especially from a tagging point of view). but as a very high use helpdesk compared with others in our industry, I find it hard to believe that this is a major issue, rather than just a major irritant.
I have been quite vocal in the past about this issue, however, in retrospect, we have moved on and only the tagging is really a problem now.
What issues in particular is the lack of being able to re-open a closed ticket causing for you? (ie. problems that cannot be addressed by the followup ticket refering to the original)
I hope I can help in some way.
Thanks for your comments Andrew. Initially it came about due to complaints from our end users. I have now removed the 4 days automatic close out of tickets, and they will remain until the system forces them to be closed, which I believe is 60 days.
If agents or the API had the ability to close the tickets, this would allow our internal applications to control the status, which would be of benefit.
Custom fields, tags, assignee, CC, pretty much all of the fields are lost when the ticket is opened as a follow-up, therefore all of this valuable data is lost.
Even if our internal systems could tag closed tickets via the API, this would be a useful.
My clients currently are also getting quite confused as to why they are getting a new ticket number when they have a call "re-opened". Because the system has emailed them the reference number, we use that reference number when dealing with them over the phone.
Anyway, that's my thought on the matter.
This would be a good option to have.
It really sucks not to be able to reopen a ticket. As long as it is documented and there is an audit trail, it should be able to be reopened.
This seems to be one of the worst "features" we are currently dealing with. Can't believe this has been an ongoing discussion since 2009!! Really?
This to me is the downfall of SAAS. If this where an in-house application, that problem would have been fixed long ago. We are at the mercy of other powers. Lessons are to be learned here.
This one problem among other annoyances will keep us looking for olther solutions.
I inadvertantly came across a very good point regarding this recently.
The achiving of older tickets in a non-active way positively deals with the issue of redundant fields. There are a number of ticket fields that we have now retired, some through evolution of our business model and other in favour of a more streamlined user experience.
These 'aged' info fields did contain relevent info which we are very pleased to see preserved in the fixed 'closed' ticket format. If I remove a field this then removes all inserted info from the field from all tickets that are NOT archived.
There MUST be a close-off point for aged tickets, otherwise they will never move into this 'archived' state, and hence the fields would never be able to be retired safely.
To those that are absolutely certain that re-opening tickets is a must, consider the implications of this... every field you have ever used... still active, or the information abandoned. Every ticket you have ever created, able to be used again and again by users who never learn how to create a new one; totally different requests on the same ticket, reopens for unrelated issues.
I would like to pose the question, what is the aim of ticketing issues?
For us, tickets allows individual (or related) problems to be handled separately, the aim being resolution of each issue in a timely manner, and to give definitive closure upon completion of the issue.
Re-opens SHOULD be the exception to normal practice. I was firmly in the 'I want re-open ability' camp, this has become a totally non-issue to us now; re-opens are a rareity, customers are understanding the need to have each item on a separate request, follow-ups are working fine.
I dread to think what a mess we would be in now, if Zendesk had not had a policy of archiving.
The 28 day maximum is still a possible snag to some, but we are set at 4 days, except for invoiced issues, which are held open for 28 days. Our invoicing team is a lot faster now too :-) (We automate a reminder to them to address ticket before it closes)
Hope this helps :-)
@techops, if you care to share an example of where you feel the archiving of tickets will be an issue, we should be able to offer some ideas.
@techops, thats great! It is pretty hard for an agent to accidentally close and issue. They can only mark it as solved, which can be re-opened until it is closed by the automation (up to 28 days).
There is only one automation to 'Close' tickets in our system, based on them being already solved for a period of time.
Marking a ticket as 'Solved', does not close them.
I am hoping that this resolves this for you, if you need specific help with triggers or workflows, let me know!
A trigger CAN close a ticket... but simply; don't make one like that! We have only one automation set up to close tickets. Some people might have more, but you dont need to.
Ensure that any closing actions are made after a several day delay. You have total control over your triggers and automations. This isnt going to happen 'accidentally'.
If you need someone to 'vet' your triggers/automations, open a support request, Im sure the team would be happy to help. Or if you post the info here, I will happily help.
First, I want to thank everyone who has contributed to this feature request. We really appreciate our customers keeping our Forums alive the way you all have done here.
With regard to this particular request, we cannot allow the ability to re-open closed tickets. Closed tickets are treated as archives, and can therefore no longer be edited.
That being said, we do have a few options for you. First, if you simply need more than 4 days from solving a ticket to closing it, you are welcome to edit the default automation to include more days. If you're unsure of how to do this, feel free to shoot us an email at email@example.com. You can also continue the current conversation in our Q&A Forum, which you'll find at https://support.zendesk.com/forums/1847-Community-questions-answers.
Secondly, if a ticket has closed and further communication is needed, you can always create a follow-up ticket. This will create a new ticket with a unique ticket ID, but all the information from the previous ticket will be housed within the new ticket.
We do apologize for any inconvenience this causes, and welcome you to submit tickets with us if you'd like to discuss your specific use case. Hopefully, we'll be able to find alternative solutions for you. Thanks again for sharing your ideas with us!
Cheers - JenniferCustomer Advocate
Support Software by Zendesk