Hi folks, I run Support Operations at [Automatic](https://automatic.com) and I [was asked](/hc/communities/public/posts/203564276-some-advice-on-the-best-way-to-report-tickets) if I wanted to share how we refactored our usage of Zendesk in order to get it reporting exactly how we needed it. It was pretty tough for us to pin this down and we left a lot of meetings with seemingly no progress made, but we ended up coming up with a system that is a significant improvement over the last. I hope this helps other companies work out their helpdesk to get it exactly how they want. Without further ado.... –––––––––––––––––––––– Our implementation of reporting on why people are writing in to Support was pretty simple at first. An ever increasing drop down of issue types. We implemented this since Zendesk's tagging system didn't quite do what we needed. There was no way to restrict creation of tags or otherwise have a curated list. Basically, we wanted a system that left human error out of the equation as much as possible. We quickly learned that having one massive drop down list isn't sustainable long term. Many of the issues we deal with involve multiple teams. We make a hardware device which connects to an app, and a user may have an issue that spans both or more. The user may have another issue later on down the line and if we switch the selection in the single drop down, we lose the original one. After several meetings and talking with others in and out of our company, we ended up deciding on a team and journey organisational system. It was important to us that we can tell a specific team that X many users are experiencing a specific issue. The journey of a ticket stemmed from the reason they originally wrote in and continued until it was solved. Often times this was done with a single macro but given the nature of troubleshooting our product, it often was not. As we learn more about the situation, the initial assessment may have expanded into something more complex. We needed a system that took into account all of this and didn't replace the initial assessment, but let us have many more options. A single drop down wasn't going to cut it. The best way to do this however, was the subject of much discussion. I led a task force to audit our current system and recreate it using Conditional Fields. We drilled down the absolute core of the reasons people write in and developed a system which enabled us to select multiple fields at once. It took us awhile, but the result was pretty fantastic. See below for a screenshot of what we came up with. !(/hc/user_images/6rYkEK7Minx_AZ7O6w6SuQ.png) App, Car, Core Features, Firmware, Link, Miscellaneous, Server, Usage are all the roots that we determined make the most sense for us. A user may have a question or problem which spans multiple fields, but we seldom switch within the field once one is selected. That's an important distinction as switching within the same field in a drop down will leave no trace of the original selection. Even the tag associated with it is replaced. Using Conditional Fields, some of the selections here have another drop down open up below once a certain one is selected. Feature Requests is under Usage for example. Return and Exchange are checkboxes as they're a simple yes or no and don't need to take up any more space than necessary. Selecting Return will open a drop down menu with return reasons below it. !(/hc/user_images/AbjW7gjSjowyAFCwoRlguA.png) Using Zendesk's multiple ticket form feature, we separated out order questions from the rest of the fields since people emailing about an order generally haven't received the product yet and therefore don't have much to troubleshoot with. :) When a customer replies to their order email, that gets sent to a different one than our general support email, so it was simple to set up a trigger which selected the Order form when this happened. To mitigate the problem with same ticket having multiple issues, we changed our automations to close a ticket after 4 days instead of 90. It was so long before since you can't change any information about closed tickets so we wanted a buffer in case we had to go back. With the new system, we took into account that if someone waits a few days to email us back, it's likely about something different than their original email. If they reply back within a day or two, it's generally about the same issue that's still happening. Replying after 4 days simply opens up a new ticket and we can assign the proper type to it. This whole process was the bane of our existence for awhile and we're glad it's finally over. The new system is significantly more scalable and flexible. I hope this helps with any other people that are banging their heads on their desk wondering how to get it done!
Post ist für Kommentare geschlossen.