Customize Status Field Values

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? 

Nicole,

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

Hi Nicole,

Please feel free to read my previous post/comment. Should you require a more "hands on" overview of a case scenario, we have the "hijack account" function available for ZD Support Staff. 

Let me know if you want to take a look, so, you or somebody from your team can take a look into that and see how we were forced to use a workaround with triggers to track additional statuses: "Reopened" and "Info given", with tags. It's a rather dissatisfactory solution, but that's what we came up to, so we can get the job done, for tracking and reporting.

Flexibility on statuses + allow status renaming would be greatly appreciated.

Regards, 

Our use case is not even that we need custom statuses, only that we need a status that can display to the customer when we are working on something. Right now from the end-user view "On Hold" just displays as "Open" so to the end user there is no differentiation between something that is Open because no one has looked at it yet, or Open because we're working to fix it. There should be at last one status that can convey to the end user that their ticket is in our queues. I custom status would fulfill this, or the addition of a single new status type, or just making the On Hold status actually display to the end user (perhaps optionally so it doesn't break workflows for other Zendesk implementations that don't want it to be used this way).

It's extremely important to us that we're able to convey to our customers that their issues are being addressed. Right now the only way to do this is through adding updates to the ticket which is more laborious for us to do, and for them to check. 

Kendall

We too would appreciate having custom statuses. At least, and very least, please make it so that customers do not see OPEN when we have a ticket ON HOLD. It is so misleading to our customers since it shows as OPEN and they probably assume we are just ignoring it. If nothing else, please fix the ON HOLD status. But really, after 8 years it would be great if you could allow us to determine the statuses and add/remove as needed. We all operate our business differently so a small handful of generic statuses just isn't going to cut it for all of your users.   

Hi Nicole,

Here is another situation that my team is running across.

We currently have the "Pending" status configured to automatically close in 7 days.  We have found this works for those situations in which we simply do not get a response back from a client.  

However, we do have several enterprise customers that quite typically will have cases open for a month because they want us to review them at a monthly meeting.  And then from that meeting we get to close them.  So we could (had have) had tickets sit in the "Open" bin for 30+ days as we wait for approval to close the ticket.  

We should be able to move them to "Pending" because we really are waiting on them to say "close it", but because we cannot create "Pending customer approval" or something similar, we have to let these tickets fester in the open buck.  I would love to even actually be able to have a "Closed" status that still shows up as open on the customer end.  Something I could say is closed for reporting purposes, but yet as far as the client is concerned it still displays as open.

That is why Zendesk would be so much more powerful if the development team would strip the workflow from the actual status field and move that to a status type.  Then people could configure the fields all day long and just apply a status type to the status they create.  The ability to customize things from a client perspective would increase ten fold if not more.

Just my two bits for the ZenDevTeam

Thanks for the details, Gerald. 

We were just discussing this in our organization yesterday. Being able to close a ticket that was "Critical" vs. "Informational" is something we would really want to track. Helps us answer the question, "What kind of ticket was this?" and further, "How quickly did we respond to/resolve those types of tickets?"

Hey Shanta - 

Is there a reason that tags won't work for you for this purpose? 

I wanted to be able to track these as how we closed them. We're on a team plan and can't produce customize results. Can I do this with tags and get those kinds of reports on the plan we have?

+1 on this feature. This is our number 1 pain point with the product that clutters and complicates our workflow.

I'll add like a previous user that we don't even need a custom one - just one more status! Call the status "Pickles" and add it to Zendesk and we'll be happy!

I am evaluating a number of Support solutions and most all of them allow an administrator to change the allowable values in a status field.  This particular need has been banging around in this forum since 2010 and it's still not been resolved?  The ability to customize a status field isn't some esoteric need that isn't worth your time, it's a very basic and entirely foreseeable requirement.  The same issue exists with the Type field.

I have been warned that while the ZenDesk may be pretty good, responsiveness of Zendesk to it's customer base is pretty poor.

Hi Len - 

It's true that we've had some communication challenges in the product feedback topic in the community in the past. We're doing a number of things to improve this, in our UI, processes, and particularly in the way that we take in, process, and act on customer feedback. That being said, not everything that gets requested is guaranteed to get built. Customer feedback is one data point, but it's not the only one we use to determine what is the highest priority and best use of our developer resources. 

As for this issue specifically, the reason this hasn't been changed is that it is a very heavy technical lift based on the way our platform currently operates. All of the logic of the system is based on those statuses, so changing them - not to mention allowing every user to have a different set of them - would require rewriting a significant portion of the platform and operating logic from the ground up. 

It's not that we aren't aware of the request, it's simply that changing this would require halting a lot of other things to address this one issue. We've opted instead to find other workflow solutions for the need and to continue to develop other aspects of the product. 

All of that being said, the product team is looking to do some significant work on Support in the next year, and we have flagged the comments in this thread for them to review when they're deciding which problems to solve and what those solutions might look like. 

Thanks as always for your participation and feedback. 

Hi Nicole,

Could the option to just create new status be added whilst it doesn't let us current edit the system default ones?

I've mentioned before in this thread, but now that Zendesk may be working toward this goal...  The reason we need a custom status is because we share one department's ticket with a 3rd party vendor who only bills once per month. So they leave the tickets they've worked on as Pending for up to 30 days.  This skews our metrics in this department to the point where we cannot even use metrics.    Neither we nor our 3rd party vendor can use On Hold or any other status is because in both of our cases those statuses have been assigned for other use within our organizations. Tags will not work for us.   Thanks for listening.

+1 Custom statuses seem like a pretty basic request to me. Loved the ability to customize statuses in HappyFox