By Francoise Tourniaire, Principal of FT Works

Support managers know that knowledge management is critical to the success of their organizations, both because it’s the foundation for self-service and also as the main reference tool for the support staff. So why is knowledge management such a struggle? This article identifies the 10 basic rules for successful knowledge management in support organizations.

Knowledge management success doesn’t happen without effort. Every support organization needs a knowledge champion. The champion;

• believes intensely in knowledge management and is a vocal advocate for it
• pushes knowledge management on the agenda of the support team and the organization as a whole
• is able to obtain and protect funding knowledge management, whether people or tools

The champion must be the top support executive to accomplish the latter two points. There is no substitute. If you’re passionate about knowledge management but you are not (yet!) the support VP, your first talk is to get that individual on your side.

There are four models for Knowledge Management (see Francoise Tourniaire’s article in SSPA News from November 2005 entitled Knowledge Management Models.)

• The content specialist model uses a team of dedicated writers to create and maintain knowledge base documents. It’s best for organizations with low-complexity products, for documents that must be researched, and for copy-editing documents that will be visible to customers
• The product specialist model relies on the product specialists (typically, tier 2 staffers) to create and maintain knowledge base documents. It’s best for organizations with a strict tiered model, and in particular organizations that use outsourcers or third-party support partners.
• The batch model assumes that all support staffers create documents as a “non-phone” activity. It’s best for organizations with high-complexity products and organizations that use a Touch and Hold model rather than a tiered support model.
• The KCS (Knowledge-Centered Support) also assumes that all support staffers are active in knowledge management, but unlike the batch model staffers are expected to create documents as they resolve cases – no batch concept there. It works well with high-complexity products.

Select a model that works for your organization. It’s fine to use more than one if you have difference types of documents. For instance, you can use a batch model together with a content specialist model if documents are written by regular support staff but polished by professional writers.

In most support organizations issues arrive in clusters. If one customer calls with a particular problem chances are that others will follow. Therefore, being able to publish documents quickly is essential to the success of the knowledge management program.

Encourage support staffers to write up issues as soon as they discover them (it’s one of the most attractive features of KCS) and streamline reviews. I’ve had clients with backlogs or weeks or months for publishing documents, which almost guarantees that repeat issues will come into the support center without the benefit of reuse. Also, having a long gap between creation of a document and publishing discourages the staff from creating more.

To help with the publishing speed issue, consider doing away wih reviews entirely. Crazy? Not necessarily. For instance, many support organizations think it’s just fine to post unreviewed documents to an internal audience (properly labeled as such.) Bolder ones consider a sampling approach to reviews, with a variety of approaches

• Review a set percentage of documents to make sure quality’s good.
• Review documents that are proven to be useful. For instance, only review documents that have been linked to at least 5 cases. This avoids reviewing documents that won’t ever be used.
• Allow experienced writers to publish without reviews – and revoke their privileges if their quality drops. This kind of pride-based incentive seems to work very well.
• Only review documents that meet a certain standard. For instance, any document that recommends installing an upgrade requires a review

If you have a multilingual audience, you should seriously consider a multilingual knowledge base. Maintaining such a beast is a big job, however, so proceed with caution.

• If you do not provide translated product documentation, you probably don’t need to translate the knowledge base documents either.
• Even if you offer multilingual documentation, you may not have to translate your knowledge base if your customers can read English (or whatever your “base” language is) with ease.
• Aim to translate the most popular documents for that particular audience.
• Get to a critical mass. If you have only a handful of translated documents it won’t be appealing to your international audience.
• Either use professional translators or get your support staff to translate. Professional translators are best, but the process can be slow. It’s fine to mix and match depending on the urgency of the need.

Once the knowledge base is past infancy maintenance is a bigger job than creating new documents. Since few support organizations have an abundance of resources to do maintenance, leverage the users’ experience.

• Allow users to flag questionable documents. There’s no reason why not do this, if nothing else. Even basic knowledge management systems can be rigged to allow use flagging. And act on the flags, for fear the users stop playing the game.
• Collect feedback. I find that only a minuscule portion of users bother to rate documents (somewhere around 1%) so there’s no need to collect detailed information, or to get excited about the results. However, a particular badly-rated document should be reviewed.
• Run usage reports and use them to target maintenance. Documents that are never retrieved may be obsolete. Documents that are retrieved but not open may need a little work on their keywords (or just a better title). Documents that are read but not linked to cases may be confusing or misleading.
• Store and analyze failed searches. You will need a good tool to help you with this chore if you have many users, but scanning through unsuccessful searches is possible and useful with low traffic.

If you have a small knowledge base used by knowledgeable users, a basic tool is all you need. Users will be able to find what they need since they have a good grasp of likely keywords and they don’t need to wade through mountains of materials.

On the other hand, if you have loads of documents, so-called naïve users who are not aware of the proper terminology or even search techniques, many different product lines, or all of the above, you need to shop for a high-end tool. The better tools can

• automatically present the most popular documents first (this feature is also available in many mid-level tools, thankfully)
• Identify the exact spot in a document that matches the user’s query. Even a little bit of context can help the user decide whether the document is a good match.
• Allow users to refine their search, ideally by suggesting likely candidates for refining.
• Match queries with the concepts in the knowledge base. So the engine should be able to suggest alternate spellings or concepts. For instance, it should know that worms and viruses could be related.

With a large knowledge base (tens of thousands of documents) look for a search engine that does all of that. On the other hand, don’t overbuy if you have fewer than a thousand documents (and don’t expect more): a simple search will do.

It seems that the usual testing model for knowledge tools and self-service is for the knowledge specialist to stare at the screen or, at best, ask a few sympathetic souls on the support team to take a test drive. That’s not enough!

You don’t need to spend thousands of dollars and recruit battalions of users to conduct decent user tests (unless you’re the head of the UI team at amazon.com, that is.) Many support organizations get excellent results by enticing user group attendees to spend 15 minutes on the support web site (it doesn’t take much more than a mug or a T-shirt.) Give the users a task and observe what they do. Don’t force them to talk (they probably will edit as they verbalize anyway). Note any areas of discomfort and confusion. The results cannot compare with what you will get with internal users.

Knowledge management works best when it’s tightly linked with case resolution because the tight link increases both the quality of the knowledge base and the performance of the support team. So ask support staffers to search the knowledge base as they resolve cases, to link relevant documents to the case, and to suggest or write documents related to the cases they resolve. Successful knowledge bases are used by the staff – and vice versa.

We support folks tend to be obsessed by metrics (a good thing, really!) Knowledge management needs to be measured just like everything else, but don’t fall prey to the quota idea.

• If you require that each staff member write a set number of documents each month, you’re likely to get them… and to end up with a cluttered knowledge base with many low-quality, overlapping documents.
• If you require that each case be linked to at least one knowledge base document, mysterious “stub” documents, empty or near-empty, will pop up to fulfill the requirement.
• If you impose a quota for reviews of existing documents, watch out for small, meaningless edits made only to meet the quota.

Should you do away with quotas entirely? Well, do you count the number of cases each staff member handles? You probably do! And you probably balance out that number with some measure of quality such as a customer satisfaction rating or the outcome of a quality monitoring program. Further, you balance out each individual’s performance with the rest of the team’s. So if Q4 is busy, everyone’s expected to pick up the pace at that time. Use a similar approach for the knowledge base. And please: put knowledge base metrics right on your dashboard. That’s what your knowledge champion would want.

.........................................................................................................

Francoise Tourniaire is the founder and principal of FT Works, a consulting firm that helps technology companies create and grow their support operations. She’s the co-author of Collective Wisdom:Transforming Support with Knowledge, a practical guide for knowledge management in support centers, which was published in January, 2006. For more information, visit www.ftworks.com or call 650 559 9826.

Comments? Suggestions? We would like to hear from you. Please email the editor at sspanews@thesspa.com.

Download PDF