The following post was previously published on John Ragsdale’s blog, Ragsdale’s Eye on Service, and is re-posted here with permission.
I consider myself an expert on knowledge management for support. But when I have questions, I go to someone with even more expertise than I have: David Kay of DB Kay & Associates. I recently had a conversation with David about how everyone seems to think they are KCS (Knowledge Centered Support, the recognized standard for support knowledge capture, publishing and maintenance) compliant, but they clearly have practices that are not true to the spirit of KCS. David has created a list of questions to ask yourself to see if you have strayed from your KCS training. I was going to use this in a webcast a couple of weeks ago, but the webcast content took a turn in a different direction and I wasn’t able to use it. But I thought the list was important enough to include in a blog post.
Here is the list from David, with some comments from me:
Does your customer-facing staff:
- Consistently search for knowledge while resolving cases? If techs don’t search for content every time, they rely on how they solved the same problem in the past. The problem here is that the knowledge article may changed, due to a product revision or new release, or maybe someone found an easier approach to solve the problem. Encourage even senior techs to search every time and be on the lookout for article updates, especially after a major product release.
- Link cases to relevant content, new or reused? Linking support incidents to knowledge articles gives you accurate data on exactly how many times each known problem occurs, which not only allows you to put an ownership cost on each problem, but helps product management and development prioritize bug and enhancement requests by targeting issues impacting the most customers.
- Universally contribute to the knowledgebase, if they have knowledge to share? I get so many questions on how to encourage everyone to contribute to the knowledgebase, and my answer is you have to leverage both the carrot (incentives, rewards) and the stick (performance reviews), making knowledge everyone’s responsibility, and reward those who participate and penalize those who don’t.
- Capture knowledge in the workflow, while working cases, rather than later? It should not take a degree in creative writing to submit knowledge. With templates and process flows, techs should be able to easily submit new articles using incident notes while working on the problem. The key here is to capture and share the knowledge as quickly as possible. Especially after a new release, many customers may report a bug at the same time, and you don’t want multiple techs investigating the same problem. By submitting an article about the problem as soon as possible–even if the fix is pending–anyone else who encounters the problem won’t waste time reinventing the wheel on a solution.
- Improve knowledge as they use it? How many times have you read a knowledgebase article and noticed a spelling error, a leap in logic, or a missing step? Support techs should be encouraged to submit suggestions to improve content, always with an eye toward making the article as easy to consume as possible by novice techs and customers attempting self-service.
- Self-approve their content, if they have the right KCS license?The key is getting new content available as soon as possible, to avoid the reinventing the wheel problem mentioned earlier. Senior techs should be able to publish articles visible to all front line workers, even if an additional layer of review is required before publishing the content to other departments or customers.
- Understand that knowledge is a big part of their job? Every single employee runs across new information in their jobs. The knowledgebase should be the braintrust of the entire support organization, not just senior techs or designated knowledge experts. As I said earlier with the carrot and the stick, use whatever means necessary to get EVERYONE to participate. This means coaching some reluctant contributors that if they will share their hard-earned secrets, it means they can spend less time solving the same problems over and over, and begin tackling some new and more interesting problems.
This article is republished with permission from John Ragsdale.
Share this: