Forums/Community/Product Feedback

PlannedDoneNot planned

Modify Ticket Status/Type Fields

Michael Turner - TurnKey I.T Solutions
suggested this on February 23, 2010 08:46

I think the ability to change the Ticket Type and Ticket Status fields is a real must.

I need to be able to have custom ticket statuses, for example 'Waiting for part' or 'Engineer Called'

Again with Ticket Type, I want to be able to define ticket type for each of our service, IT Support, VoIP etc.

I think this sort of feature is very important

 

Comments

User photo
Jake Holman
Product Manager

You're able to deactivate the Status Field, and use your own Custom Field if you wish.

Changing of the Status field is not something we intend on doing any time soon though.

Jake Holman
Zendesk

February 23, 2010 10:25
User photo
Michael Turner - TurnKey I.T Solutions
turnkeyit

I think it's a feature that is required, as reports don't work as well. Especially with ticket responses and how quickly they are closed?

February 24, 2010 14:03
User photo
Jake Holman
Product Manager

You're able to adjust how quickly tickets can be closed via Automations (there's one there by default, you're able to edit it).

Jake Holman
Zendesk

February 24, 2010 14:11
User photo
Michael Turner - TurnKey I.T Solutions
turnkeyit

Hi Jake,

I know that, I'm talking about when I open a report based on resolved tickets. It will be really bad, if I've had a ticket pending for 2 weeks because we are waiting a part. It's out of our control. But if I was able to put that ticket status as 'Awaiting Part' it would make more sense.

February 24, 2010 14:16
User photo
Jake Holman
Product Manager

You could achieve that with Custom Fields, as mentioned in my initial post. Unfortunately we do not have any plans to enabled editing/adding to the current system field of 'Status'.

Jake Holman
Zendesk

February 24, 2010 14:20
User photo
Bfiggins
kingdomsofcamelot

I'd like to put my support behind this idea. Our company doesn't need custom statuses as much as we'd like the ability to rename the existing status.

'Solved' is misleading to our users. We use 'Solved' to indicate that a representative has responded to the issue. A good example is when we have a bug in the game, and we have to tell the user that there's no good solution. The ticket isn't new, open, or pending, but we haven't solved the issue, either. When a user sees that the ticket is set to 'Solved', they are likely to flip out about it.

Here's an example: WHERE ARE MY TROOPS?? HOW WAS THIS SOLVED?? WHY DID I NOT GET AN EMAIL??

Our needs would be served well by keeping the exact same functionality, but allowing us to rename 'Solved' to something like 'Responded', 'Addressed', 'Viewed,' etc.

July 23, 2010 13:11
User photo
Bfiggins
kingdomsofcamelot

Just to give a data point: I had our support staff track, for 1 week, how many times they saw users enraged by their tickets being marked 'Solved' prematurely. We counted 150 tickets that required a secondary response because of an angered user. Granted, that comes from our support procedures, and the need to bulk-close a lot of low-paying users. Still, that's 150 extra interactions that our team has to provide each week that could be avoided by a one-word change.

August 03, 2010 13:40
User photo
Conrad Selle
Project CS Beta Testers

If we use Custom Status Fields...how will that affect customer views, notifications, etc?  We can't exactly turn off the system Status field.  I just need a field that allow me to put a ticket into a "waiting on third party" status...which is still Open from a customer perspective...but not requiring action from our staff and pending resolution from the third party.

August 27, 2010 14:47
User photo
Jake Holman
Product Manager

@Bfiggins: Using the status field in a way unintended by the application, I would suggest, might be the issue. The 'Pending' status sounds more like what you want, this is the exact status to be used after an Agent has responded, or more specifically when the Agent is waiting on a response from the End-User. 

When the End-User responds, the status automatically flips back to Open, so as the Agent is now aware he needs to reply. You can build an automation to tell Zendesk to automatically Solve (or even Close) Pending tickets that have been in that state for too long, i.e. you don't expect a response from the End-User. 

@CS: How it effects notifications is completely up to you, as defined by Triggers. For example, a custom field could add in a tag - when the ticket is updated and the trigger is fired, you could notify the end-user this ticket is currently "waiting on a third party". 

As for the end-user view, I'm afraid there's no way to affect that at the moment.

