Your FAQ Sucks. Here’s How to Fix It.
I’m the CEO of a small software company; our product line simplifies downloading audio and video content from the Internet. Due to the wide variety of websites we work with, the process can be fraught with complications.
While our software does a good job to streamline things, we still get a shit ton of support requests.
What’s more disturbing was the cost of each ticket. After some analysis, we discovered some products averaged $19 per ticket in employee-costs.
$19 for each support ticket! Fuck. For a product line that sells between $19 and $79, this was seriously unacceptable.
Our support process was a help desk system paired with a knowledge base. For a lot of companies, this works well, but our FAQ documents didn’t work in this format. Most of the procedures were like this:
- Try this trick. Did it work?
- If yes, go to step 3.
- If No, go to step 4.
- And so on…
Due to the non-linear nature of our troubleshooters, our customers quickly gave up and just submitted a ticket. Then, our tech staff would go through the same troubleshooting sequence via email, with a lot of back-and-forth. At $37/hour for a well-trained tech engineer, you can see how this added up very quickly.
Despite the fact that sales were good, we weren’t profiting like we should have been. Support costs were killing us.
I’m first and foremost an engineer, so I hacked together our first interactive troubleshooter in PHP. After flow-charting the process for supporting our most popular product, we built and deployed a series of web pages, with “try this” in the content area, and branching into the next “try this” stage via hyperlinks.
The goal was for customers to answer questions, try some things along the way, and find solutions on their own. This was our first “interactive decision tree,” and it made a big difference right away.
After deploying our decision tree, the next problem we encountered was that our content was more fluid than we expected. Editing code was not optimal — our techies were always asking for changes to our decision trees, and it required non-trivial engineering time to maintain the content and flow of our trees. The next step was to turn this idea into something anybody could use — sort of like a Wordpress for decision trees.
Zingtree, the “toolkit for building interactive decision trees”, was born.
We started with a form-based editor, where authors could create “Nodes” with formatted text, images, video or anything else, and then link to other nodes via questions and answer buttons. These trees were inserted into our help pages via an iFrame, and customers could easily navigate and self-solve their technical issues. It was a huge hit.
Although we still get support tickets, the volume is more manageable, and our support techs can spend their time doing more interesting, meaningful things.
We also included a transcript of the customer’s path through our decision trees when they couldn’t solve their problem, and wound up submitting a ticket. This helped reduce the uneccessary back-and-forth, since our techs could see what steps the customer had already gone through.
Since we first launched Zingtree, we added a graphical design tool where you can draw boxes and arrows to build your tree, and these will turn into working code automatically. (I’m not a visual preson, but many people are. My team had to talk me into this, and they were right!) We’ve added a lot of other capabilities that customers have asked for as well, and after a couple of years we have a few hundred amazing clients.
Zingtree works out to about ten cents per session. Given that the average company spends upwards of $5 per customer support ticket, it was a big win.
Zingtree hasn’t proven itself to be a cure-all for all companies, but we’ve found that our customer base typically has technical products which require interactive troubleshooters like our other company. We’ve also been surprised to discover that call centers LOVE our product, since it gives guidance to customer service reps answering the phone or doing live support.
Search-oriented knowledge bases will always be a helpful tool. But, if your product requires more in-depth troubleshooting, you should try Zingtree or another similar product and see if you get better results. And definitely figure out how much each ticket is costing you — you’ll be amazed, and probably shocked (and maybe a little sick to your stomach, too).
So, try adding an interactive decision tree to your help page! Maybe, just maybe, your FAQ will suck just a little bit less.