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

260 Comentários

  • Irith Williams
    Ações de comentário Permalink

    @Andrew I appreciate that community threads are not the same thing as closed tickets. 

    My observation is that the behaviours are essentially the same. Wanting to query an historical dataset to assign attributes and then organise based on those attributes.

    Nicole wants to query a dataset (community threads) > to identify an attribute (feature request that has been built) > to gain insight into a pattern   (user requests against feature build)

    That is what tagging gives to tickets, to assume tagging is no longer relevant after a ticket is closed is not supported by user behaviour (it has been a feature request for at least 10 years.) So I want to perform exactly the same sort of analysis that Nicole is offering, but I need to be able to retrospectively assign attributes to tickets (tag) in order to perform this analysis. This makes sense, as organisations might have questions that evolve over time (like Nicole offering this new way of querying the data) so with new questions comes the need to assign new tags.....

    On further inspection it seems to me that there are a bunch of 3rd party apps that integrate with ZenDesk to offer this type of data query ...

    0
  • Imbi Joy
    Ações de comentário Permalink

    +1 For this capability.

     

    Current use case for my company is that the account manager associated with a customer changes periodically. We have tags associated with the account manager's name, with the tags we create views based on the account manager's name so they can easily see any tickets associated with their customers. This causes a problem for closed tickets as the tags are not updated. Also, my support group has recently re-vamped the naming and options for a few tickets fields that would be great to update in closed tickets as well. This aids in a more comprehensive and complete ticket analysis when exporting data via Reporting/GoodData (e.g. someone looking over the GoodData spreadsheet doesn't need to know that in 2017 and earlier the 'product area' ABC synchronization existed but in 2018 it was renamed to XYZ synchronization, we want to change ABC text to XYZ).

    0
  • Support Admin
    Ações de comentário Permalink

    +1 need to be able to edit closed tickets' organization for our retroactive reporting purposes, especially after we update/sync organizations between our database and Zendesk

    0
  • Craig Willis
    Ações de comentário Permalink

    +1

    My issue is one of customer privacy.  We allow select users of our customers view all cases submitted by there organization.  However, some tickets we closed while the agent was list against that organization, so now, our customer can see some cases from another customer.

    I've submitted a case to get this addressed and this is a real privacy concern for me now.

    Craig

    0
  • Blair Bethwaite
    Ações de comentário Permalink

    +1. This is so basic I struggle to see what the fuss is and why it wasn't done years ago. I'd also challenge the notion that it's such core functionality that it is hard to change - if this is true then there are some serious design and architecture problems under the hood.

    @Nicole, any updates on progress here. Did the team end up reviewing this in Q3 as previously intended?

    0
  • Bill Cicchetti
    Ações de comentário Permalink

    Another case in point.  there is a known issue with using the canned CSAT functionality will auto-generate a Rating of BAD even when the client does not respond to the embedded survey

    We now have CLOSED tickets that have a rating of BAD and effecting our CSAT scores.  We should have some control over our Closed tickets. 

    0
  • Chad Kocherhans
    Ações de comentário Permalink

    +1

    We need to add tags to closed tickets for crucial reporting purposes.

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

    +1 

    Not that I am expecting my request help move this functionality forward (so sad to upvote a 10 year old feature request)

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

    Been active watcher on this thread for 2 years now, I can finally say I need this to be changed as well if someone in the Product team of ZD is even aware of this anymore.

    0
  • Nicole - Community Manager
    Ações de comentário Permalink

    Hi Rotemi - 

    The product team is aware, and as indicated in my last comment, have been exploring what would be involved with making these changes and when would be a realistic time to put that into a roadmap. They have not yet slated a timeline, but this is something that they're actively looking into. 

     

    0
  • Lila Kingsley
    Ações de comentário Permalink

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

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

    +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!!

    0
  • Lila Kingsley
    Ações de comentário Permalink

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

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

    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.

    0
  • Dru Kepple
    Ações de comentário Permalink

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

    0
  • Charles Wood
    Ações de comentário Permalink

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

    0
  • Nicole - Community Manager
    Ações de comentário Permalink

    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. 

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

    @francis tan, I recommend you open a support ticket about this - possibly the team may be able to retroactively fix this on your behalf for this one off issue.  

    You will then want to look at tag management and make sure it is right going forward. :)

    -2
  • Nicole - Community Manager
    Ações de comentário Permalink

    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. 

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

    Sorry guys, there is simply no plans to allow closed tickets to be edited. This includes tags. 

    -12

Publicação fechada para comentários.

Powered by Zendesk