August 31, 2010 11:29
User photo
Andrew J
BizStudio NZ

We are integrating our invoicing system with Zendesk... and would like to be able to set a status 'to be invoiced' or the below might be an easier option for us...

Originally it would have been fine if the tickets didnt close after 28 days, but we cant guarentee our account staff get everything tidied up in under 28 days...  so a bypass for the 28 days would be great!

 

 

 

December 09, 2010 18:06
User photo
Graham Robson
Coherence Design

Coherence Design - (http://www.coherencedesign.co.uk/zendesk-implementation/) have a range of commercial widgets that enable custom system types to be used - see attached datasheet.

The sophistication lies in the ability to harmonize the substitution of custom fields into the same position as the system fields and mapping back the custom fields to the true system fields. The benefit of which is that all the expressiveness of the rules conditions can be used, not just the tag condition. In addition, we can also support conditional display of these substitute system fields, such that depending on ticket type, an expanded or contracted priority values are displayed.

Please contact me (graham.robson@coherencedesign.co.uk) if you you'd like to explore this with us.

December 09, 2010 23:12
User photo
Jose Ortiz
tcicollege

the status field can not be deactivated also it states

This is a system field, so you can't edit the field title.

January 19, 2011 09:00
User photo
James Melbow
mobileiron

Jake,

we are unable to deactivate the Status field as the option is not available so your solution does not work for us. Is there something I am missing? Having linked a linked substatus is virtually a necessity for us.

February 09, 2011 14:43
User photo
Scott Davis
cloudbearing

This flaw is a huge burden and causes a ton of confusion.  Would love to see something resolved here. 

April 05, 2011 10:26
User photo
Terje Moglestue

Michael,

Other system often got Status and Status Reason as sub category of Status. It is often very useful. You can then quickly add workflow to the combination of Status and Status Reason.

I would like to see this implemented.

July 12, 2011 08:22
User photo
Jules
websearchdesign

We need this as well–I need to know when an engineer has started to work on a project, in other ticket software, there is “accepted”, for example–when I see that I know that it is in the queue and being worked on. Right now I have no way to know what is being worked on.

October 04, 2011 21:12
User photo
Tara Davlin Holcomb

We also desperately need this feature.  When the status shows pending, the client wants to know WHY it's pending.  We need to be able to add "Waiting for Client Response" or "In Progress" or "Waiting on 3rd Party".  Has anyone found a way to work around this?

April 19, 2012 08:09
User photo
Tom
dcip

I have to agree. The inability to either modify this field to have additional status that map a customers workflow is a huge pain. There is NO workaround since I can't even disable this field and use a custom field instead. So either allow additions to the field or allow us to disable it and add our own. 

May 23, 2012 07:41
User photo
Amanda Birch

I have to agree that we need this feature too.

May 23, 2012 07:51
User photo
Daniel Thörewik

I have agents that are requesting this feature aswell. They need it to make the work easier and also have more control over what we are wating for on a ticket.

The thing that an other customer of yours suggested in this feature request was this:
"Other system often got Status and Status Reason as sub category of Status. It is often very useful. You can then quickly add workflow to the combination of Status and Status Reason."

This feature would also be good to have.

I would like to get some answer from an Zendesk staff on this request.

 

June 07, 2012 02:02
User photo
Tal Admon
qualisystemscom

We need a more flexible Status field and allowing end-users to see that their case is processed by different groups in our organization (sales, development, support...)

 

July 19, 2012 02:04
User photo
Erin Boyle
Product Manager

Hi all,

While we are still not planning to allow custom statuses, we are ready to open up our beta for a new status called "On-hold."  On-hold means the ticket is waiting on some third party other than the requester or assignee.  If you're interested in participating in this beta, please fill out the form below.

https://zendesk.wufoo.com/forms/status-onhold/

Thanks,
Erin 

August 16, 2012 10:03
User photo
Simeon Aronson
ltc

Pending or On-Hold are not good status values in a busy support organization.  We found that these can become black holes and is not clear what party is responsible for next steps.  We found that "With Customer" or "With Support" or with Development or with Product Management is more helpful, but these are very specific to each company.  Again, I very much would like the ability to customize the default status field values.  This is a very basic requirement, and sub-reasons and triggers just don't work as well, especially for customer clarity and for reporting.

September 14, 2012 11:13
User photo
Devin GM

The “Pending” status is a catch-all that includes tickets where the support work is done but are waiting for client confirmation as well as items that are open but waiting on client input before we could continue working on them.  Adding a new status to cover the former would let us set separate automations based on the different conditions.

December 03, 2012 06:20
User photo
Andrew J
BizStudio NZ

The 'On Hold' Status has now been released.  This can be used for separate automations. 

@Simeon, allowing your agents to keep the ticket stream clear of tickets that they cant work on would normally increase productivity.  The tickets move back to open upon a customer comment.  You can automate this reopening after a set period if you like, to suit your workflow/targets.

There is a tutorial on how to add simple timing for on hold status here - https://support.zendesk.com/entries/22520522-on-hold-status-reminders.  A similar system could be used for Pending if desired.

December 03, 2012 10:55
User photo
Michael Owens

I should also voice our need for customization in the status field. This seems to be a standard in just about any other ticketing system. It seems unnecessary to loose clients due to not supporting their needs.

December 31, 2012 20:11
User photo
Scott Roberts
khamma

We really need this as well.  Ditto to all the above.

March 01, 2013 18:35
User photo
Andrew J
BizStudio NZ

Hello Michael and Scott,  where would these modifed values show, and what would the purpose be?

Could their display be modified using a global js widget perhaps?  Or maybe we could hide the status display and show a custom field with more options, but automatically linking to the built in status options?

The standard status field is built into the workflow, it would be good to discuss your use case and see if there is a way to make this work.

March 01, 2013 19:30
User photo
Neil Mauskapf
socialwellth

I also would like to jump in and say that the ability to change the name of the priority field would be a very useful activity. 

OR

If there were more options on the ability to define conditions on Custom Fields.  -  custom field are not as flexible in triggers as standard required fields. Priority  has more flexibility in that we can choose operators like "CHANGED FROM" or "CHANGED TO" when creating a trigger. Where as a custom field only has operators Is or Is Not.

 

We are trying to use multiple triggers/automations to create a scenario where a ticket is created with a priorirty of Urgent (known as Severity 1 in our organization) is not updated in X minutes - an email is sent. Part of the confusion has to do with the wording - Severity 1 vs Urgent.  This would require a large change in our processes and training to implement. Whereas if we could just change the selection names - we could use the priority field as is.

 

We are mired in trying to use custom fields and addition/removal of tags via automation to simulate what could be done with new field selection names in the existing program.

 

Count me as another customer who wants this badly.

April 02, 2013 07:36
User photo
Eoin Ryan

I'm new to Zendesk (first day!) and I had intended to modify the ticket types for our variety of call types (e.g Repair/Sales Enquiry/Contact Us/Returns)..... but now I see that is not possible.

Generally, do people use tags to work around this, or simply create a custom field with drop downs for ticket types?  Would anyone have any comments on the pros and cons of using either?  (e.g. is one type more amenable to reports/automations?)

thx

August 16, 2013 06:55
User photo
Andrew J
BizStudio NZ

Hello Eion,

The TIcket Type feature is fixed, but can be disabled.  Normally we would use a custom drop down for this.  The custom dropdown can have multiple levels using :: as a separator.

With each option, you set a tag which can then be used to drive views, triggers, automations, and more.  Make your tag more complex than a single word  - reason being, further down the track you may want to use auto-tagging and you could find a conflict.  Just some advice.

August 16, 2013 12:30
User photo
Eoin Ryan

Thanks Andrew, that's very helpful.  I'll take that approach.  One embarassingly simple thing that I don't see in the settings yet is where to display custom fields on a ticket.  Is there a 'ticket layout' area?

For example, I just created a new Call Type custom field and made the standard Ticket Type field inactive.  However, when I create a new ticket, the standard Ticket Type field is still showing and there is no sign of my new custom field (nor any of the other custom fields I've made for tickets).  As I said, I'm new to Zendesk, but when creating custom fields previously in Salesforce, there was a 'page layout' area where you would arrange your standard and custom fields.

August 16, 2013 12:49
User photo
Andrew J
BizStudio NZ

Hello Eoin,

I can't add an image here, please see the page you need here http://bizstudio.co.nz/business-support-and-helpdesk/images-support-and-helpdesk/re-order-ticket-fields-zendesk-support-platform/

Once you hit 'Reorder' just drag and drop.

To edit the field's properties and visibilities open each field.

August 16, 2013 13:35
User photo
Eoin Ryan

You're a legend!   Thanks.  Will get on to that straight away.

August 16, 2013 13:39
User photo
Shelley Cavanaugh

WE NEED THIS!!!!  I really wish we had the ability to change the Status field options - or at the very least, add a status of 'Answered'.  This is paramount to client happiness.  Why isn't something as high in demand as this being implemented?

August 22, 2013 08:42
User photo
Andrew J
BizStudio NZ

Hello Shelley,

The default 'types' are a core part of the functionlity.  The best way to address this is to 'hide' the status field from the customer, and  make a new custom field with the statuses you want.  Presumably you would use macros to set these values to suit.

Answered sounds like a 'forum' question rather than a support request, however I can understand what you are thinking.  What would make all the difference would be if we could manipulate custom field values with triggers and automations.

August 22, 2013 12:30
User photo
Maxime
Product Manager

@Shelley are you asking for renaming the statuses for your agents? So instead of submitting a ticket as pending/solved they would submit it as "answered" ?

August 22, 2013 12:36
User photo
Shelley Cavanaugh

@Maxime - Yes, sir.  Currently, the statuses are New, Open, Pending, Solved, Closed - it would be great if our company could change Solved to Answered, and another company could change Pending to 'Waiting for Part' or whatever the case may be.  The term 'Solved' throws people off [the clients of the company I work for] in the context that it is being used [depends on a lot of factors - will provide a good example that makes sense shortly].  And as you know, end-users can see these Status reasons as well.  We would love, love, LOVE for Solved to be changed to 'Answered' instead [or at least create a sixth status reason called 'Answered' that Zendesk agents can use.  I just wish that Zendesk could take into account how many people have voted on this and really, really consider this.  @Maxime - can you tell me how much votes it would take to implement this?  I know I can fill that quota.  

August 22, 2013 14:41
User photo
Shelley Cavanaugh

@Maxime - maybe you can share why Zendesk Development is quick to say 'no' to custom statuses.  Is this something that can be super-laborious to implement?

August 22, 2013 14:48
User photo
Maxime
Product Manager

I'm pretty sure we won't implement it Shelley, but you'll be happy to know I think it's very doable by building a custom Zendesk App.

We've recently added APIs to allow you to do that, so if you have an engineer wanting to spend a couple hours building this super useful App for you just point him to http://developer.zendesk.com/documentation/apps/ and he can get that under way pretty quickly

Feel free to send a support ticket if you want to know more!

Thanks

August 22, 2013 14:48
User photo
Shelley Cavanaugh

Thanks, Maxime.

August 22, 2013 14:50
User photo
Andrew J
BizStudio NZ

I do agree with the idea that it would be great to be able to change these... I would also suggest that some companies would find that no one term may suit for some 'renamed' items (solved and answered would both be nice - but confusing for the agent)

How we address this currently is to focus on the emails and messages to the user, and make this very clear as to what the actual situation is.  In our case, we close some tickets as 'unresolved' and they get an email telling them it is 'solved'! 

In real terms, this doesn't cause any problem for us.  The message clearly says, 'Unfortunately we have been unable to resolve this problem...etc.' and provides clear direction for their next step.

August 22, 2013 14:53
User photo
Shelley Cavanaugh

Andrew - Loved your follow up. There are workarounds for everything, so we'll continue to do what we've been doing.  A little sad that this will not likely ever be implemented though.  

@Maxime...I know how busy you must be as the Zendesk Product Manager, however, if [during the next Zendesk staff meeting] you happen to remember this feature request, please, please, please bring this up.  This would make a nearly perfect product even better.

Have a blessed day, everyone.

August 22, 2013 15:02
User photo
Andrew J
BizStudio NZ

I think the real problem is that these statuses are intertwined throughout the entire ticket flow.  I could imagine that a display re-name of the current statuses might be the most we could expect. 

August 22, 2013 15:47
User photo
Hollie Charlotte Brown

Just want to add myself tothe list of the people that would love to have this feature. Sometimes some of the tickets we have raised are not 'problems' and therefore cannot be 'fixed.  and we often have situations in which a 'propose no fix' status would be really useful. Currently, we're leaving all of those tickets set to on-hold, which we would rather be using for when we have ordered parts, are waiting on a third party, etc. 

 

There is clearly a desire for custom ticket statuses, and if we could have this feature, it would be greatly appreciated.

 

September 26, 2013 01:52
User photo
Jimmy Maher

I'm astounded that Zendesk is refusing to budge on this very basic requirement for a support organization. I need multiple pending statuses that are explicitly  understood by customers, agents and other stakeholders who review service requests. Eg.

Pending - Customer

Pending - Engineering

Pending - Third Party

Pending - Support

Jimmy

 

September 26, 2013 11:49
User photo
Evan Colwell

My workaround was to create a "Secondary Status" field just under the system status field.
End users are able to see this and there is no confusion.

 

Evan

October 02, 2013 21:32
User photo
Evan Colwell

But yeah, Zendesk should accommodate the need for custom statuses

+1 custom statuses

October 02, 2013 21:44
User photo
Andrew J
BizStudio NZ

Modification of existing statuses yes (names only), but fiddling with the core functionality, no thanks.

The second status field is the solution for those who want this, but changing the actual status field would be interfering with core workflow and affect triggers, automations and macros etc.

You can HIDE the status from customers, and use your own custom field.  

I think altering this would be a little like asking MS to add a new default email folder 'Items I'd like to send but can't'.  Its a good idea for some, but a custom folder would be more obvious.

October 03, 2013 00:36
User photo
Jake Holman
Product Manager

Hello!

While there's still no solid plan to start development on this, I do want to explore the idea further with all of you. Having followed this thread (as well as others) and speaking to customers at many of our events, the Status/Priority fields come up a fair amount.

I'm going to keep referring to "labels", which simply mean the values within the drop down options.

So far, I understand there's two main needs on this:

  • Changing existing labels
    This one is the simplest. Wanting to simply change the existing labels we have for system fields, i.e. changing "Problem" to "Bug Report"

  • Addition of further labels, or removing existing ones them
    This one is the more complex use case. Wanting to add more to the Type field, or the Priority field - or indeed removing/hiding existing labels

I need the communities help to further understand both of these cases. Here's a few questions I would really love to hear some feedback on:

  1. Why do you want to change the label of existing fields? What difference would this make to the lives of customers, agents and you?
  2. How would you expect Zendesk to treat customizable, new labels in fields such as Type? The UI (and indeed meaning) of a ticket changes depending on the Type of ticket, how would you expect Zendesk to treat your custom labels? Or even existing labels you'd changed the name of?
  3. Is there anything else you'd like to add to help us understand the need more?

Thank you in advance if you're considering answering these questions. 

October 03, 2013 10:59
User photo
David
bombbomb

Hey Jake, I can give a little feedback on questions 1 and 2.

 

  1. Being able to change the label of an existing field would do two things: First, it would more accurately communicate the status based on organizations accomplishing very different things with their support tickets (which is helpful internally and externally), second, it would allow for easier and more accurate internal communication as tickets move between departments and statuses. Every "at a glance" advantage we can get is incredibly helpful. For my organization, we would see HUGE benefits from an "in-progress" status that could be used to indicate problems or incidents that are in active development and expecting closure soon.
  2. I don't really understand this question. If the type of ticket is a Problem or an Incident, and we added a custom status label called "in-progress" I wouldn't see that there would be any need to change the interaction between those two fields. "in-progress" would be a status used for tickets that have been removed from communication between us and clients for an indeterminate period of time and moved into internal communication until the ticket is able to be completed when the problem or feature request is resolved.

This request seems to me to primarily be one intended to facilitate stronger internal communication among teams working through zendesk. For us, it would add a whole new level of productivity as we deal with hundreds of requests each day, many of which need to be moved to a problem or incident (to track feature requests or software bugs) for a period of internal review before we decide if/when we will act on them.

December 03, 2013 10:49
User photo
Scott
logianalytics

We have our ZenDesk linked to JIRA and in JIRA, the issue types are things like bugs, enhancements and feedback.  I'd love for those labels to be the same in ZenDesk. Your labels of question, incident and problem mean nothing to us, so we just don't use that field at all, which is a shame.  The best I could do was map to a custom field, but custom fields are obviously not integrated as tightly with your workflows, reporting etc.  Hope that helps.

December 12, 2013 13:13
User photo
William Tinker
procentia

I fully agree that this is necessary.  It is very important that we/our customers are able to differentiate between tickets that are 'pending' awaiting a response from the client, and 'pending' awaiting an update from ourselves.

Presently, I am having to update the ticket with a clarification on why I am using 'pending' as a status each time prior to setting, which is cumbersome and also unhelpful where reporting/stats are concerned.

February 03, 2014 06:37
User photo
David
bombbomb

It's also very helpful to have a pending ticket close automatically when we're waiting on a customer response, but not so helpful when a ticket is pending, waiting for an internal response.

 

February 03, 2014 10:36
User photo
Craig Eastman
kixeye

@Jake: re: "What difference would this make to the lives of customers, agents and you?"

Our use case... on the consumer facing "My Activities" templates.... when a ticket listing reads "Solved", but hasn't automated to "Closed", we feel the user will be more tempted to continue unnecessary replies to ticket involving issues that simply don't have hard resolutions - unfortunately we have these. Altering the 'label' of the status would allow us to try to temper aggravated  customers.

February 06, 2014 14:52
User photo
Jason Robinson
filamentgames1

Craig has the right of it: it's about being able to manage customer expectations.  Not every problem can be 'solved' and it is downright infuriating as a customer to be told 'we can't do that' and then receive an email indicating that your problem is 'solved'. 

Let's reimagine this thread as a Zendesk Trouble Ticket. 

Mr Turner opens a ticket and he thinks its a 'problem'  He gets an email telling him that his Problem ticket is Open.   A couple hours later Mr Holman responds and sets the ticket to Solved.   Mr Turner now gets an email that his problem is Solved in the same email where Mr Holman says that  Zendesk has no intention of solving the problem.  

Just stopping there, the problem with the status labels should be evident and the use case for changing those labels should be pretty obvious.  

Additionally, I'd love to be able to sync up my Zendesk and Jira implementations. 

March 11, 2014 08:32
User photo
Craig Eastman
kixeye

For what its worth, we found a way to display a different status 'Label' - showing customer "Answered", as opposed to solved... just a bit more gentle.

March 11, 2014 09:09
User photo
Matthew Clyker
petroweb
  1. Why do you want to change the label of existing fields? What difference would this make to the lives of customers, agents and you? - Well I don't want to change the *existing* field. Leave it there if you have to. For instance we simply ignore "task".  We don't have tasks in our workflows.  I want to add a new Type label..."Enhancement". It makes a big difference for us and customers as sometimes what a user reports as a *defect* really is an *enhancement*.  (ie This button doesn't work. I wanted it to do this... when it only does this. Or much like this conversation about adding/editing labels... This is an enhancement request we are asking you to make. )  Our support model covers defects through maintenance payments but not enhancements.  Enhancement requests are an opportunity for us to sell services and fund or partially fund that work by that client.  It also allows us to see how many requests for this are coming in.  Is it a one off request or is it something that the community at large is asking for?
  2. How would you expect Zendesk to treat customizable, new labels in fields such as Type? The UI (and indeed meaning) of a ticket changes depending on the Type of ticket, how would you expect Zendesk to treat your custom labels? Or even existing labels you'd changed the name of? - Well again. I like the custom functionality Zendesk has built in... For instance Incidents and Problem linking. So go ahead and leave those as not changeable.  If a customer wanted to relabel them to match another system or process then perhaps treat it like a display name.  So on the front end it reads whatever they input it as but the back end treats it just the same as always.   On custom types added in like "Enhancement"... I'm not sure of the system ramifications on your side but if they were treated as a searchable option (maybe like you treat "Question") that would work just fine.  The existing labels we changed the name of wouldn't be affected if it were simply a display name... Editing or Deleting a custom type would be problematic.  And perhaps you just treat it as an overwrite. If you are going to make the change here are the consequences.  Smarter guys that me could probably create a script that would move them from one type to another before deleting the old one...but I'm over my head on that one. :)
  3. Is there anything else you'd like to add to help us understand the need more? - Nope. Exhausted myself in the above. Thanks for the consideration.

Thank you in advance if you're considering answering these questions. 

March 11, 2014 14:24