Ticket classification options
I’m trying to re-create the ticket classification options we have in our current system in Zendesk.
The current system will display up to 3 options to the agents, e.g.
After you have selected Product, then the list of Issues is filtered to only show those for the selected Product.
After you select Issue, it there are sub issue options for it, then the list of Sub Issues is displayed and filtered to only show those for the selected Product and selected Issue.
We currently have 30 Products in the dropdown, 390 Issues and 159 Sub Issues.
What is the best way to do something similar in Zendesk?
I have experimented with one giant, nested drop-down "Category" field, but can see that getting very unwieldy to manage. We also don’t like that as once selected, they only show the final value, not the “breadcrumb” of selected options so you can’t really see what’s been fully selected.
Would creating multiple custom drop down fields of Issues for each Product and conditionally showing the right dropdown field be a good thing to do, or bad for performance/reporting? We would also have to create multiple Sub Issue dropdowns for each Product/Issue combination that needs it and conditionally show that as well.
Thanks for any advice,
I've used both ways you've described - one big "Category" field or 2-3 nested fields - and I far prefer the first one.
Each potential item would be structured Product::Issue::Sub-issue. For example, Consumer::Update Contact Information::Change Contact Number. The :: allows you to report at various levels.
The problem I've run into with the nested fields is that reporting is atrocious. There's no way to gather the data in Explore and make sense of it without doing a lot of data manipulation in a spreadsheet.
The bigger question I have for you, though, is whether you have too many Products/Issues/Sub-Issues. With so many to choose from, does that slow your support agents down? And are you getting meaningful information, or just a bunch of Sub-issues with 0-2 tickets? At a previous company, when I came in we had ~500 categories. We narrowed them down to ~100 and were able to get much more meaningful data.
We do similar kinds of things with Formset.
It's a paid application, but it does this particular function very well.
Thanks for the advice. I know it seems like we have a lot of options, but in works well for our teams. I think we're going to initially try the single, giant, nested drop-down.
I may follow the advice in this post: The 'About' Field – Zendesk help - and set-up each item as follows: Consumer::Consumer/Update Contact Information::Consumer/Update Contact Information/Change Contact Number. So once we select an item we can see the "breadcrumb" - but clearly the text gets a bit long, so we may have to play about with the wording.
The reporting does sound like a bit of a pain, but this article Explore recipe: Reporting on nested drop-down fields – Zendesk help seems to suggest we can make it easier using "Standard Calculated Attribute"s.
I also see it being a bit of pain configuring other conditional fields we want displayed based on the selected Category. It's very restrictive having just a "If value is" condition (really wish there was a "If value contains" condition available!), It will mean we have loads of condition rows added for each sub-option :-(
Please sign in to leave a comment.