Writing things down so that others can reference them in an official knowledge repository does funny things to our thinking….
Here’s the backstory. I spoke to someone recently who told me his company (a very well known, large company) is hesitant to let their customers know when they have an issue with their products (software and/or hardware) – especially when they don’t have a solution. The reason: they don’t want to look flawed.
Long story short; I pointed out that this lack of transparency is a lost cause. Their customers are already talking about them, especially when things go wrong. They have two choices: be the hub of communication for their customers, the first place their customers go when facing a question or issue; or, let issues go unattended, circulating out “in the wild” without any ability to influence that conversation. In either case, their customers are talking about them.
Most of us work very hard to get things right. We want the answers we give our customers to be right, and this is appropriate. The standards we define around what we provide to end users, internally and externally when it comes to support, are usually the wrong ones, however. Let me explain.
We chew up a lot of cycles, time and effort reviewing information before we release it for public consumption. We all tend to apply the marketing department standards to support information: we think it has to be pristine and perfect. And that’s the rub.
We create processes and gates to vet knowledge articles that we expose to the public, because we believe each article has to be pristine. We seem to be afraid that we might post a solution or answer that might have a mistake in it. The result is that we slow the flow of information waaayyy down. But why?
Why do we require gates and permissions when we share written solutions to issues our end users are facing? To answer the questions they ask us?
The old double standard
The fact is, we employ a double standard. When our support personnel are talking with end users on the phone, we don’t require them to get approval before they answer a question. We accept whatever answer our support personnel can locate and provide. And for most of us, all of those calls are recorded for quality and training purposes. On the other hand, we get quite protective about the answers we provide when we write them down – or put them into a knowledgebase.
There is a better way, and our customers love us when we follow this path. Set the same standard for spoken solutions and written solutions. Then, shift your thinking about the written solutions. Rather than pretend that the knowledge base is the final and definitive source of answers, think of it in the same terms as the Wikipedia model: crowd-sourced, best-likely answer unless and until someone amends it.
This shift in thinking signals that we are moving from the age of monolithic encyclopedia volumes to a much more accessible and dynamic knowledge ecosystem in which experts from our organization, experts from our user base, and others can contribute in real time:
- ask questions
- answer to the best of our ability
- contribute ideas and insights
- offer suggestions
- posit different scenarios no one else thought of
- try different uses for products
What restrictions do you place on content before you expose it to your end users? What do you do to accelerate getting your organizational learning into the hands of your customers?