The Secret Knowledgebase, Part 2
If you haven't already, please read The Secret Knowledgebase first before you read this post, otherwise this won't make any sense to you. Thanks!
As promised, here are my thoughts.
First of all, there is nothing wrong with the knowledgebase tool. In fact it's really a great tool. The problem here has nothing to do with tooling. The proof: the support agents are quite happy using a simple network folder for knowledge sharing.
I'm also happy that management takes knowledge sharing seriously. And I'm even happier that the support agents on the workfloor have the motivation to share knowledge with each other.
All the ingredients for a successful knowledge sharing program are in place!
But there appears to be a disconnect between management and workfloor. They point at each other and say "they don't understand it"! For the support agents, the knowledgebase tool contains official, management-sanctioned instructions. Important, sure, for new hires. Their network folder contains stuff that the agents need to solve customer issues every day. Management on the other hand believes that the knowledgebase should be used by the agents, that's who the knowledgebase was implemented for in the first place. And they're right, too.
It would be so easy to say "let's merge the two", but I am convinced that this is futile if we don't first address this disconnect between management and workfloor.
In my opinion, two main issues prevent a successful knowledge sharing process:
1) Lack of ownership
Who owns the knowledge that resides in the knowledgebase? I can tell you that the support agents don't feel like they own it. They had no influence on the implementation, no participation in the creation and improvement of the knowledge items except for checking a box. To them, the KM team owns the knowledgebase and the knowledge items in it.
The KM team on the other hand are not, or hardly, involved in the daily problem solving process. It's surprising how fast you lose feeling with the day to day operations on the support floor when you're pulled away from it. They miss a great deal of context as they write knowledge items.
2) Lack of trust
The way that the knowledge sharing process has been designed, shows a great deal of mistrust from management towards the support agents. Indeed, the process has been designed with the weakest performer in mind.
The support agents don't trust management either - they've kept their own knowledgebase under the radar for all this time.
The solution?
Trust is key here. Management needs to learn to trust their support agents, but that also means that the support agents need to be ready to be trusted. Clear communication, alignment of the organizational goals with individual values - why are we doing what we're doing? - and connecting "what's in it for me" with the outcomes of a successful knowledge sharing practice.
Only then can we truly transfer ownership of the knowledgebase to the support agents. Management defines the what, the support agents define the how: from designing the workflow to the day-to-day creation and improvement of knowledge articles.
The good news? The wheel has already been invented, tried, tested and proven to be extremely successful. Developed since 1992 by the Consortium for Service Innovation and adopted by service and support organizations across the globe.
It's a methodology called Knowledge-Centered Support.
Sander, I intended to respond to your first post earlier, but LinkedIn ate my post :( Agree that there is a disconnect. My point would have been that the tool appears to be client-facing as well as internal (just basef on a couple of references, eg to "language the customer will understand") and I think this is its key flaw. For internal knowedge exchange, speed and access trumps layout, grammar, and even accuracy (assuming ongoing evolution of content). This is at odds with the "high quality" demanded by management.