[Closed for comments] Add or Edit Tags on Closed tickets
I realize the ITIL importance of making closed tickets un-modifyable, as a system of record. But, as a part of post analysis and reporting on hundreds of past closed tickets, mining for patterns of support issues, etc., I would like to be able to add and edit the tags on long closed tickets. For example, if I have an epiphany and want to do something in my Zendesk to help me with something like, "Wow, we sure seem to have been fielding a bunch of upgrade issues with our installed customers over the past 3 months. I think I'll go try to tally those tickets into some kind of category..." ...just as an example. It seems that post tagging might do the trick.
Any thoughts / opinions?
David.
-
I have many of the same needs as the others listed here:
- change tags on old tickets to match evolving standards
- fix tags on mistagged tickets which have closed before we noticed
- add tags to capture new information that suddenly became interesting in old tickets
All with the goal of reporting about stats on all tickets - including both old and new. Things like SLA misses (which we use a tag for that is manually removed in case it was on there in error) can make a big difference in perception and in the bottom line - do we need to hire more support engineers? Do we owe our customer a $100,000 refund for failing to adhere to our SLA's?
It would be acceptable, though non-awesome, if there were editable "meta tags" that could be manipulated that are not technically part of the ticket tags but still are per ticket. Workflow could be: tag added. trigger adds forever-editable "meta tag" and/or I review an old ticket and add it myself. Insights supports meta tag reporting. Suddenly my SLA graphs are true again.
-
+1 on this.
Tagging has limited usefulness without a better ability manage tags at the admin level. Unless you came out of the gate with a robust tagging convention, your tags are probably a mess and will be difficult to get streamlined even in the future.
A great Step 1 would be to make it possible to define your list of active tags at the admin level, and prevent agents from creating new tags on the fly. We have simply had too much tag proliferation, and even if we want to implement a stricter tagging convention moving forward, it will be difficult to do this when agents have hundreds of tags available + the ability to create new tags.
Step 2 would be the ability to clean up old tags through merging, pointing, and/or deleting.
I've been surprised to learn that these features don't already exist given how well-built ZenDesk is in so many other areas.
-
I think it's complete nonsense that as our business evolves and our data analysis capabilities grow that we don't have the ability to re-characterize tickets (by updating/assigning relevant tags)..
I'm getting really fed up with limitations everywhere I turn.. and seriously considering a migration.
-
Also, keep in mind that the comment regarding ITIL standards was simply a blow off.. there's nothing in the standards that prevents you from being able to re-characterize closed records..
Our reporting standards will change over time, and certain tags will have to evolve.. and the fact that we will not be able to go back and edit those tags means that we will eventually have to move to a solution that allows us to manage our own data.
-
+1
-
+1 or even +2 on this!
If you are heavily using tags for statistical purposes you're going to need this sometimes.
-
+1
I have a similar use case to those mentioned by many other users in this thread. There are over a year's worth of tickets in my Zendesk account, many of them already closed, which I want to tag for a number of metrics that we didn't know we wanted to be able to gather at the time the tickets were closed.
-
+1
I think it would be nice being able to change/delete the tags on closed ticket for all reasons already given in this thread (old tags not relevant anymore, typing issues, etc...).
The only way I found out to make my own tags cloud with the relevant (or renamed tags) is to use the API and before printing my cloud, make all those different operations (delete/replace/etc..) within my script after calling /api/v2/tags.json
A bit a lot of work for some cases, but I don't see any other option today
-
+1. A fledgling product's community team is going to have a lot less insight into the best nomenclature to use for their product and userbase than one that has existed for a long time. I want to be sure that the tagging system that I come up with now has the flexibility to grow with our product. It doesn't look like Zendesk has the ability to give me that assurance right now, sadly.
-
+1. It seems like they could add a new type of tag that can only be applied (added/removed) to a closed ticket, that would not actually modify the ticket. The closed ticket could still be seen in it's pure original state. ITIL standards would be preserved.
Since this request has been unmet now for over 5 years I doubt they are going to fix this. Time to look at competitors if you really need to do full data set analysis..
-
+1. Could not agree more. The lack of response or explanation form Zendesk on this is deafening. I've never seen them actually explain that ITIL standards are the reason for not doing this - it's been an assumption made by forum posters over the years.
This one issue alone tells me how little zendesk actually care about their customers. I tell anyone looking at system to steer clear of zendesk. Not because of the product itself - but because of their poor responsiveness. Amazing that a support systems company should itself have such poor customer relationships.
-
Any update from Zendesk?
-
I've been in this situation before where closed tickets could no longer be edited; but needed to be needed to be edited. Especially where tags are then used in reports and other calculations that might be in play
This workflow was actually one that I had in mind when creating my paid app called Clone that was just added to the Zendesk App Store.
The Clone App copies the tags and other details exactly from the original ticket and creates a new ticket that is not closed with the same ticket tags, details, comments, metrics, etc.
After you've cloned a ticket, since it maintains all of its original data; you then have the option to delete the old closed ticket if you'd like (since this would be an un-needed duplicate) -
@andrew...it even holds the ticket solved date? even though you're going to solve the new ticket ostensibly with a new solve date?
my need for this is because we've replaced tags along the way and I'm not finding the data I need when I do history. I'd love to be able to export all my data, run a query to perhaps "update all tickets with the tag 'passwrod' to 'password', and slap that back into my system.
you can imagine what my GoodData / Insights stuff looks like when I have to run for TWO tags because someone couldn't spell.
If I got rid of all the tickets with the incorrect spelling and updated those, I could clean up that query.
I know I also have tickets that are totally missing data because I didn't find them until after 30 days and they were closed.
speaking of which...is it possible to DELETE a tag from Zendesk? I really don't want "passwrod" in my list. How do I kill that?
-
Hi Diane,
Yes this holds the solved date which is just awesome for fixing those faulty tags--and yes I can imagine your GoodData data as I've hard the same issue before in my day job managing a team :-) Theres also another issue with tickets going to closed once you have 1000 in solved that gives you the same issue if you've removed that "closed" automation
Your workflow for correcting the data seems accurate, and was actually something I had to do in the past.
While we are on tags, 1 thing to keep in mind is that I do however add a cloned_ticket tag to the new ticket for tracking purposes--hope that wont cause too much trouble; but felt that it would be needed by someone at some point to track these new clone tickets down--or for auditing purposes.
Regarding GoodData, unfortunately in my experience, there isn't a way to remove a tag from GoodData--once its there, its there since theres a history trail of deleted tags on a ticket. The Zendesk folks might know better though.
-
+1
-
@andrew
i saw the "cloned_ticket" tag...i do things like that to identify anomalies. That makes sense if you really want to identify this isn't the original.
I'm not dealing with any sensitive data. I like to keep all this for statistical purposes.
For reporting, I'm not concerned about deleted tags...but I just don't have to search for "password" and "passwrod" to make sure I'm identifying all tickets dealing with a password reset that I didn't catch before I realized someone couldn't spell. :)
that's my main use case here.
-
+1 on this as well. Pretty much everyone has outlined the use case for this in great detail. I understand product feature decisions are hard to triage, but that this has been an open ask for 5 years seems extreme. I need my org to be able to get more out of ZD than they put into it, and if there's no way to periodically sanitize our data (align tags to new schemas, add tags to cases that are found to be part of a trend, etc) this is near impossible.
-
+1, it is just not of this time to have a system that is so rigid that you can not even improve upon your reporting capabilities.
-
+1 Not having the ability to even add a incident to a original problem after it is closed causes major issues with reporting as well as being able to keep track of all of your major problems.
-
I wish edit-ability was available for merged tickets that were merged by accident and now closed.
wow that reminds me, can we have an un-merge feature please?
-
Ugh, I just want to correct typos that arose from manual tagging. (e.g. change nisdc-0051 to nsidc-0051).
For context, this is the dataset which a user had a question about: http://nsidc.org/data/nsidc-0051
-
Shameful behaviour from Zendesk - ignoring the demands of customers like this for 5 years. They could easily allow this with an admin-only "Enable closed ticket modification" setting.
-
Hey everyone,
I won't beat around the bush on this one: there are still no plans to allow re-opening or editing of closed tickets. Our stance on this request has not changed. This will remain marked as "Not Planned".
We obviously still welcome feedback here, particularly around why you need to do this. I appreciate many of you have already done this.
Whilst the re-opening or editing of closed tickets is not something we plan on doing, we may be able to find solutions to problems you're having as a result of not being able to do this. That is why we'll always ask "why?", sometimes repetitively and annoyingly, to any feature request.
-
Jake, it's not even editing tickets that we're asking for, just the ability to change tags on closed tickets in order to allow them to be included in reports - when I say "reports", I mean searches by tags. I don't want to modify anything else - I don't have the time - but I want to be able to quantify accurately the number of tickets I have using particular tags. There's an audit trail of changes to tickets - so what really is the problem - or are you guys just hung up on an itil principle?
-
At the suggestion of some experts in your analytics dept, we recently changed our flow for handling bad csats by closing out tickets immediately when the requester rates their experience. Previously, we had a very house of cards flow in order to properly follow up, but were having issues reporting on agent CSAT properly.
However, since changing, the follow up process is a nightmare. Our process is that team leads review bad rated tickets and choose whether or not to follow up, but have no way of marking a closed ticket as reviewed, which is adding the unnecessary work to this process.
I second the motion to have SOME functionality regarding editing a closed ticket. There are too many use cases to warrant complete inactivity here.
-
@jake - When I read through this list of comments in this matter I can't see any reason why Zendesk shouldn't make this possible.
Couldn't you please tell us what the problem is? Is your entire database structure build upon this fact? I want to understand why you can't just fix this - but I just don't see your point of view?
And if you don't make your point of view more clearer - then I just can't stop being extremely annoyed on you in this matter! :)
(my solution to this is to NEVER set a ticket as CLOSED - but this can't be how to do this)
Best regards
Andreas
-
@jeremyp - editing tags is editing tickets. To move from fixed state to the ability to edit anything would surely entail adding functionality back by way of editing. It would also require a reverse of the archiving action. Maybe you could open a seperate topic about this so that we can discuss the issue - it occurs to me that if you want to change the tags, you would need to find the incorrectly tagged ones... could you therefore create a search that looks also for the conditions or incorrect tags rather than just the right tags? I understand that tagging is not the ideal way to generate reports - but we do it a lot too :) If you open a new topic about this issue - I'd be interested in looking at it and seeing the issue and possibilities.
@jeremy - what is the reasoning behind closing the bad CSATs - rather than leaving them on hold or open for the person to review? I understand you've had some advise. Maybe you could open a specific topic on this and post the link back here so we can discuss. I would be interested in why this is done, and we might benefit from discussing the issues and options.
@Andreas - probably the accessibility to 'view only' the ticket involves a lot less resource drain and speed issues than having these tickets available for editing. And since the recent addition of archiving tickets so they are less accessible - I am picking that is a similar reason. I don't understand the technicalities, and you may more than I do.
Having large numbers of tickets slows the system down somewhat. Our company is processing up to 1000 tickets a week - our total unsolved tickets might get up to 600, and unclosed might get up to 1600. If these were available indefinitely - we would have 170,000 tickets accessible - that sounds like probable impact. Not only for us, but everybody else on the same server... other companies may have far more than this... so conceivably, the accessible tickets on a server could go from 100000 to 100+ Million.
-
Thanks for the reply Andrew, and your argument makes absolute sense, but it indeed sounds like there are conflicting functionalities at work.
In regards to CSAT, the primary issue was being able to accurately report on which agent received the bad rating. Because of our volume, agents do not own their own bad csats. Having a round robin approach works much better for meeting SLA, changing bad to good, and a lower overall full resolution time.
Good Data does not support this flow. There is no way to track csat by updater at the time the rating was submitted by the requester. We've attempted to work with a system of triggers to keep the original assignee for the duration of any post-CSAT events, but this is inconsistent enough to skew our metrics and present unfair data to our agents.
After exploring the reporting possibilities and limitations, we were told that our flow was unique and the standard recommendation was the close out tickets immediately after a rating is offered. While this indeed solves the issue of accurate CSAT per agent, it prevents a bad ever being changed to good (granted a very small percentage), and makes follow up very difficult, as the teams who monitor these find the new flow extremely inefficient.
-
@Scott - I think that what Jake is saying is that Zendesk will look at solutions for problems, but not at adding the general ability to edit closed tickets.
I feel pretty certain that 'editing closed tickets' is not it's own primary task or reason for existence for any Zendesk operation; but that they want to edit tags for a specific reason that makes sense in the here and now. For example, when tags change over time, historical reporting can get difficult. And if that is the problem, I'd need to provide some defining information to really give an insight into the problem. How far back I'm reviewing tickets, how I am finding the specific tickets I wish I could change, what other things have I tried to get the same info, how am I going to make the data consumable.
In the moderator team we, try to keep discussions in the 'problem space' - and, as much as possible, leave the solution suggestions to the team who understand the technicalities and business decisions - not to say that we don't give them a few 'this is my ideal' thoughts from time to time! :-)
I'm fairly certain that given specific problem information - without presuming on a single solution, there will be a more construction conversation. I would also suggest that if you have a specific problem, open this in a new topic and link to it from here.
Publicação fechada para comentários.
260 Comentários