Community tip: refactoring reporting with conditional fields

Community tip: refactoring reporting with conditional fields

December 1, 2014
Community tip: refactoring reporting with conditional fields

At first, our implementation of reporting on why people are writing in to support was pretty simple — 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 organizational system. Read our community tip to see how we used Conditional Fields to produce the reports that we needed.

Head on over to the community to learn more about our journey with refactoring our reporting.

This week’s tip by Ani Niow, head of Support Operations at Automatic.

We know. It's a lot to take in.

Sign up for our newsletter and read at your own pace

Please enter a valid email address

Welcome to the club!

Oops! Sorry something went wrong, try again later?