[Closed for comments] Add or Edit Tags on Closed tickets

260 Comentários

  • Tim Book
    Ações de comentário Permalink

    +1

    0
  • Andreas Larkfeldt
    Ações de comentário Permalink

    +1

    0
  • Eric Rodriguez
    Ações de comentário Permalink

    +1 Same use case as Jeffrey Wood.

    0
  • Customer service
    Ações de comentário Permalink
    • 1
    0
  • Xavier
    Ações de comentário Permalink

    Same need here. This is really essential!!

    0
  • Francis Tan
    Ações de comentário Permalink

    Thanks for the tip @andrew. I'll do that. I just need to finish up cleaning my tags for now. 

    0
  • Daniel Reed
    Ações de comentário Permalink

    +1 one for this.

    0
  • Wilson Morales
    Ações de comentário Permalink

    +1 on this.

    0
  • Sameerdeen Ahamed
    Ações de comentário Permalink

    +1

    I need to edit/modify TAGS to our closed tickets.

    0
  • Ken Foulks
    Ações de comentário Permalink

    +1

    0
  • Rene de Haas
    Ações de comentário Permalink

    Any update from Zendesk?

    0
  • Andrew B.
    Ações de comentário Permalink

    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)

    0
  • Diane Albert
    Ações de comentário Permalink

    @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?

    0
  • Andrew B.
    Ações de comentário Permalink

    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.

    0
  • Olivia Hopkins
    Ações de comentário Permalink

    +1

    0
  • Diane Albert
    Ações de comentário Permalink

    @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.

    0
  • Jake Holman
    Ações de comentário Permalink

    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.

    0
  • Andrew J
    Ações de comentário Permalink

    @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.

     

    0
  • Jeremy Flanagan
    Ações de comentário Permalink

    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.

     

    0
  • Andrew J
    Ações de comentário Permalink

    @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. 

     

    0
  • Sharon Asulin
    Ações de comentário Permalink

    + 1

    Part of the support team work is continuous engineering. This results in a more efficient support work (tickets deflection, better flow of work etc). However, it requires the ability to look at all historical tickets and perform grouping and filtering in a way that will allow reaching meaningful conclusions. 

    Unfortunately, by the time Zendesk implementation in my organization was completed and all the processes around it were also finalized, over 710 tickets were archived without custom fields such as "categorization" that were added during the implementation process, being updated.  

    The fact that I can't now review those tickets as part of my analysis is a big problem. A lot of information just lost.

    If I could now review those tickets and update this custom field or add a specific tag to associate them to a certain category, it would have had a a big impact on my analysis results. I lost almost a year of data, as this field was added only recently following one of Zendesk "best practices" articles.

    I also think that if customers continue discussing this over 8 years, it should have gotten some more attention from the Zendesk team. At least provide a valid workaround.

     

    Thanks :)

    0
  • Dale Slear
    Ações de comentário Permalink

    I can't agree more with this either. I'm in a situation where I'm analyzing past support tickets and I'm handicapped by not being able to filter and segment the data correctly. This would not only help the organization understand past patterns, but also enable for a better setup in tagging in the future. It's crazy this hasn't been added as a feature yet. All we want to do is update the tags regardless of status. 

    0
  • Andreas Schuster
    Ações de comentário Permalink

    Regarding "I want to edit tags", wouldn't it be possible to create custom queries for specific groups of Tags which should be counted as one in insights?

    0
  • Andrew
    Ações de comentário Permalink

    +1 - there needs to be a feature to atleast remove tags. clogging up my inbox

    0
  • Melinda Stanley
    Ações de comentário Permalink

    To address the 'why' in some fashion: one thing that adding this feature would assist in is erroneously applied automated tags. Some tickets we have are closed (automatically in the case of some Jira sharing instances), and will have automatically added tags such as 'this'.....so now I've got 80+ 'this' tags that I can't get rid of for reporting, because those tickets are closed. Other than entirely disabling automatic ticket tagging, we're still going to run into this problem continuously with tickets. 

    This is only one example of why tag modification on closed tickets would be extremely useful for reporting purposes, previous comments also highlight a learning curve issue as well as reporting needs after the fact. Even if this option was only made available to administrator users for management purposes, it would be greatly beneficial for backend tracking.

    0
  • Andrew J
    Ações de comentário Permalink

    @Melinda - I agree with the 'dumb' tags created by auto-tagging.  We have a trigger that removes specific dumb tags we were seeing on ticket update.  This helps with future tickets, not past closed ones.

    Our list currently includes;

    "serial please would thanks through new can cannot computer white help that logo asap someone like following back trade see one list some setup dave error ticket helpdesk website company machine cost buy who site box office change"

    Using tagging for reports is not recommended by Zendesk - but we do it. In Insights you can filter to include only specific tags.

     

    0
  • Yazmin W.
    Ações de comentário Permalink

    +1

    We just realized we have a pattern of support requests and wanted to go back and tag the tickets that were closed, so we can do a search of these requests at later dates.

    We can search on a keyword that pulls up the issues; however, that also pulls up other issues that happen to mention that word.

    This is why adding an issue-specific tag is our solution, but it won't work if we can't tag closed issues, too.

    0
  • Heather Rommel
    Ações de comentário Permalink

    A slightly new(er) use case that came up for us on editing/adding tags is when you have a dropdown field selected, it adds a tag to tickets. As our processes evolve and shape, sometimes we want to edit the tag the field creates, but that only updates it on non-closed tickets. That poses issues when we pull reports or pull up an old closed ticket.

    The field shows an error because the old tag has been changed or the selection for that dropdown no longer exists, therefore nullifying the tag.

    0
  • Nicole Jackson
    Ações de comentário Permalink

    +1 Our use case is - we have particular automation based off of tags. Given the manual nature in which we sometimes add a tag.. this leaves room for error and accidently adding the wrong tag. "suppress_satisfaction_email" instead of the tag that will trigger an automation "suppress_satisfaction_survey". When somebody adds a bad tag or misspells a word, we want to be able to delete that tag so others don't see it when they start to type and continue to use the wrong tag which will never do what they intended for it to do (suppress the email).

    0
  • Nicole Jackson
    Ações de comentário Permalink

    Thanks for the tip Andrew

    0

Publicação fechada para comentários.

Powered by Zendesk