Customize Status Field ValuesCompletada
It would be great to be able to customize the status field drop down and specify which status values are considered closed (and open for that matter) Much like Salesforce's Status picklist where you can check which values are default and closed
+1 on that feature.
"Waiting for Client" is needed, not just "Pending" or "On Hold". Some use statuses differently. At least we should have the option to decide what works best for us.
Custom ticket statuses are a must...
Zendesk is ITIL based you say, well, then get to work and fix the statuses, because we need them.
- in progress
- on hold
+1 for custom statuses!
It's a great product, and yet users in this thread have been asking for custom ticket statuses since December 21, 2010. Six years later, we are at the same spot on the road.
I just joined. Also have need of custom ticket statuses. It would be much easier for my team and clients to know exactly where we are with a task if, for example, something were labeled "in progress", or "clarify".
So. Pretty please?
+1 for this feature. We would really like it. We have customers that log enhancement requests and this will allow us to set an "logged as enhancement" status for better tracking purposes.
This is very much a required Feature for Kinaxis. We require the ability to quantify the number of cases in a certain status. There is very much a need to have the status say one thing to the agent and another for the customer.
ie Agent- waiting on server Customer - In progress
There are certain steps we want to track to see why a case took a long time to close. We dont want to expose those reasons to the customer.
This would be a fantastic option to have.. As our systems and project coordinator, I often have to reach out to different departments and offices... and having a "waiting on resolution " status would be ideal.. It would help keep track of where I am in the progress at a glance instead of going into each ticket... and this would help my team know where we stand quickly when they are trying to follow up for a customer.
Customising your statuses is important when you want to seperate your tickets in a more precise way. For example, I have two statuses for our Dev process. One is to reflect the fact that an issue is in an active Sprint, another one to reflect that, while identified as a legit issue/improvement, is unlikely to go into development anytime soon. This allows for easy access to said groups of issues. And I can fit them all on the one page.
There is also a efficiency issue with not being able to customise statuses. You can create a custom field to allow a user to move between a broader view queuing system. But this requires the agent to now take two actions when submitting a response to a ticket.
1. Change the queue by moving cursor and changing the custom field on the left side of the screen.
2. Now submit the ticket with the button at the bottom right, changing the status field as required.
As opposed to....
1. Submit ticket, changing the status to park between different views.
Doesn't seem like much of an extra time burden when you think about it once. But adds up to lot when you start talking about hundreds and thousands of responses. Its like the customisation makes changing the status redundant, but the action still has to be performed.
Then there is the consideration of the simple fact of human nature - make a process harder and it is less likely to be followed.
These reasons are why Zendesk should reconsider its policy of forcing the status field to be non-customisable.
This is a required capability for ConcretePlatform. We use 'Pending' to let customers know we are awaiting information from them and this emails them to remind them. We use 'Open' to indicate that there is an outstanding action on us. We now need a further status to indicate we have shared the ticket with our engineering team on Jira and that it is with them. We run reports on tickets in the Open status and Pending keeps sending emails to the customers even though they don't need to do anything while we await a resolution.
Please I'd need to be able to customize the status values. For example, I'd need to break "Pending" into "Pending Customer" vs. "Pending Internal". This is so we'd know for our backlog tickets, how many of them are held up by waiting on customers vs. internal organization.
I am part of the product team at Zendesk and our team would like to have a discussion and understand how your agent workflow is impacted by the underlying problem.
Kindly follow this link to book a time that works best for you: https://calendly.com/zendesk-ayush/30min.
Agreed - I'm working with the trial trying to understand how to implement but the lack of customizing status's is making this difficult to match our processes.
Especially considering we are going to be integrating ZD with Jira, we need to have the ability to track tickets at different durations when it comes to passing back to development vs waiting on customer vs waiting on technical analysts.
Adding my voice to this as a desired feature.
+1 for this feature.
We are searching for a other product. This because we still cannot add a prefix or a custom status? Why is Zendesk not listing to its customers and fix this? Really disappointing.
+1 This feature.
+1 for this feature. This is a very important and needed feature from our end as well.
Very important feature. As we pass between teams I want to track the time in different teams and when we hand off to engineering who use JIRA
So it is 2018, this feature has been requested for many years and by many people and this still is not a feature. Zen Team I would recommend paying attention to the client base. There are far too many alternatives out there. I used Zen back in the day when it was an opensource application, and at that time it was leading the way in ticket tracking and analytics. But today we cannot even get statuses to be customizable to meet our needs....heck even being able to change the actual name from "open" to "open with a side of fries" would be a move in the right direction.
Hi Zendesk Team: We also would like a custom status option. Our reason is because we share some tickets with a 3rd party vendor who only bills once monthly. They don't close tickets until they've been billed, so we will have hundreds of tickets hanging out as "Pending" for up to 30 days. Tracking workflow is impossible for this department. We cannot use the "On Hold" status for this issue because we currently reserve that status for when we are waiting for other 3rd party vendors to fix issues on their end so we can then support our teams.
It's 2018. I see that this thread was begun in 2010. It's time, please! (please!)
I'd like too custom Statuses. We have to use as workaround triggers and tags. Rather ugly for agents and makes reporting not so great:
- New // 1st time end-user contact Support on specific ticket
- Cancelled // End-user has a change of mind and cancels the ticket by himself on front-end
- Resolved //Agent replies to ticket, sets status as solved, no more actions needed.
- Reopened //End-user not satisfied with Support's answer (Ticket set as Resolved), so, reopens ticket
- Need More Info // Support side, we need more data from end-user. In ZD, you call this "Pending" so far.
- On-Hold //Support side, Agent puts ticket on hold until we have more info to provide to end-user.
- Closed // Either Support (manually, we use a tag+trigger, rather "ugly" workaround) or end-user on front end close the ticket.
ZD needs quite a bit more flexibility in this regard. For small companies, the current ZD options may be ok. For big companies, current statuses offered are not enough. Looking on the comments from other folks in this post, we're all in pain over this sad restriction.
Please make this a thing.
+1 on this feature... Pretty shocking this isn't a feature... seems like such basic functionality to allow a customer to have the flexibility to have.
Jr. level programing required it here seems.
Hey James -
It's not necessarily a matter of how easy something is. Also, things that look easy from the outside aren't always. While the level of difficulty is one factor in whether or not something gets developed, there are many other factors at play in determining what we do and do not build.
In this case, building customized statuses would, indeed, not be that difficult. However, there are many workflows and functions that would be impacted, and accounting for all of those and the many possibilities that would be created by allowing every user to customize those statuses is much more difficult.
Then make it an optional feature. PLEASE add it in.
Hey Darius -
Making it optional wouldn't solve the problem of a custom status breaking the workflow.
But, we are interested to hear detailed use cases that help Product Managers understand the problem behind the request. Can you tell us more about your workflow and why the current statuses don't work for you?
Read back through this thread and you will find at least a half a dozen business cases for more flexibility in this function. And overwhelmingly the response is not that the current statuses do not work...it is 1) there is not enough of them 2) we want to name them differently for different functions.
Product management could move the current statuses to a "type" and develop some configurable functionality around them as well. So that when we create a status we also assign a type to it. That way the internal workflow processes you have could be applied to types of statuses instead of the actual status. That would allow users to make the status field whatever they wanted as far as what it says. And then apply an internal workflow from Zendesk to it.
And provides some configurable features to those workflows. Example: An On Hold status type may have ability to configure the number of days before closing or something like that. Yes that would be a great deal of re-arranging things inside Zendesk...but again this is something that has been requested here since 2010 and something that many of the competitors have the ability to do and still provide similar functionality that Zendesk has.
Thank you so much, Gerald. :)
La publicación no admite más comentarios.