Michelle Stumpf, KCS (KM) Practice Director

Remembering the four Core principles of KCS

When you are implementing KCS, it’s important that you never forget the four core principles of KCS when making decisions about the practices and techniques you are planning on implementing in your organization.

Demand-Driven

Aligning to demand is what KCS is all about.  In a typical Knowledge Management approach, the creation and maintenance of knowledge are often created because we think we need it, not because we know we need it.  For the knowledge that’s created based on requests or search and usage metrics, it’s often created so far after the initial demand came in that it’s not fulfilling the demand at the time of need.

In a KCS environment, we are creating content based on the demand for it.  If someone reports an issue or asks a question on how to do it and we have identified a gap in the knowledgebase, that gap is plugged immediately by the person responding to the request.  The review process is also demand-driven as well, incorporating the review of articles into the reuse of those articles which eliminates timely processes on unused articles and also provides a more valuable review as the review happens when we actually have users with the issue that can confirm the fix was accurate.

When you are making decisions about the processes in your organization, here are a couple to keep in mind when trying to remain in alignment with this core KCS Principle:

• When introducing a new product, applications, etc. into your environment, do not pre-load your knowledgebase with articles which you think you might need to help reduce calls from coming in. This is precisely the method we followed previously which did lead towards the successful use of that content.  Instead, get involved with your organization’s testing and capture the questions people are really asking and how it’s really breaking instead of asking developers how they think it might break.  Always remember, we want content that we need based on why it’s needed and that includes the customer’s context.
• If you have a new group or team looking to come on board to your knowledgebase and follow KCS, try to avoid doing a mass import of their content into the knowledgebase. The content may not be structured, and it probably does not contain the customer’s context so this will make this content more difficult to find by your targeted audience:  your end-users.  Instead, see how you can still access this information from the existing knowledgebase and pull it into the KCS knowledgebase as you gain the customer’s context which is then added to the KCS version of the article.

Create Value
When we focus on shifting to following the KCS Practices, we shift our focus from activities to outcomes.  The outcome of our KCS activities is the value that is created both for the organization and for your customers.  When we’re looking to create value or to assess the value that has been created, focusing on the number of activities completed doesn’t automatically determine the value that was created.  Assessing the value that is created may be difficult, however, this is the real metric that helps us determine how successful we are.  Understanding what activities were required to get there gives us context, but it shouldn’t be our focus as then we lose sight of the end goal.

When you are making decisions about the processes in your organization, here are a couple to keep in mind when trying to remain in alignment with this core KCS Principle:

• When following KCS, we have shifted away from rewarding our knowledge workers for the number of articles used, created, or modified. Instead, we have moved towards looking at whether they’ve used the correct knowledgebase article and how often they took the opportunity to create and modify when given the chance.  Keep this in mind when you’re looking to communicate how well things are going with KCS.  We often see companies forget this core principle when they send out a communication congratulating a knowledge worker for creating the most articles that week.  This is something you want to steer clear of as it sends the wrong message to the knowledge workers… that we’re looking just at how many they’ve created, not the value they created for the company.  Better communication would be congratulating a team for collaborating to create an article that helped save the company $250k based on the reuse of the article combined with the reduction of calls for this particular issue.
• Similarly, we think that since we’re not talking about a specific agent or team that we can share stats about how many articles were added to the knowledgebase given a specific time period. This may be a number you track internally, but this should not be something communicated to your knowledge workers as it reinforces that the number of articles is created and this typically leads towards agents not reusing the existing content but creating new content so they get credit for creating content.

Abundance

The principle of abundance is one that can be easily bypassed when designing KCS processes for our organization, but it’s one that we really need to keep in mind.  When it comes to this principle, it’s different when we talk about knowledge versus something tangible like an apple.  If I shared an apple with you, I’d cut the apple in half and I’d essentially lose half my apple.  But, with knowledge, if I shared what I know with you, I don’t lose half of what I know.  Through the conversation, more ideas may be generated.  The more people you have sharing knowledge, the more robust your knowledgebase is going to be.  We always want to design with abundance in mind, not scarcity.

When you are making decisions about the processes in your organization, here are a couple to keep in mind when trying to remain in alignment with this core KCS Principle:

