[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.
-
Editing custom fields for purposes of reclassifying tickets will allow us to better report on trends retroactively.
-
I need this option to move any closed ticket from one organisation to another, the organisation was previously divided into two and now they are one and I can not change this.
-
Our need is not tag based, but, similar to Alexia's above. We have cases where tickets are sometimes on the wrong customer, and for the most part this is not discovered until tickets are closed. We would like to move these tickets to the correct customer so we have the correct history on the correct customer. :)
Ideally this would be allowed in the UI via permission so we can restrict to admins or super users only. At a minimum, it would be helpful to at least have the capability in the back end (API).
-
+1 to reopen a closed ticket!
We handle travel agency requests of flight bookings and we like to have all requests about the same booking inside one Zendesk ticket.
With your restriction that a closed ticket cannot be reopened, you force us to create a new ticket on the same flight booking every time there is another schedule change or name change or refund request. And as flight bookings are made long time in advance, 28 days is nothing. In our previous case management system, we had cases being closed and reactivated again over a whole year.
In Zendesk, our Service Desk needs to click through several Zendesk tickets to understand what was when. This is annoying and was definitely much better in our last case management tool.
So, please, please, allow us to reopen a closed ticket!!
-
@Daniel, not sure what your particular configuration is, but, it sounds like it would be a good idea for you to extend the timeframe in the automation which sets solved tickets to closed.
-
Hi Lila,
as I wrote, 28 days is set and it is the maximum configurable, unfortunately. But the 28 days are not the actual problem. I mean, the tickets should be closed one day anyway, otherwise we would end up in having thousands of not-closed tickets. Our main interest is to be able to reactivate a closed ticket.
-
+1 for this feature too.
My main feedback here is user error on my agents part. If they forget to add a label or misclassify a ticket, it will skew my company's analytics. If they do this for even 1% of the tickets in a year, we are talking hundreds of misclassified tickets. I can throw training and other things at my team, but there will always be user error. Not to mention that a customer can close a ticket before we correctly classify and label it.
This thread has been going on for 7 years and is a simple no-brainer. Please update your product.
-
+1, Its been there for the last 9 years and still if its not developed, I am doubtful if it will be taken up ?
We have few customers data which has empty priority and need this to set a default priority for closed cases.
-
Happy 10-year anniversary :)
-
Who else do we need here to get proper comment, not one that goes by "our PM team is still reviewing this" how many PM's did went trough ZD over those 10 years?
-
One more +1.
My use case: We're in the situation of need to "backfill" data for metrics purposes. As we use the platform we make changes, add data, migrate this or that...it's easy enough to write scripts that utilize the API to update old tickets in some cases, but obviously we can update non-closed tickets. We would love to be able to update all tickets.
For example, we realized we needed to migrate a custom string field to a custom number field, and after learning we can't change the data type of a custom field once it's been created (another request...) we created a "sister" field for the same data. We'd like to drop the string field all together, but we can't because of all of the closed tickets for which we cannot migrate the data.
This makes me worry that as we deprecate old custom fields, they'll just pile up and create clutter, and we'll have to continue to add to our metrics logic to "check this field and if it doesn't exist check this field and if that doesn't exist check this field and...."
-
+1 for all the reasons everyone else mentioned.
-
+1 to editing closed tickets at least in some way.
My use-case is this:
I have ticket fields, which are used in a custom integration.
I have one ticket that has like 100 followups, presumably because the customer keeps replying to the same email when they have a new issue instead of creating an issue from scratch.
Unfortunately, this uber ticket has some invalid data in its ticket fields. This causes target failures, which causes erroneous error reports, and failed integration updates, every time this customer opens a new ticket by following up on the initial one. Because Zendesk helpfully copies the data from the original ticket into the new followup.
I realize that there are numerous ways to address this. Our integration could look out for this specific failure. The customer could be educated to create a fresh ticket instead of creating unrelated followups. But these are poor practices.
Hardcoding a single exception is a terrible software engineering practice.
Advising your customer that they should use your helpdesk in a special way is a terrible business practice. (It's also in no way guaranteed that they would listen, or care. Which they shouldn't; it's not their problem.)
The best solution would be to fix the invalid data in the ticket. I would be fine with making it a special circumstance that required me to sign a waiver or something.
-
We also need this, the use case:
We have integrated Jira and Zendesk and want our customers to be able to track the linked Jira bugs through Zendesk without actually keeping the support tickets open.This would mean that we expose the linked bug and status in custom fields and sync them with Jira.
Keeping the Zendesk tickets opened until the bug will get implemented will break the SLAs so we need to be able to update the custom fields after the ticket was closed.
-
+1, extremely useful
-
+1
This is a feature that would be useful for Zendesk Admin users. I'm running into scenarios where our organization's closed tickets are not categorized properly, or are missing info in fields that are now listed as required. This is causing issues when we go to report on this data.
-
We absolutely need this feature to be able to clean up tags and tickets assigned to the wrong group. It is disappointing to see that this has been a Feature Request for over 10 years.
-
Preach! ^
-
Hi Judd and Jon,
We understand your frustration. Trust me, it's not super fun for us to tell you what's not coming - particularly when there are a lot of great reasons for the product team to build something that they just haven't been able to get to.
That being said, longevity of a request is not a data point that our product teams consider when prioritizing what will go on our roadmap at any given point in time. Just because something was asked for a long time ago doesn't make it feasible, or the best idea or most important things for us to build.
To provide some context, we receive hundreds of feedback requests every month, but can only develop a few dozen each quarter. This means that product development is a constant and ruthless process of prioritization. Sometimes users suggest something that is a really good idea, but it's just not more important than the other things we have to put ahead of it. This can mean a request can get put off for many development cycles, particularly if it's a nice-to-have and not business critical.
When prioritizing things, we look at the impact it has on a business, how many users it effects, what the most common use cases are, market and industry trends, and how it fits in with new innovations we have in the pipeline. Sometimes, we have to build something else first to lay the groundwork.
It should also be made clear that the product feedback topics in the community are for discussion of challenges, but are not a case --> resolution system. There are no guarantees that we will build everything asked for, no matter how long it stays live or how many votes or comments it gets. But the conversations that happen here do deeply influence our product decisions.
The product manager for this particular area of the product has told us that this is something that's being looked into. I wish there were more we could share with you at this point, but please know that this is movement in the right direction. It's just an ask that has some very complex implications, so the exploration of it is quite involved. Thank you for your patience and for sharing your feedback.
-
This thread is currently closed for comments, as additional use cases are not currently needed. Users may vote on the original post to express support for this request.
We will reopen for comments if and when the product team indicates that more user stories would help with making a case for this development.
Post ist für Kommentare geschlossen.
260 Kommentare