A knowledgebase can be a great tool for allowing your customers to help themselves and solve their own problems. However, this effectiveness doesn’t come for free and takes hard work on behalf of your organization to get it right. Since we’ve helped develop knowledgebase content for a few companies now, we thought we’d share a few learnings from along the way.
To start with, realize that pretty much every knowledge base (KB) system is flawed. We’ve yet to see a perfect system and most tend to have very fundamental shortcomings. For example, one KB system we’re helping a customer with right now, is limited to one file attachment per article and can only support filenames up to 40 characters in length including the “.” and extension (a limit that you thought would have went away with the end of the 1980’s). So learn your system’s shortcomings early on (preferably before buying the software), and devise a plan on how you’re going to get around them. In this example, we’ve limited filenames to just their unique document number’s which fit well within the filename limit.
Most KB software allows you to organize articles into a hierarchy of categories so it’s important to think this through carefully. A good approach is to devise a hierarchy for products and sub products, while keeping other categories like FAQ’s, white papers, etc. under their own branches. More generally try to keep the hierarchy simple both in breadth and depth so your users can easily find articles in future searches if they navigate the tree.
Similarly, most KB software will allow you to devise templates for your articles consisting of different fields for different types of articles. We’ve found it best to also keep this simple because it can be difficult for other authors around your company to determine which template they should use when creating a new article. Limiting the number of templates to two or three is a good rule of thumb, as is using self-documenting naming conventions and documenting the purpose of each template somewhere.
Providing links back to a KB (e.g. from your documents) can be a double edged sword. On the one hand it’s nice to provide a direct link to KB articles from other sources but at the same time if your KB article URL’s ever change then you’re left with a collection of broken links. We’ve found it more beneficial to simply tell the reader to see the company’s KB for more information, rather than embed direct links or provide specific KB numbers. More often than not, KB URL’s change over time or companies change to new KB systems, so we’ve found this to be the lesser of two evils.
Finally, remember that it’s all about quality content. Be sure to introduce an article by providing any relevant background information on what the article provides, and why the reader should be reading it. Don’t assume that the reader intended to read any given article, since they likely come across an article by searching for keywords. So “ground” the reader first so they can decide if they should continue reading an article before getting into the details.
On a similar note, be sure to come up with a consistent format and layout for each type of article. Use consistent headings, bullets etc. so that the reader can become familiar with where to find information in any given article.
Like all forms of writing, the creation of an effective KB requires a bit of thought. Understanding your system’s limitations, creating a consistent layout, and adding quality content will ensure that your KB serves as an effective tool for your organization.