• One of the most common mistakes we see being made is limiting the number of publishers that you think you need in your KCS Practice. Ideally, the goal is that everyone will prove their KCS proficiency and get to the Publisher license.  If you limit this and keep qualified people at a lower level, they aren’t enabled to publish to self-service which has a profound ripple effect:
  • Contributors who update/create an article with a resolution are forced to leave the article in a Not Validated state which means that it can’t help any customers looking for a resolution through your self-service portal.
  • A Publisher will have to then take the time to review the article and make the determination whether or not to publish it to self-service. Note that they’d be doing this in the absence of helping a customer with this particular issue, one which they might not have any knowledge of.  This also caused the publisher to spend time on something they really didn’t need to spend time on – so double effort between the contributor and the publisher to do what the contributor could have done originally.
  • And don’t forget about the time wasted between when the contributor solved it and when it was actually published to self-service where that already-solved issue continued to cost your company money.
• Another common mistake we see being made is limiting the number of agents that can participate in KCS. If you’re only selecting certain people to create knowledge, you’re not really doing KCS, you’ve pulled agents onto your authoring team.  The first practice in the KCS Solve Loop is Capture where we are capturing in the customer’s context and capturing in the workflow.  Taking this approach breaks down KCS right from the first practice.
  • One, by only having a select few create knowledge, the remainder aren’t capturing the customer’s context when solving issues.
  • And two, if someone who doesn’t have the right to create identifies an article that needs to be created, everyone (including your customers) is now delayed at knowing this is a known issue as someone else needs to be tasked with creating that article.
  • Even if you have your non-authoring agents flagging articles to fix things and add the customer context, those details aren’t visible to self-service and they’re not searchable until someone else comes in and updates the article which could be quite sometime later. Self-service success means your customers can easily find what they’re looking for in your knowledgebase and solve their own issues.  KCS enables everyone to make timely relevant updates to knowledgebase articles.  If an agent is unable to capture that context and edit the article, you’ve lost the next opportunity for the next customer who uses those same terms to describe the issue to self-serve.
  • Another point to think about with this approach is how you can incentivize using and sharing knowledge if the agent is only participating through flagging articles and doesn’t really have co-ownership of the knowledgebase. We know that human nature tells us that people care more about the things they own then the things they do not.  We’ve seen how co-ownership of the knowledgebase incentivizes agents to share what they’re learning because so many benefits come from that sharing.  When they’re not a part of this, it can be difficult to get the usage and feedback we’d see otherwise.

Trust

The principle of trust is one of the most important principles to uphold when implementing KCS.  When we are designing our KCS Processes, we must exhibit trust.  We need to enable, empower, and engage those who are contributing to our knowledgebase.  If we design our processes to the weakest link, we don’t enable our strongest to contribute in a valuable way.

When you are making decisions about the processes in your organization, here are a couple to keep in mind when trying to remain in alignment with this core KCS Principle:

• Stop locking down your knowledgebase so people cannot contribute. You’ve hired smart, capable people and you’ve enabled them to help your customers directly, so enable your agents to create and modify the articles.  Through the KCS Practices, incorrect or incomplete information is corrected upon the next use.  So as long as your agents are using the knowledgebase, they will always have access to the most accurate and up-to-date information possible.  Trust that they will do the right thing because they understand KCS and because they care and treat the weakest links as exceptions to the rule, not the rule.
• Stop saying you’ve got smart agents and then design processes as though you’ve hired dummies. As I mentioned before, you hired smart, capable people and you’re letting them communicate directly with customers.  You trust them enough to speak to customers, but not enough to write down what they’ve learned through that interaction.  As I’m sure you’re beginning to realize, these two actions contradict each other.  If an agent gives out incorrect information and they’ve written it down, we can correct them. If an agent gives out incorrect information and they haven’t written it down and we didn’t hear the call, we can’t correct them.  Being able to correct misinformation leads to more knowledgeable agents and more consistent answers given to your customers.

I hope you’ve found these best practices and tips helpful!  In addition to this ongoing blog series highlighting some of our best practices and lessons, we’d like to extend the invitation to join our KCS Community:

1. Enhance your KCS knowledge by attending one of our upcoming KCS training sessions.
2. Talk to me! If you’re unsure if KM or KCS is right for your organization or if you need some help with your plans to implement KCS, let’s have a talk about it. Contact me directly mstumpf@uple25.wpengine.com

Also, my team and I are available to assist you with your KCS Implementations and have a range of services available from running something as simple as your KCS for Agents training to helping you implement KCS every step of the way!  Contact me directly for more information: mstumpf@uple25.wpengine.com

In case you missed any of the previous posts in this series…

• Blog Post II: Introducing KCS to your Agents