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
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.
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?
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).
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.
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'.
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.
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.
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.
@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.
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!
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 (firstname.lastname@example.org) if you you'd like to explore this with us.
the status field can not be deactivated also it states
This is a system field, so you can't edit the field title.
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.
This flaw is a huge burden and causes a ton of confusion. Would love to see something resolved here.
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.
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.
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?
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.
I have to agree that we need this feature too.
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.
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...)
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.
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.
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.
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.
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.
We really need this as well. Ditto to all the above.
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.
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.
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.
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?)
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.
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.
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.
You're a legend! Thanks. Will get on to that straight away.
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?
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.
@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" ?
@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.
@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?
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!
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.
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.
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.
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.
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
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.
But yeah, Zendesk should accommodate the need for custom statuses
+1 custom statuses
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.
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:
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:
Thank you in advance if you're considering answering these questions.
Hey Jake, I can give a little feedback on questions 1 and 2.
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.
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.
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.
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.
@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.
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.
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.
Support Software by Zendesk