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 have also run into cases where this would be helpful.
How is it that this is not already in Zendesk? Why on earth would you ever want to prevent anyone from reopening a ticket?
Just ran into the problem? Not efficient to have to recreate a ticket (it doesn't send a message to the user). Any progress being able to do it?
This is actually a serious enough bug that it makes me look for other ticketing systems. I don't mind that the tickets "close" after 30 days, I just don't like that I myself can't even reopen a ticket. Marking everything as "pending" is inaccurate. An example of this is maybe we find a solution to a bug we thought was not solvable and we want to email a customer more than 30 days later to tell them. Right now there is ABSOLUTELY NO WAY to email this customer from zendesk - I literally have to email the customer directly. Not ideal.
This actually annoys me. I've just went back to look at a request I had from a client a while back and I want to add more information to his ticket, but I can't as it's closed. I can't reopen it... I can't reassign it a new ticket number... I can't do anything with it. All I can do is create a new ticket, which seperates out a single issue into 2 tickets. Why so strict, zendesk?
We also use Zendesk to handle our support needs, and would find the re-open functionality useful.
An alternative work flow is to create a new ticket representing the
closed ticket. This is a little cumbersome and would likely incur a
greater performance hit that re-opening the closed ticket.
I agree, this absolute, undoable closure policy is a barrier to providing the best support to customers.
Another aspect of the total inability to do anything with a closed ticket is that if an end user e-mails a reply to one, the user gets a bounce message and we do not know that the user needs more help unless and until the user figures out what the message means. I think this is a disastrous way to treat customers. I'm not suggesting that that end users necessarily should be able to re-open closed tickets, but at a minimum, an e-mail reply to a closed ticket should create a new ticket.
Thanks for your comments everybody. Email updates for closed tickets will result in new tickets after our next update.
I think that you have missed the point. We do not want new tickets being opened. We want to be able to reopen closed tickets. There's no sense opening a separate ticket if it's the same issue as the first ticket. That makes it much more complicated to see the history of the issue. We need to be able to repoen a closed ticket. It's not that hard. The ticket is still in your database. Please provide a solution for us that does NOT open a new ticket.
Morten, I'm glad theres some development on this. In your proposed solution, how would I know the user had replied to a closed ticket and hadn't just created a new one themselves? Would the new ticket have an opening comment that referred to the old ticket number? ... Or, to get around this, couldn't we just reopen a closed ticket? Is there a reason Zendesk don't want to reopen closed tickets? Thanks!
There really are two different issues concerning closed tickets here. 1) When an agent knows of a need to re-open a closed ticket, they should be able to do it, but it's unclear whether this will be allowed in the future. 2) When an end user replies to a closed ticket by e-mail, it's essential that the message get through instead of bouncing as it does now, and it seems that this will be the case soon. When a user does this, it would be great for the agent or admin to be able to choose whether to re-open the closed ticket or create a new one, but automatically creating a new ticket would be enough for me as a response to this type of user e-mail. I am assuming that the e-mail subject line would be preserved. The message must have the old ticket number or the system would not recognize it as a reply to a closed ticket to begin with. Having the old number would allow me look up the ticket (and, if issue 1 is addressed, re-open it and merge the tickets if appropriate.)
Just wanted to add my 2c: I agree completely with Arnie's comments. Especially the ability for an agent to reopen a closed ticket is really essential.
I have just had this problem, customer was not happy. Ticket was merged in-correctly which resulted in the ticket being closed, Had to start all over again. This is a big problem for us.
While I'm not here to offer any cake, sorry guys, I can give some feedback on the points raised so far.
@Luke: The ticket is referenced before the comment has begun from the end-user, this link is clickable. I'm afraid it's not as simple as you think to completely re-work the architecture of Zendesk, but does not mean it's outside the realms of possibility or means we can't reach a solution at some point.
@Alan Wilson: There is a line added at the top of the ticket, clearly separated from the comment made by the end-user. See above :)
@Arnie: Totally agree on point 2 - and that's now changed as soon as we realised we were making it harder to get support, which is totally not what we're about. Email Subject would indeed be preserved, and you're able to edit the subject line (if you have that option available). The old number is referenced in the ticket.
On point 1, what would be the clear use case for this, that couldn't be done anyway if it were a new ticket referencing the otherwise closed ticket?
@Alan Trombla: We'd love to know exactly why it's essential to the workings of your helpdesk, and how it prevents you from otherwise providing support to that end-user
@Steve: While that's very unfortunate, there's warnings of what will happen with what ticket during the merge process - if you have any suggestions on how to improve that process I would more than welcome it, if you could pop it into a new post that'd be great.
Guys, I appreciate this is a pretty hot and sensitive topic, I'm not trying to antagonize anyone, but simply understand everything fully and get the opinions and arguments of all.
Jake HolmanZendesk Support
To carify, since my prev comment, email updates to closed tickets result in a new ticket. This is a huge improvement over a bounce/error, and as a result we
ve started closing tickets again. But just in general, we have many situations where users do not explicitly OK the closing of a ticket, but we mark them solved, then closed, because the issue seems resolved and the user is not perstering us about it. Of course we may be mistaken and when the user gets back from vacation they're going to tell us that the issue is not resolved at all. In that instance (where the user is probably already annoyed) to be confronted with a closed ticket that cannot be reopened is I think really bad customer relations. Since most of our interaction happens over email, the automatic creation of a new ticket is good, but does the new ticket contain the history of the old ticket in that case ? If not, I think that's a problem. Also it does not address the case of the user coming back to the web interface and finding a closed ticket.
Thanks for listening,
Alan's remarks nicely cover what I would have written in response to Jake's query about my point 1, and I also agree that the revised handling of e-mail updates to closed tickets is a big help. Thanks, Alan and Jake.
This whole thing is crazy. Zendesk: just make it so tickets can be reopened. I don't really care about why you did what you did or how difficult it is to "re-work". No one from Zendesk or the general public has yet to give a good reason why you can't do what should be a very basic task. I'm not trying to antagonize anyone either but everyone, Zendesk included, seems to be in agreement that this is something that should be possible.
Reading this thread, it does seem like a case of "technical difficulty" winning out over usability. It's clear that the only people who don't want this feature are the programmers who have to figure out how to make it work. I'm not saying that's a bad thing, I just think it's important to realize. All other support systems that I know of allow the re-opening of existing tickets, so it's also not the case that it's an impossible task.
I have threads with some of my customers over 5 tickets deep - there is no way I can tell to reference old tickets, so my customer service manager needs to search on email addresses or keywords every time to get the full history.
+1 ... If this is really a 'performance' issue, give me a mailing address and I'll send you an iodrive for our server - Will 95,000 read iops will allow me to re-open a ticket?
@Jake, Rather than starting from the position of defending the current functionality, pretend the current functionality doesn't exist, please provide us a business/use case for making it impossible to re-open a closed ticket..
explain why this is a good feature, remotely intuitive, or consistent with "Loving our helpdesk" ?
Thanks to all those who replied with constructive and fair feedback. Essentially, this is something we want to look at improving, but it's not going to be coming immediately. There's some significant design, process and back-end challenges this represents and to combat them we need to put the time in to ensure to negative repercussions (i.e. horrific performance issues) come as a result of any changes.
We're probably looking at a late Q4 update, but there's no telling (at this stage) what might delay us. Thanks again to everyone for their feedback, we have been more than listening!
Jake HolmanZendesk Support
That's great Jake!
Just to be sure, do you mean Q4 fiscal or calendar year?
Looking forward to this essential feature being added.
@Jonas: The Calendar Year. I'm not allowed to touch the monies.
Please. Adding my +1 here. I am at the merci of the agents correctly closing a ticket. If they don't correctly close a ticket I have to open a new one and lose the history from the original.
If I could even just "merge" a new ticket with a closed one I would be happy.
C'mon now, no more +1 stuff, we have a vote button!
Hey! Was that there a few hours ago? That's cool. :)
Just to clarify - 3rd bullet on list of Zendesk inborn ticket rules is separate functionality than what we have been discussing here?
https://support.zendesk.com/forums/3199/entries/4654"If a ticket's status is set to Pending or Solved, and requester performs an update, status is changed back to Open"
Please help confirm/clarify. Thanks!
@Vi: Yeah, different things. Closed is a status reached after n amount of time after a human has manually set the status to Solved, something called an "Automation" is run on Solved tickets, causing them to become Closed.
Gotcha. Thanks Jake!
The ability to reopen closed tickets is a must. For design ideas see Jira. In fact you could use Jira as a model to fix most of the problems that your users send feedback about: (ability to edit/delete comments, ability to import tickets, ability to reopen closed tickets..)
We need this too.
I'm just now finding out that a closed ticket can't be re-opened. I honestly couldn't believe it when Zendesk support told me the news. That's a defect and needs to be fixed ASAP.
The ability to reopen a closed ticket is essential. I hope we'll be seeing this soon. It will be "very" helpful.
Encountered the need to reopen a ticket, just so that I could close it again and merge it into another ticket. Is there a secret workaround for this?
It seemed obvious that the reason for not doing it is because of the engineering of the database, which appears to be confirmed "here's some significant design, process and back-end challenges this represents." Half the banter here appears to just be a debate so that doesn't have to be admitted.
I'll "me too" on this thread, as well. We've got a billing person who needs to have a custom field populated in some of our tickets. Invariably, this field is accidentally skipped by the personnel solving the ticket. By the time the blank fields are discovered, the ticket is closed and unable to be reopened.
In short, it would be useful to be able to reopen a closed ticket, even if it were just for internal housekeeping purposes.
@ Michael Lehmkuhl - I agree, that's the only situation we'd need to use it - not even to necessarily "re open" the ticket, just to add a certain few fields such as "invoiced"
@Jack. While adding fields to a closed ticket would be fine and good, it doesn't solve the root issue of the problem.
Users need to ability to completely manage our tickets how we decide, and if that means reopening a closed ticket so we can further process it in a variety of ways, then we should be able to do this. I presume the only reason that Zendesk hasn't made this basic feature a reality after all these months is probably because they move closed tickets to a different database, and they need to create a path for the ticket to flow back to the "live and active" system. If all the tickets remained in the same database, this solution would be easy as pie, just change one switch in the record from closed to open, just the same as we change active tickets from open to pending to solved, etc.
Its quite frustrating that this basic feature has totally been overlooked in the design of this application. It needs to have priority in resolution.
Just added my vote as well. We are really understaffed, and even though we "Solve" tickets as fast as possible, it is sometimes a week or two before we have time to post a hidden comment (solution) for the other agents. If we could re-open a closed ticket, slap on some tech notes and re-close, that would help us a great deal. Thanks!
Wow, I had no idea this was not a standard feature - add to this the fact that I cannot publish closed tickets as solutions in the FAQ I'm pretty much done here unfortunately...
For a moment I thought I'd found a way around this by removing the 4 day close solved tickets rule. I figured I could just leave all tickets in solved state.
But alas NO, you've implemented a system wide 4 week auto close on all solved tickets too that I can't turn off :(
This is no longer feeling like MY helpdesk, I've got a ton of good support content hidden away inside closed tickets and I cannot leverage any of it...
Any chance you could just buy a bigger database box and keep all tickets in the live one? Perhaps keep just plus+ users closed tickets in the live DB, I'm not one but I'd upgrade for that.
Gary, we're looking at ways of getting closed tickets into forums/macros but I can't say when that might be completed.
Hi Jake, okay, fair play, how about temporary lift on the 4 week auto closure until you get it sorted then?
Those who want can just leave tickets as solved and there would be no issue until this was implemented. Later you mass close the tickets.
If performance is the issue:
Make it an opt-in so not everyone will use it.
Make it plus+ only feature and use the extra cash from the new upgrades to buy an extra terabyte for the DB box ;o)
Glad I took the time to read this before signing up for an account. I'm in need of a good helpdesk and thought my prayers had been answered when I found ZenDesk :( Just have to bookmark and keep checking back for the time being as ability to reopen tickets will be essential for my clients needs.
You're losing potential and current clients over this basic feature. Can you please just get it added? It's been way too long already
I think (hope) that the position of the community is clear, but just to beat the dead horse some more, this is a _huge_ problem for us. We release our software frequently and every time we do, I want to go back and let people know that issues they asked about are affected by changes in the new release, no matter how old the ticket is, even if the "main issue" of the ticket was "solved" in the past.
It's just vital to our business that people hear about changes that they care about, and this tracking functionality is really one of Zendesk's primary roles.
If the ticket has been closed, we can't send an update on the ticket, this chain is broken and it costs us customer good will and eventually money.
Our "solution" at the moment is not to "solve" anything, which is pretty pathetic for an issue tracking system.
I see lots of new features coming all the time from Zendesk, and that's all awesome, but to be clear, none of the new stuff I've seen in the last year is as important to me as fixing this core problem.
I love ZenDesk.
But from today foreward, after reading this thread, I'll pause when it comes to recommending it to others looking for a turnkey helpdesk solution. Simply put, the lack of ownership over what I'd think is an obvious design flaw, and the design flaw in itself, hurts my perception of the company and its solution.
Here's my use case, which probably can be repeated over a variety of organizations in actual day to day usage. I had new agents who were inadvertently Solving tickets the moment they answered them. An automation that closes Solved tickets after four days triggered and closed all of those tickets, even though they really weren't *in reality*. Now we have to go a) outside ZenDesk or b) create a new ticket to fix what should otherwise be a very simple change of state.
I need to recommend that ZenDesk take this one as a bigger priority. Q4 of this year when the problem was first identified last year--and so many "me toos"-- no bueno.
I remember thinking at one time that allowing the ticket to be re-opened and not auto-closing tickets were a great idea. After we allowed that (we had custom software with many features similar to ZenDesk), we found several reasons why we shouldn't have done that.
1- Customers would reopen cases that were months and years old. Some customers also found it was easier to just reopen a case and use it as a new case than it was to actually create a new case.
2- In reopening the case, all of the metrics for when a case was actually closed or resolved became skewed. Reopening a case 6 months later would change our metrics from an average "resolve time" of a few days to 20 or 30 days.
3- Not auto closing cases meant some cases stay opened forever because the customer simply would not close the case.
4- Cases that were open a long time became a drain on Support Reps because of the need to review and resort cases regularly and basically reviewing a case that wasn't going to move forward.
5- Cases opened a long time caused management to call us when they looked at the metrics because the metrics said we weren't solving customers problems.
6- If we had a customer relation problem with a customer or a legal dispute with a customer, they would point to the complete lack of resolution of a case as an example of how unresponsive we were.
From the examples above, I'm sure you can see a lot of similar things that might come into play.
Anyway, in the end, we autoclosed cases that had zip activity after 30 days (assuming it was pending the customer and not pending support) and we gave the customer 30 days after we auto closed a case to re-open it.
@Bbrown, I agree with you.
Originally I found this issue annoying. but when I got the Automation for solved to close right (I have it set to 45 days) it hasn't been an issue. just let your tickets sit as solved for a while before closing them.
I think if zendesk changed the default automation to 30 days of inactivity, so much of the anger around this issue would dissipate.
that said I still think it should be resolved but there are SO many other things I'd prefer the Devs work on!
Why reopen a a closed ticket when you can create a follow-up (https://support.zendesk.com/entries/236801-updates-to-twickets-closed-tickets-and-plans). In my book this is even better!
Create a Follow-up is a perfectly acceptable solution to this problem. I vote to close this feature request.
Thanks for coming up with a good pattern.
From Forest's link:
"You'll notice a 'Create Follow-up' button that has appeared on all closed tickets. When clicked, you'll be taken to an interface similar to that of replying to an open, pending or solved ticket. This feature copies the original closed ticket and allows you to respond to the requester. When you submit this, Zendesk will form a link between the new ticket and the closed ticket. This should enable you to easily follow up with your customers if the solution given on a previously closed ticket is no longer sufficient."
T.J. likey. Anger regarding poor usability has been vanquished, and I can allow tickets to be closed again for my support team. Will work for me! Anybody see any potential detractors from this solution based on the use cases shared above?
Thanks for your feedback on the new follow-up ability for closed tickets. We would like to hear if this still is an issue for customers. The new functionality addresses the fundamental need to act on closed tickets without interfering with ticket metrics (as Bbrown and Nathan alluded to above).
Thanks for the follow-up ability. I do think this could alieviate the biggest problems I have with being unable to reopen tickets. After trying it out, my main complaint is that followups created automatically by attempted email updates to the closed ticket result in a ticket with different requester and CCs.
Could these 'auto followups' be initialized to be identical to the original ticket in terms of requester and CCs ? Otherwise the right people don't hear about the follow up, which is the whole point after all.
Also (this is much more minor), the title of the followup ticket includes the entire subject line of the mail, including the 'Re: [Tweak Software Support] ' that zendesk tacked on in the first place. It'd be great if it could say "Follow-up: <original ticket title>" or even "Re: <original ticket title>".
@Alan: That doesn't sound right, it should be a pretty much carbon copy of the original closed ticket. I'll need to look into it a little more.
I'm with @Bbrown, I much prefer to march things to closed & then do a back reference on a new ticket if needed.
@Michael L - you can add a trigger / notification if the ticket state goes to "Solved" and your custom field doesn't have a reasonable value ( You can also mark the custom field "Required on solved" )
@Alan - The use case you're presenting is more bug tracker than help desk. In my experience you can do one or the other with any one particular tool, but not both.
@All - you can "stop" the 30-day by "juggling" the solved status via automations (I don't know if the auto-close is "not updated in 30 days" or just "30 days from 'Solved'" ), using tags to control the juggling process
Jake - thanks for investigating. I just tried it again to be sure, and the follow-up ticket created by the agent email definitely had the agent as the requester, not the requester of the original ticket.
And to reiterate, I think the auto-follow-up is a good compromise solution to the problems discussed in this thread, especially if the follow-up ticket can be made to have essentially all the properties of the original ticket.
I am a bit late here, but I do have a question. You state that this is used to enable the ability to follow up with customers if the previous solution was not sufficient. Which makes sense to me, but I needed the ability to reopen a closed ticket so that I could change the values of the fields in the ticket that were set by my staff to incorrect values. I dont want the customer to see a new ticket, I just want to go in a change the values of some of my fields. I dont think this new feature does that.
@Alan: Argh! I'm sorry I missed this completely. I'll keep pressing to ensure we get a solution.
@Charles: No, I'm afraid not. Once a ticket is closed, it is not editable. I'm afraid we're unable to move on that position.
@Jake - Awesome, Thank you. You have no idea how much that helps me.
I just attempted a follow up and it does not seem to copy all the info. It does set the requester properly, and adds the follow up comment mentioning the original ticket. I think it needs to copy EVERYTHING (even the comments) OR there needs to several follow up ticket options (requester only, all Fields, Fields and Comments, etc.).
How about adding a tag with the original ticket # so a search finds this follow up ticket?
@Clark: That's not what happens, and is certainly intended that way. If you did that, you would be essentially replicating data in your own account, which isn't particularly good in a help desk.
However, what does happen is a relationship is formed between the new ticket and the closed ticket. You can still access the "old" comments in the link highlighted below:
Does this "relationship" between the 2 tickets keep me from having to tell an Agent to copy or retype 20 custom fields into the new ticket? You seriously can't see WHY anyone would want the option to copy the contents of the old ticket into the follow up one? I've been building, maintaining and using databases from all angles for 30 years and I GET that you've designed yourself into a corner on this (not being techically able to recover the ticket once it's been archived), but if customers NEED the old data, you should try to help figure out how to get it to them with the least possible effort, not tell then that replicating data is bad.....your applicatoin's design is what makes that duplication necissary.
Rather than continue this discussion, should I just make a feature reuqest for a FOLLOW UP CLOSED TICKET WITH CLOSED TICKET DATA ? I'm not suggesting that what you offer isn't useful to some people, it's just does not seem to go far enough to address the NO WAY TO OPEN A CLOSED TICKET issue (at least in my opinion...maybe I'm alone on this, but I doubt it).
@Clark: I see, you're referring to the actual custom field stuff, and not necessarily the comments - I wasn't getting that clarity previously. It should be copying all the relevant fields over, but in some cases it seems to be failing which we need to look into. Essentially, the follow-up feature should be copying absolutely everything over except the ticket comments and audit trail of the closed ticket.
Ok....sorry if I sounded rude before. Not my intent. What you are saying it should do is sufficient as the closed ticket can be accessed if previous comments need to be viewed.
However, I just tried this on about a dozen closed tickets and NONE of them copied anything other than the requester and the subject field. It does not seem to be copying the closed data proplerly EVER (at least in my case)
Jake, thanks for continuing to investigate. For the record, we do most of our zendesking by email, and I just confirmed that a follow-up ticket created via email to a closed ticket has as requester the sender of the email, _not_ the requester of the original ticket. This is the main problem for me. But the bottom line, as I think you agree, is that everything in the followup ticket (requester, ccs, subject, custom fields, etc) should match the original. The audit trail and comments history can but left on the original.
Hi, I'm like Charles and would like the ability to open a closed ticket to edit incorrectly entered data. If this can't be done (even just an admin ability?) is it possible to make some fileds only accept a certain value types? My main issue is that users ocasionally enter text into the Total Ticket Time box. Bar user education/training which mostly works, is there a way to change a ticket field to only accept a numeric value?
And also if possible get the user to clarify if they enter a large numeric value (i.e. iv'e had a typo of 200 instead of 20). So once its closed it skews our reports.
@Alan, Clark, Everyone: We're able to pretty easily fix the problem of things not copying over from the closed ticket. But there's a few questions I wanted to ask first.
Of course, I can just make these decisions myself, I just wanted to check it's the right decisions :)
I agree with all of the points that Jake listed above. I think that even though it's a follow up it should technically be treated as a new ticket, which means that it shouldn't be assigned to anyone automatically.
Hi Jake, thanks for asking!
You make good points, but note that most of these also apply to any ticket that has sat in Pending for a while. On balance though, as long as the followup ticket has status "New", I'm fine with it being unassigned, as long as the previous assignee is added as a CC (since that person is the agent most likely to have relevant context).
About CCs, I disagree. The negative consequences of CCs not hearing about something they care about are much larger than those of them hearing about something they don't care about. So I think it's quite important that the original requester and CCs are all copied to the follow up ticket. Also note that the followup may be generated by an agent (that's the common case for me), in which case it is certainly not on a different topic.
While I agree with all the points, you guys seem to be forgetting that this ticket can NOT be automatically created....some human HAS to actively select the dropdown to generate the ticket startup and THEN hit the SUBMIT button to create the new ticket. Shouldn't THAT person be responsible for taking everything in that list into consideration? I don't have an issue with filling in 2 fields instead of 25, but in my case, it's 90% likely the same agent is going to get the ticket back. If it's an unrelated issue, I'm not going to use this feature to copy the ticket anyway.
if it copies everything but Group, Assignee and CC, I'll be a happy camper.
@Clark A follow up ticket can also be created automatically by an end-user if they attempt to update a closed ticket via email. I think this is the reason that it's important to treat all follow up tickets like a new ticket, one that needs to be addressed and will not likely be overlooked.
I was unaware of that, but as mentioned above, it shows up as STATUS=NEW I'm not sure how it could get overlooked. Again, having to reassign it is trivial compared to trying to accurately copy 25 fields of data between tickets.
I guess it really depends how the tickets are managed, whether you monitor views or have triggers set up to let you know when there is a new ticket in your help desk. I'm having hard time deciding whether I would like to accurately copy 25 fields of data between tickets or have to remove unnecessary info that was copied over. There are definitely pros and cons to both scenarios but I think that starting with a clean (empty fields) ticket is the best way to go since the history of the previously closed request is in the comment timeline that is associated with the follow up ticket.
Maybe this horse is dead, but I'd like to remind everyone that the issue here is that closed tickets cannot be reopened. The original request and all of the comments above (from me) are directed at getting around the technical issue of being unable to reopen a closed ticket. The proposed solution is an automatically (or manually) generated "followup ticket". If it is going to solve the problem for me, it must be an exact copy of the original as far as is possible and practical. This definitely includes all field values especially the original requester and the CCs. I would prefer that the status go to Open and the assignee remain the same (since this is what would happen if you could reopen a closed ticket). If others really prefer that the status go to New and the assignee go to none, I can live with that, but I think it's important to remember that every step you take away from the followup being an exact copy of the original makes it less of a solution to the original problem.
Help me out here people... we are using our zendesk to integrate with invoicing... accounts work off solved and tagged tickets... then they macro it as charged... however if they are not onto it in the 28 days... they cannot run the macro... and the tag is not able to be removed....
Please can we have an option to extend close off time...? or a close of time related to an invoicing period (40days?) then I can threaten accounts that they must get invoices out very early the following month...
Also, I now have a lump of tickets that got closed like this... I cant open them to fix the issue...
I know this covers a few subjects... but ONE is reopening tickets!
The AUTOMATION that closes tickets is fully editable. The Zendesk default is 5 days until CLOSE. I have extneded mine to 30 days and some posting in this thread have disabled the AUTOMATION all together so their tickets NEVER close (a partial solution to the fact that you can't reopen CLOSED tickets...not pretty, but it does the job). I'm guessing Zendesk DB managers hope that everyone doesn't realize this and jump on that bandwagon as this would undoubtably cause all kinds of performance and storage issues for their back end DB (and that would cause everyone that uses Zendesk issues).
After working with Zendesk more, I see that if the follow up ticket is created by a user replying to a closed ticket email, the majority of fields DO copy (but not customer fields), if you MANUALLY generate a follow up ticket, hardly any data copies. AGAIN, this lack of consistency makes the MANUAL follow up ticket button useless to me. Can this be fixed?
FYI, this is how we manage time tracking and billing: https://support.zendesk.com/entries/210637-fyi-how-we-re-managing-c...
@Andrew: I should be very specific hear. Removing the automation will not stop tickets from closing. Instead, Zendesk will keep it open for the maximum number of days, and then automatically close it.
As for the follow up, we made a change last week which will now copy over the custom fields when a follow up is created either automatically or manually - this should now be consistent.
@Jake - What is this "maximum number of days"? I have processes involved that are counting on the tickets staying open for 30 days after being solved.
I can confim that Jake is correct and the followup button DOES now copy all ticket informatoin when creating a followo up. Thanks!
Hey Jake and crew... I just noticed this request is noted as DONE.... well... how do we do it? "..allow-ability-to-reopen-closed-ticket"
I have a small dilemma, I have 50 or so closed tickets with a tag on them that I cannot remove... this is now stuffing up my accounts depts views...
If its done please tell me how so I can fix this ASAP!
OH NO!!!!!!!!!!!!!!!!!! I just fixed my macros yesterday, and manually changed a pack of ticket to eliminate the problem caused by the tag I cant get rid of... and I missed changing my solving automation... now my NEW tag is stuffed (on a whole load of CLOSED tickets!)
Help me out here Zendesk... this is ridiculous...! Can you recover them for me or something?
I'd like to request the ability to reopen closed tickets so that we can manage our business metrics appropriately. As we add categories of issues and reorganize how we think about problems our clients have, we inevitably need to tweak the categories to which closed tickets are assigned. We are an evolving SaaS company, and the inability to categorize our tickets however we like (regardless of whether or not they are closed) means that we can never get good metrics out of the system. I don't mean to sound an alarm here, but if we never get the ability to categorize our tickets however we like, it will eventually be the clincher detail that drives us to a more robust solution. If I can't accurately measure the experience our clients have interacting with our company and our services, then the primary business value of Zendesk is gone. It's nice to have a tool to track and close trouble tickets, and, so far, I like Zendesk, but in the scheme of things that's a big yawn, from my perspective. The real value comes from being able to slice and dice the data. If I have to have all sorts of manual work-arounds to understand what my clients are experiencing, a tipping point will eventually be reached where the overhead associated with using Zendesk is greater than the value it provides.
Regardless of how difficult it is to provide this functionality (it IS possible, it's just a matter of time/effort/money), I'd like to suggest that not solving this problem is a long-term strategic error for Zendesk, unless your strategy is to service clients until they outgrow you. Without control of our closed tickets, I'm worried that we will outgrow Zendesk sooner rather than later.
Please give this issue more consideration. It's kind of big, from where I sit.
@Mark - couldn't have said it better myself! Metrics, metrics, and reporting!
A new subject for this has been opened... as this one is labelled DONE... so I guess it might get ignored (Sorry Zendesk team if thats not the case) https://support.zendesk.com/entries/360837-ability-to-reopen-tickets-and-extend-closing-period
Anybody tracking this, I have a 'work around' for this... well for the issue of running out of closing time (part of the issue)
I have an automation that picks up tickets about to close (and with a specific tag)and turns them back into pending... and then back into closed... It does this until my tag is removed. In my case, by the account dept.
However Zendesk, should I really have to be doing this kind of this to make it work?
@clark - Auto closing time max is 28 days I gather... so watch those 30 day ones! See may note to extend this... tho my rough workaround might be a bit ugly for some.
Is everyone on holiday or has the 'done' tag fooled you all?
The ability to fully re-open closed tickets or extend the period solved tickets go to closed is not something we plan on doing.
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.
@Jake - Thanks for continuing to ask about what's driving the requirement to re-open closed tickets. It's the outcome we're all after, not the process by which we arrive, so I appreciate Zendesk's continued engagement on the matter.
From my perspective, the use of tags for solving the problem doesn't work, because tags are free-form, which means that human error will cause the metrics to be incorrect. For example, suppose we want our agents to flag every ticket in a way that describes the reason a client contacted us. Right now, we use a custom field to do that. It's a required field that an agent must fill out before a ticket can be closed, and it's a drop-down box. They must pick from a list and there is no other option. Now... we could certainly put operational guidelines in place that tell an agent how to use tags to capture the same information, but that is an unreliable way to make sure that the client experience is captured and categorized accurately. Suppose, for example, that we have categories for browser type. We want to know when a client has a problem with our software that was caused by a browser incompatibility, and we want to know which version of the browser they were using. If we have a custom field that requires an agent to select from a list, we get accurate data, but without that we'll get this scenario:
Suppose a user gets an error while using Internet Explorer 6.
Agent #1 might tag that as IE
Agent #2 might tag it as Internet Explorer v. 6
Agent #3 might tag it as IE6
Agent #4 might tag it as IE 6
Agent #5 might tag it as Int. Exp. 6.0
Agent #6 ... you get the idea
With that said, if tags can operate the same way as custom fields, whereby we can force specific selections, AND we can go back and add or change tags on closed tickets later, then we may be circling in on a solution, but from my perspective, that's the same thing as editing a closed ticket.
At the end of the day, it's simply not possible to predict, in advance, with a high degree of certainty, how a business will want to slice and dice its data in the future, which is the root of the problem. Here's one more example that may provide some insights. We recently began a new method of invoicing our clients that is generating some feedback, questions, and a few problems. Naturally, we want to start capturing that experience in our metrics, so we added an entry to the drop-down box (required field) called "billing." Anytime an agent tackles a problem that is related to billing, it gets categorized as such. So far, so good, right? But this is a new feature for us and we are just now learning what the issues are, and how our clients are experiencing this new feature. It is inevitable that we will want to get more granular with the category "billing" as we gain more experience with this new feature, but I can't predict in advance what the appropriate breakdown might be. So, at some point in the future, we're going to want to go back to a set of closed tickets and re-categorize them in a way that helps us capture the client experience more accurately. This process will repeat itself over and over again, as our company grows and learns, and that's not something unique to one or two our Zendesk's clients. That's pretty much a universal need and it's a flaw in the Help Desk model, as it is currently deployed.
Again, thanks for continuing to think about this and work on creative ways to solve the problem. I am fairly new to Zendesk, so I may be missing some other ways in which to solve this problem, and I look forward to any and all input on the matter.
@Jake, Thanks for your engagement on this again... Ability to amend tags after closure would help tremendously.
@Mark... Does this help https://support.zendesk.com/entries/366131-tag-control-ability-to-specify-standardised-tags-and-redirect-incorrect-ones
Was this implemented? It says it's been "done". But I don't see it anywhere.
Looks like this was rejected, but it's marked as done. That's confusing :(
@Jake - If possible the editing of tags on a closed ticket would at least provide a work around for not being able to re-open the ticket, is this going to be possible any time soon
We track staff error rates through the custom ticket fields. The inability to go back and edit a field after the ticket has closed is a huge limitation for us.
I have run into a similar issue to Mark Deaton. As we refine our Topics and support reasons, it makes sense to be able to revisit closed tickets in order to better categorise previous issues.
As it stands this is not possible which means one category which has now been sliced into multiple categories will skew our reporting which means reduced ability to assign resources to the most needy areas. It also means it's more difficult to more specifically target training and support.
For us, the ability to at least modify fields on existing tickets, as opposed to reopening, would be welcomed.
Jake, I've got a good case for adding tags to closed tickets. I'm going to post it here: https://support.zendesk.com/entries/15987-add-or-edit-tags-on-close.... Maybe you can remove the "Not planned" tag from there, since you are considering it? :D
So what is the plan here? I noticed "Done" at the top but I'm not seeing the ability to alter closed tickets. If I missed it somewhere in the comments above, then my apologies!
Is there some article that I can read up on to learn more about altering closed tickets?
@Richard: There's no way to "alter" closed tickets, which has been the way for a while and will likely continue as so.
However, you (and end-users) can create "follow-ups". This is pretty much a straight clone of the original ticket, with a direct reference in the interface so you can still refer back to that closed ticket with ease.
For end-users, they can simply do this by responding to a closed ticket (an email sent months ago, for example) and it will create a follow-up automatically. This is seamless for the end-users, they're not particularly aware of the difference. You can even wrap rules around it (There's a "via" for closed tickets) so you can escalate higher if needed or mute email communications back to the customer to avoid any confusion.
Support Software by Zendesk