How to Start Building Your Knowledge Base

When I hear a customer say the above phrase or anything similar, I cringe a bit. Each time someone has to contact support after trying to find help on their own is a missed opportunity.

A knowledge base can really help to reduce those missed self serves. The realization that you need one, however, often comes with the realization that you have no idea how to build one. These questions may sound familiar:

1. How do I get started?
2. Where are the areas in my application that need documentation the most?
3. Is the benefit worth the resources?

Our Story

Like most places, SurveyGizmo started out with very little documentation. When a customer ran into an issue, it was very hard if not impossible for them to find a solution on their own. A fairly large amount of our customer support volume were “How Do I” questions. While we always love showing off our stellar support team, our customer base was growing very quickly and our support team was having trouble keeping up.

Help Them Help Themselves

We realized that in order to scale our support in a sustainable way we needed to make a change. We began to focus on what we call “proactive support”. The idea is to reduce support volume by preventing requests from being created in the first place.

The Bumpy Road to Success

Ok, so we had an idea of what we wanted to do but actually getting it up and running was by no means a cakewalk. Here were a few of the major problems we ran into:

• Documentation started to get written but it was inconsistent and hard to find
• We didn’t have a good way of tracking whether or not the documentation was having an effect
• Without a good system for managing our documentation getting new content out was painful

Seeing the Light

After a rough start, we decided that in order to really make a difference we needed to put the resources into it. We hired two full time documentation authors, and molded our knowledge base tool, HelpGizmo, to give us the data that we needed to make the correct decisions.

If You Build it, They Will Come

How are you supposed to know if your knowledge base is making a difference? If you aren’t actively tracking the numbers, you can’t. Or at least I can’t. I guess I shouldn’t assume that you don’t have super powers. That was kinda rude of me, I apologize. For most of us though, data is king.

Follow the Data

Here are some things that we track with our tool:

1. Which pages are generating the most support
2. What search phrases people are using
3. Whether or not after searching for a phrase the customer submits a support request

“We’re not ready for software!”

That is absolutely understandable. Software can give you some great additional data, but if you want to prepare before you decide I would suggest bucketing your help requests. It’s actually just a good idea in general even if you do decide on utilizing outside software.

Our Support Buckets Breakdown

As with anything, you need to find a system that will work for you but here are the buckets that we use:

• How Do Is — These are your main targets. When creating a new knowledge base from scratch, try narrowing down the top ten most common “How Do I” questions that are coming in. If you can create ten help articles that answer those ten questions you will be off to a great start.
• Bugs/Issues — We don’t create help articles from these at the moment, but some companies, especially ones with long release cycles find success in doing so.
• Features/Enhancements — In terms of documentation, these are pretty similar to bugs / issues.
• Dream Support — This one might be a little bit more specific to us, but I thought it was worth sharing anyway. These are customer support requests where our customers either want our advice on something, or  want us to help with their projects. We love getting these requests as it means that our customers trust our opinions and believe we can help. This is not a number we necessarily want to drive down.

The Payoff

It wasn’t an easy ride for us, but it was definitely worth it in the end. By tracking our support in a meaningful way and creating documentation based off of real data we have been able to get more and more people to self serve. We all want our software to be so easy to use that the thought of needing something like a knowledge base is just silly. But for the majority of us that aren’t quite there yet, providing relevant, easy to get to help articles can create happy, self serving customers.

What are Your Biggest Hurdles?

What do you guys feel like are the biggest hurdles you have to getting started? Are they pretty similar to the ones I mentioned up top or are you facing something entirely different? I would love to hear your stories.