Are you REALLY KCS Complaint? David Kay Documents Common Departures from the Standard

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.

For more information, you can find the original list at dbkay.com/checklist, and David has a video discussing the list on YouTube: http://www.youtube.com/watch?v=xb8TQKUZwXU&feature=youtu.be

Thanks so much to David Kay for the great content, and thanks to all of you for reading!

Explore posts in the same categories: Technology

Tags: , , , ,

You can comment below, or link to this permanent URL from your own site.

4 Comments on “Are you REALLY KCS Complaint? David Kay Documents Common Departures from the Standard”


  1. [...] following post was previously published on John Ragsdale’s blog, Ragsdale’s Eye on Service, and is re-posted here with [...]


  2. [...] following post was previously published on John Ragsdale’s blog, Ragsdale’s Eye on Service, and is re-posted here with [...]


  3. Wow, John, thanks for the good words and for sharing this! You did an outstanding job distilling these points. I wish I could have you follow me around to say, “what David actually *meant* to say was…”


  4. [...] caught up with John Ragsdale, VP of technology research at the Technology Services Industry Association (TSIA), to discuss three [...]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

Join 103 other followers

%d bloggers like this: