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?)
-
We want to provide our user with a flag which they can choose to escalate the case. This can happen after the case has been created and for some reason user wants to escalate the case. For this user(customer or staff) edits the case and checks the escalated flag and we can create triggers so when this happens we notify our support org. once things are brought to normal, customer and our support team should be able to de-escalate the case by unchecking the flag.
also key to feature would be to able to report on it and have a history as to find how many cases were ever escalated.
-
Hi Donna,
Ditto here, I looked again and again and - unfortunately - that feature doesn't exist with Zendesk Plus license.
-
I've noticed this same request raised in multiple threads dating back to 2013. It would seem to me that allowing users to edit/update ticket fields should be part of the standard architecture.
We have a ticket flow that requires 2 user engagements, and it's disappointing learn that we'll have to setup multiple forms and track and consolidate at least 2 tickets for each user request;
Has anyone learned of an alternative?
-
Yes, I agree. I am particularly interested in the Subject field. We may have a customer who wants to edit the subject but they have no way of doing this themselves.
-
We have the same need. There are additional pieces of discrete information we need our End Users to provided incrementally as we work through resolving a ticket. As others mention above, we also have many cases where our End Users would like to change or append fields from the initial submission (and their doing so would help drive the correct workflows and notifications on our end). Not being able to update those discrete fields after submission prevents us from measuring some key metrics; results in tickets not being able to be routed to the correct "workflow", notifications, and triggers; as well as adds overhead to our Agents when they need to update the discrete fields based on information provided by our End Users through comments.
-
We have the same request - I actually was surprise today when I tested this and realized that end user could not edit the Subject field - which they provided in the first place. They should be able to edit all fields (except for previously submitted comments) that they were asked to complete.
-
+1 Why can't end-users update ticket fields if a field needs to be changed? Obviously this should be configurable (editable/not editable) when the ticket field is created.
-
Has anyone figured out a workaround? I've searched the internet, ZenDesk App Marketplace, Zapier, and the Community here, so far there does not seem to be a way to do this.
-
Has anyone learned of an alternative?
-
Yes, you can create a trigger to allow updates. It's not an ideal workaround, but it does work...
The way we set things up was anytime a particular string of text was entered in a comment, to increase (or decrease) the priority. The text string we chose was a keyword preceded with a number sign/hash (#) - ex: #urgentpriority, #lowpriority
Where this workaround gets clunky is that you need a trigger for every option in a particular field....
-
Has this been addressed by Zendesk ? Hard to believe this is not an option!
-
How can we raise visibility of this request? Are any moderators watching this thread who can help us get this prioritized? We have a need for this, which has been requested by a strategic customer of ours. Thanks.
-
Hey David -
There are a couple of ways to increase visibility of Product Feedback:
1) Outline the problem you're trying to solve in specific detail. This gives our product teams the most insight into what's going on and how they might build something to solve the problem.
2) Share impact information, i.e. how frequently the problem happens, how many incidents of the problem there are, how much time/money it costs you.
3) Up vote the original post.
For more information, you can read through how to share your product feedback.
These practices help our PMs understand the problem behind the request, the size and scope of it, and how many of our customers it potentially impacts.
There are many factors taken into account when planning what developments to devote our resources to. Some of those include feasibility, number of users impacted, and how that development would impact other things already in process, to name a few. We cannot guarantee any specific idea shared in the Product Feedback Community will be built, and we cannot share specific timelines. Threads with lots of detailed comments and a high number of votes do, however, have the greatest visibility.
We do very much value our customers' feedback, and are working to make the Product Feedback Community a better space of collaboration and communication.
Thanks for participating! -
Hi Nicole,
Thanks for the response. I assume you folks have a system for tracking Enhancement Requests. Can you tel me if this is already in that system? If not, can you add it please, so that it is visible at some level?
Regarding impact, we have customers who would like to add additional team members to CC from within the Support Portal, which is not allowed after the ticket is submitted. They also would like to modify the Priority, which would then allow us to set up an escalation trigger. Lastly, they would like to modify certain other fields for their own tracking and reporting purposes, which again is not possible.
Impact: Workflow improvements will help us scale our support services, and without knowledge that some of our concerns will be addressed, we will likely need to investigate alternatives to see if we can better meet our customers' needs long term.
Thanks for your attention.
Dave
-
Hey, any decision if it will be implemented or ETA?
-
Any word on this feature request? Is there an alternate workflow that anyone can suggest?
-
This is so unfortunate. One of the most critical functions to any support these days is an online customer knowledgeable/portal. It is also important that the client can take the control into their hands and not have to wait on a support rep to make changes to their ticket. Due to this limitation we must continue in this hybrid world of manually updating tickets for clients between email and an online support system. Here are just 2 business cases for the development team at Zendesk.
Ticket Creation and Priority Setting
We have been providing our clients an email address to our support for years to open a support case. We ask our client several questions as part of the ticket creation process that helps us determine priority, as well as potential support paths. This typically requires a lot of back and forth between the client and the support rep via email to figure out the urgency of their request. You can enable these questions/fields on the ticket creation page in the customer portal, which dramatically speeds up this process. Furthermore the portal will make article suggestions to the client which could solve their questions eliminating any support need at all. The holy grail.
However if a client still emails a support email address without this information, we cannot have it create the case and simply point them to a link to update these critical fields in the portal after ticket creation. We have to fall back on old ways of taking the case in, contacting them, and having our support reps fill in these fields manually to prioritize their ticket, as the fields are not editable in the portal after ticket creation. If we change our support email to a bounce back email saying please go to the portal and add your request there, this will make them unhappy, as they need to recreate the wheel. If they recreate the wheel and make a mistake in the process of choosing the wrong value and they cannot correct this, you will have mad customers on your hands (this has happened to us).
Ticket Escalation
In our older support system, our clients could edit the priority field in the portal after ticket creation to escalate their ticket if the issue had become more critical. They cannot do that now, as they cannot edit their field. They need to contact us, we need to do it manually, etc.
PLEASE FIX THIS!!!!
-
Thanks for the detailed feedback, David.
We're continuing to collect use-cases and votes, as the Support product team is looking into improvements to the ticketing workflow.
-
+1 on this, simply I would like the option on each field whether the customer can edit this field once the ticket has been logged, this will allow the customer to edit the subject, or raise/lower the priority.
-
Pretty basic feature. A Customer should be able to self serve and update the priority of a ticket simply by toggling the field in the Zendesk Portal as opposed to add a comment to request someone to do so...
-
We would also like the ability to be able to allow our End users to Escalate and change the priority of Tickets themselves.
This seems like a very basic feature that should be table stakes for a CRM.
-
We've had to implement this with an API hack, would be great if this could be part of the core product.
-
@...
If you don't mind me asking, how did you use the the API to accomplish this?
-
We don't directly connect to the ZD API, our custom JavaScript makes a request to an externally managed endpoint which in turn updates the ticket in ZD. It's a hack, but it works.
-
@...
Now I am even more interested.
Are you displaying something on the help center that allows the user to change the information?
Or is this on a custom-built form?
I am interested because I am trying to get away from email submissions but there will always be those who want to do it that way. So, I wondered if there was a way to update a ticket from Zendesk HC. Of course there is not. Then I took a few hours and created a proof of concept of sending any email ticket request a response that auto-generates essentially a form that they can fill out and update the ticket. I plan on telling requesters that email their ticket in that we will not look at it until all of the information is added.
The reason I did it that way was that there is no way for an end-user to update a ticket from HC.
I ended up creating a simple endpoint that I maintain to do this. In the same way, the request gets sent to my endpoint. But, I was not sure how I would go about it on the actual HC. Like adding options or something to the form they see in HC.
-
Using some custom Javascript in a custom HC theme we added this which calls our remote API:
-
@...
That is exactly what I was looking for.
I think that would be a great tip to add to the community if your company would allow that. I really think a lot of Admins would be interested if you were to do so.
If you don't want to go through the trouble but don't mind sharing the code you used, I would not mind writing it up for you.
-
@... Can you share the Javascript you are using?
-
We have custom fields on our ticket that the user can select and edit when submitting a ticket through the portal but after that, they are unable to change these fields. The portal from the end user's standpoint is a useless interface. Why can't they edit fields that I have setup as editable by the end user?
I don't expect to see ZD do anything about this. They really don't listen or address these valid concerns that their loyal base submit. Comments go on for 10 years and nothing. I'm looking at the possibility of switching to something else with a more responsive development team. There are just so many basic functions you assume would be in this product only to find that not only are they not there but ZD has known for years that people want/need it and do nothing.
It has been 3 years. How long does it take development to give a thumbs up or down on this so we can just concede defeat and move on to another product?
-
I would love to give end users the capability to update certain fields in the activities area of the portal. As others have indicated above, we have end users that will log a request and then realize they have entered the wrong priority type and right now there is not a way for them to update it unless they create another ticket to bring it to our attention, specifically if let's say they needed immediate assistance and selected the wrong priority. Would love to be able to pick/choose which fields they can edit, much like the end user editable flag on the ticket fields perhaps another flag that would say editable in the portal itself.
Vous devez vous connecter pour laisser un commentaire.
47 Commentaires