[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.
-
Neill is right, we need more than just tag editing.
Better yet, please consider making 'Can edit Closed tickets' a permission set for User Roles. There are users we would trust with this that would not necessarily be administrators in our system.
We have agents assigned to QA'ing agent tickets, if they could note compliance issues and fix issues with closed tickets, this would be better for our data quality. -
I would really really like this. I frequently go back to old tickets and find they're lacking in tags, but once a ticket is closed we can't edit those tags. It would be very nice to have this functionality.
-
+1, would be very useful to flag patterns that are only identified over a longer period of time
-
Andrew Reback +1 for this, as it stands tags are all but useless for me.
-
Thanks for the continuing feedback, all. As always, detailed use cases about how this functionality would serve or impact your business carry the most weight.
If you haven't already, please use the voting buttons on the original post to up vote.
No additional updates to share at this time; the feasibility study is ongoing.
-
Very happy to see this now has potential. It's wrong to assume that our agents are flawless in their field selections, and towards having the system correctly represent the data we want when collating our metrics, this is quite a vital change. I don't believe anyone wants to remove comments here, just the ability to offer limited users the chance to make updates at intervals that are much longer than the "solved to Closed" time window, which for us is only 10 days.
-
+1
-
Wait what? Zen Desk does not allow closed tickets to be modified? How about moving closed tickets from one group into another? Is this possible?
-
If this is not possible -- being able to move closed tickets form one group to another, this is surprising and I
vote
+1
-
Hey all -
Please use the voting buttons on the original post to express your "+1" and use comments to share details.
-
where is the voting button?
-
It's the arrows on the original post.
-
This would be incredibly helpful for us. Do you have an ETA of when it would be added?
-
Hi Alejandra -
We use an agile product development process and this is in the early stages, so we do not have an ETA at this point in time. But we will continue to update this thread as it moves along.
-
Hi All! Glad to see this as a planned feature--I know this has caused some confusion for users when they've run into this limitation.
Just to do some shameless self-promotion until the Zendesk team is able to implement these changes, I do have a paid app available that can assist with getting around this: https://www.zendesk.com/apps/support/clone/ (which has a 7 day free trial)
The workflow would be to clone the closed ticket (modifying the tags or other fields), and then deleting the original. The cloned ticket is a 1:1 match with all comments and close/open dates so there isn't any data loss. Happy to discuss more in-depth about your specific use--just click the email or website link on the app link
-
Thanks for sharing that resource, Andrew!
-
I would like to add a legal consideration on this feature (being able to change the close tickets).
Since a closed ticket cannot be changed, it can be considered as an archive. From a legal perspective, this is a valid data.
If there is a possibility to change the closed ticket, it would be considered as an historical data and not an archive. From a legal perspective, it is not a valid data.
So, if zendesk gives the possibility to update the closed tickets, there will be no ticket valid from a legal perspective.
Knowing this, I don't think it is a good idea to be able to change the closes tickets, unless zendesk add a new status called "Archived" and that the admin can bulk change the closed ticket to archived tickets
When reading the threat, I think there is a misunderstanding between what is "historical data" and "archived data"
-
That's an interesting comment Andreas, but does adding a tag for the purpose of categorising a ticket constitute a material change to the ticket?
I would argue 'no', and that it's simply improving our ability to file and categorise tickets without changing the content.
-
Hi William,
Everything goes around the word "argue". On a court, the best is to close every dispute by a "yes" or "no" without any "but" ! Of course you can argue, the attorneys love this sport !
I am maybe excessive, but prevention is better than cure.
-
Well, if you go down that path, the real question would be... why are they having to "lock" this data after only 1 week? I still don't like the TAG only update idea, I strongly prefer to be able to modify our customized fields, as stated above, since agents make mistakes, and if I can correct some fields our metrics can end up making more sense, that has more value to me than being stuck with an incomplete/incorrect frozen record.
-
Agreed! 100%
The legal argument is easily solved by ensuring an appropriate audit trail for all modifications, which Zendesk already provides.
The inability to modify tags makes tagging all but useless without considerably clean-up efforts. I cannot, at a glance, see what is actually going on because people tag things incorrectly and they cannot be fixed so are forever polluting the tag cloud.
The inability to modify custom fields similarly ruins reporting from those fields.
-
Andreas,
You've actually highlighted one of the primary reasons we haven't allowed changes to be made to closed tickets to date. The ticket system has long been considered a System of Record, and allowing changes after the fact does challenge the integrity of the data.
That being said, we also recognize that sometimes the way people catalog tickets (i.e. adding tags) evolves over time and they may wish to alter tags so that historical reporting matches current organization.
This is part of what is being considered as the team is going through the evaluation process. Certainly an archived vs. Closed data set is one solution, and the team is looking into all of the possibilities.
-
Hi Nicole,
The solution maybe in the agent roles by giving or not the possibility to close tickets (like it is today for tickets deletions) while the closing at the latest automation should remain (nobody wants to do the cleaning...) - but not sure if after there is a back door via the api or even an automation/trigger.
But at some point, guarantee "frozen" data is a must. Closed status does well the job today.
-
So the reality here is that there are 2 competing needs. Some need this data to be "frozen" and some are less concerned, or simply do not have such a requirement in their processes. While I like the idea of "closing" a ticket which locks out the customer from adding comments weeks or months down the road, the fact that this "closure" also locks out agents is essentially the root problem.
So why not keep the rules on ticket "closed" state the same, but add a new "lock" state, and have the "ticket lock" timeframe be a setting that is flexible for everyone? Those who need things to lock after 1 month would remain satisfied with the current imposed situation, and the rest of us could extend this "ticket lock" timeframe to something longer, like 52-weeks, thus giving us the flexibility we are looking for in making modifications to fields to correct agent errors and yield more accurate metrics.
-
An alternative to this is setting your 'close ticket' trigger to longer than 28 days (default). I set my tickets to never auto close until after a year old so I can go back and code my tickets as necessary.
Side note: Merged tickets automatically are set as a 'closed' status and cannot be edited. +1 on the original post...
-
I've recently migrated over a couple of hundred tickets from a different help desk system. Several of the fields didn't migrate perfectly, so I was updating them manually. Specifically tags, and some custom fields I'm contractually required to maintain. As I was doing this, all of my solved tickets started changing to closed about 45 minutes after the migration. This made them effectively useless to me. I might as well not bothered to migrate them. The fact that I, as the data owner no longer have the ability to correct my records less than an hour after putting them into your system is incredibly frustrating. Now I have to spend $10 on some ticket cloner because Zendesk won't let me control my tickets? Please fix this.
-
@chris I believe theres a 1000 solved ticket limit thats an unwritten rule—and then it auto closes. You might want to try importing in bunches
-
+1 on this.
Customer support is using the system to take care of the customer while engineering has access to the system in order to identify/track trends. The tag field is unrelated to data integrity and I see no reason why that one field cannot be editable. It would be extraordinarily useful.
-
+1 on this from here.
We have recently gone live with Zendesk. What we have found since we went live is that some design descisions made adversly impact reporting.
We particularly have a lot of parent child records where data fixes are neede to sync up some parent information to child records for GoodData to be able to do analysis. A solution for us would be to inject tags into closed child records in order to populate data with parent tags.
-
+1
Also important for the upcoming GDPR legislation; if a customer wants to modify data or delete data in a ticket which is closed, we cannot redact the ticket to anonymise it anymore and deleting it will result in a loss of data (quantitative/qualitative non-personal data)
Publicação fechada para comentários.
260 Comentários