Allow end users to update fields after ticket is created
Sometimes our end users change their mind, think of a better way to summarise their issue or request that we change the requester to the person who experienced the issue as opposed to the person who emailed/logge into Zendesk. I appreciate that some fields should really be untouchable to the end user at all times (eg. assignee, group, status, etc) but would like the ability to allow the end user access to their own fields (perhaps a flag on the ticket field? we currently have one that allows the end user to populate on logging, could we have one to allow the end user to populate on update?)
-
Zendesk you had one job!!!
How is this basic feature request not fulfilled after 5 years of user requests is beyond reason. This is completely unacceptable!
Our end-users are unable to even alter the subject of the tickets they file. -
Darien,
It's actually been over 8 years that this topic has been open. Fear not! It may seem like a really long time with no resolution but I can assure you that there are other topics that have been open for far longer (many years more) with 16 pages of comments that have still not been addressed. It is completely normal here. This lack of attention in no way means this topic is dead... nor does it mean that this issue is not a valid one, important, affecting a large portion of the user base and clearly an obvious flaw that should be addressed. However, this is the ZD forums where good ideas go to die. It's just not this topics time. It's not dead yet. This topic is still in the early phase. If we get up to 5 or 6 pages someone from ZD will maybe tease that they are looking at it or a moderator may chime in telling everyone to keep pushing. This in no way means anything is going to happen. It is just the next phase. They really don't like to say no at ZD so it will just remain an open sore, a scab that users will pick at every now and again.
I believe that this and other "features" that people complain about are there because of limitations in the core of the product. If it were easy to fix I think they would. I don't think they are purposely ignoring us. It is just that they look at these issues and know why it is the way it is and know that its not easy to fix. The issue really is that they need to either bite the bullet and start addressing the hard to fix issues or just tell people we would love to but the way the product was developed limits out ability to change this feature. It's not going to get addressed. Then we all know where we are and can make choices and move on with our lives. Instead, they develop features that no one asks for or wants but are easier to develop and then try to up sell those features. Leaving these topics open for years is just insulting to your loyal base and, in a public forum, exposes ZD horrible customer service and lack of respect for their loyal base of paying customers. Honestly, if I had seen these threads going on for years I would never have started with ZD. Both because of the basic issues with the product that are exposed and the lack of response from ZD. Totally embarrassing. If I were a competing product my comparison sales brochure would just be a link to a few of the ZD forum posts going on for 15 years.
I really wonder what is going on over at ZD. Who in management thinks its ok to have a request topic open for 10 or 15 years. It is just the wrong way to handle it.
By the way, I believe the official work around that our customers (end users) have implemented is to just create another ticket with the right subject or the right priority. So now we deal with a bunch of duplicate tickets that are just slightly different. When you contact the customer about the duplicates I usually get, "well your stupid ticketing system wont let me change... so I just created another ticket". Totally efficient and not at all embarrassing. Honestly, there are far more serious issues with the product to get bent out of shape over.
Welcome to the forum. I see your kinda new here. Initially, I just used the product without really implementing a lot of it. After a few years I dove in head first and tried to implement a lot more. As I ran into issues I discovered the forums and found others with the same issues. Some of my issues were resolved by solutions others posted. Some were just issues that I was able to confirm were not just happening to me and really were not going to get addressed. The part that started to piss me off was where you are right now with the outrage that an issue could be on the forum for 8 years without a response from ZD addressing the issue. That is followed by the frustration that your problem is real, others have it, it is impeding you moving forward and its just never going to get addressed. Keep exploring the forums. You may find solutions to your problems from other posters but generally, what you will come to understand is that topic that is not addressed in a "reasonable" amount of time is never going to be addressed. Some people hold out hope because after 5 or 6 years someone said development was looking at it but after another 5 or 6 years those users become disgruntled. Sometimes a third party will solve the problem with a paid addin but I never like to go that route because those solutions can break as the product develops.
I find your
-
Agree with all of the sentiments above. Sometimes our end-users need to update the priority of a ticket or need to update a field after the ticket has been submitted.
To make Zendesk truly "real-time" and interactive this feature is very important.
-
+1
-
@... - I would love know how you were able to pull this off as well!
-
I can't share the code publicly but we (https://outeredge.agency/) might be able to offer some custom development for you on your portal.
It involves creating an API endpoint outside of Zendesk which the portal can communicate with to carry out actions that require more than end-user permission.
-
+1 on this functionality. As another user shared, we would love the ability for end-users to escalate cases from their case center. Having some triggers to auto detect some keywords seems to be excessive, and customers should be given a chance to call in for an escalation when they think it is necessary.
Nicole Saunders Do you know if this has been taken into consideration, considering the amount of activity in the thread?
-
+1
-
+1
We also have customers that would like to update the Priority or escalate the ticket after it is submitted. Many of our users submit through email but use the portal to review updates.
-
+1 For this, my teams and client base would benefit from having this be a field level permission we can set.
-
Please developt this. We have requirements for this too.
-
+1 We have the need for end-users to be able to update their own subject lines. It causes confusion with our Agents when the end-user references a certain subject line but it is not in ZD as it doesn't update the existing ticket
-
Upvoting this as well - this is going to be really important for us as we scale
-
Critical for us! we've started looking into other alternatives! can you please provide with ETA?
-
Another vote stating how critical this functionality is.
-
+1
Has anyone found a way for when an end-user updates the subject line within an email response for it to update the ZD ticket?
-
Another +1
And another "How can what seems to be a relatively small feature take this long to be implemented"
Please sign in to leave a comment.
47 Comments