How Anyone Can Create A Useful Knowledgebase

According to Wikipedia, the primary benefit of a knowledge base is to provide a means to discover solutions to problems that have known solutions which can be re-applied by others, less experienced in the problem area.

There are great knowledgebase products, but most require the investment of a lot of time and money. Most companies adopt one of two approaches. The first approach is to document everything in Microsoft Office files and file them away on a shared drive. The other approach is to gather the company's experts, stuff them in a room to brainstorm every possible problem and solution and document it in something resembling a fancy flow chart.

Both approaches create a knowledgebase that isn't very useful. I'm sure you've been on the phone with a call center that uses one of these. They work like the horrid hardware troubleshooting steps in Microsoft Windows, taking you step by step through a full barrage of things to check, even those that have absolutely nothing to do with your problem. It wastes your time and paints the company in bad light, but what is worse, it doesn't solve your problem.

Back in the day, when I worked in technical support in a call center, we had a knowledge base that worked better than anything I've seen since. It was so simple and I'm going to tell you how to set it up for yourself. We wore headsets, a must for a call center, which left our hands free to record every detail of the call in a document. When a customer called for technical support, we recorded three things: their problem, the resolution (when we closed the call), and the steps we took along the way from problem to resolution.

At first glance, it might seem that recording the steps taken along the way from problem to resolution are unnecessary. Aren't the problem and it's resolution enough to help future customers? Not really. In fact,the documentation of the steps prove to be the most valuable.

Here's how it works: You're a junior tech support technician and a customer calls up with a problem--let's say it's "My printer doesn't work." So you search for "my printer doesn't work" and you find two previous calls. Both have the same resolution: wrong printer drivers. So you have the customer download and install the correct version of the drivers, but their printer still doesn't work.

So you dig deeper through the records of the previous calls. Both were recorded by senior support techs who really know their stuff. One just recorded the problem and the solution. No help there because that didn't work for you. This is like the end of the crappy automated Microsoft Troubleshooting system. Your printer still doesn't work? Sucks to be you.

The support tech documented every thing he had the customer check before he discovered the problem. His customer didn't have those things wrong, but yours might. So you ask every question the more experienced tech asked until you get to "Is your printer plugged in?" "Uh, no." "Well there's your problem." (Don't laugh. It happens far too frequently). You close the ticket putting "Printer wasn't plugged in," as the resolution and close the call. Then you think better of it. Reopen the call, and record from memory, everything you had the customer check that could have been the problem, but wasn't -- to help on the next call.

Don't tax your company's resources for the latest in artificial intelligent systems that cost a fortune and take so much time to implement that they are obsolete as soon as they are built. Look for a simple tool that allows you to enter and search on three text fields: problem, resolution, and details. Other tracking fields are helpful, especially those containing details about the customers, but concentrate on the first three and you will sure to build something useful.

Seed Newsvine

Bookmark this article in your preferred program

Comments

Add Comment

Popular Articles in this cathegory

This article is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License.