Let me paint you a typical problem in a home office scenario: You are working at home finishing a document you need for your meeting on Monday morning, click on Print – and nothing happens. Try again, still nothing. You go through your standard “repair” techniques: turn the printer off and on, unplug the connecting cable from the printer and the computer, reconnect it, save your work and restart the computer; still nothing.
It’s time to go to your favorite search engine. You type some keywords (printer, printer model, error message if any, words “not working”) and find 1,250,000+ links. You click on some of them, and get pieces of the information you need. Your printer’s web site says you need to reset the printer, your computer’s website talks about upgrading drivers, and the operating system’s support site talks about parameters in the registry.
Who is right? What shall you do?
Welcome to the problem with knowledge: we have too much of it and it is too widely distributed. Finding the right information is not easy, and even when you do it is generally not complete: either you are missing steps that a vendor assumes you know, or there is a link to a third-party web site that is broken so you never find what you need. The level of frustration increases with each passing moment since all you want is to print, or at least to troubleshoot your problem.
According to The American Customer Satisfaction Index (ACSI, run by the University of Michigan) customer satisfaction with personal computers support departments has been in a steady decline for the past 10-15 years. This is when the interconnectivity between components escalated, and self-service knowledge centers came online. As it turns out, the cost for self-service may be in the pennies per transaction for the organization, but the cost to the customer is much higher in wasted time and frustration.
Pushing the customer to support themselves via a self-service center might sound like a good move when you have a simple solution, with no inter-dependent components, but when the problem could have multiple origins, letting the customer try to figure out what is the proper way to troubleshoot and solve the problem does not work.
The problem is even bigger for brands. Beyond upset and frustrated customers taking cheap shots at their products in social networks, they also have to deal with customer service agents and their lack of access to information. The number one reason for churn in a call center is that agents don’t have access to the right systems or information to do their jobs. When the customer cannot find what they want online, they reach for the contact center. Alas, if the agents don’t have any more information than the customer has – there is nothing they can do but sit there and be yelled at.
What is the solution?
There are three models that could solve this problem:
Hybrid Knowledge Bases – To create a hybrid knowledge base combine the content from two or more knowledge bases into a massive knowledge base. The problem with hybrids is that very quickly they become so massive that finding anything is impossible. So end users find the first 2-3 entries and hope that is the answer – similar to doing a search in the open internet – and they are not very easy to manage either.
Knowledge Management Partnerships – Two or more vendors work jointly to create solutions that are later propagated in their respective knowledge bases. In the example above, the operating system vendor would work with the printer vendor to produce specific knowledge in the places where they intersect, and then put that in both knowledge bases. The sheer complexity of coverage for all the possible combinations, and then being able to keep those up-to-date is where the model falls apart.
Federated Knowledge Bases –A federated knowledge base works in a similar model to a federated government: each vendor controls the knowledge specific to their products, and then work together in the areas where they intersect with other vendors. Using the example above, the operating system vendor would create and maintain their own knowledge base for all the issues related to printers, and then jointly create and use knowledge for where they intersect with the specific printer in question. Each vendor can create and manage their own knowledge base, they can maintain it as needed, and need to focus on only very little information in regards to the other vendors. This information does not even have to be the same as the other vendor in the same intersection, just has to be accurate from their perspective (chances are that they will be the same, or very close in nature).
Obviously there are different scenarios that would work for each model, but the federated model is the one that works better when both partners have a similar commitment to the enrichment of their knowledge bases and they rely equally on their Knowledge Bases for service.
How do go about implementing a Federated Knowledge Base? That is our next installment…
This is part one of a six-part sponsored research project I am doing with NoHold. Stay tuned for more on federated knowledge, a very cool topic indeed!
ThinkJar - The Blog (Archive)! 
Esteban,
I will try not to make this a fisking type of response, but let’s start at the top…
An insightful post highlighting a number of issues. You better than most are in a great position to help me (and maybe others) get past some of the fundamentals, so we can work to solve the problem. I get caught up in the difference between “information” and “knowledge”. The make matters worse, there is data, which is often the precursor to information.
Here is how I look at, let me know if I am on target, or off: If I have a few pieces of data, I can use the data to search and find information. In your example, I know the printer make/model etc.,… I search, I find a lot more information, and I might even find the information I am looking for (to solve the problem). Ok, so I followed the instructions I found, it works, all is good with the world. Except, when the problem happens again in a few weeks, I will probably go through the same steps – issue, I have no idea what I just did (I have no knowledge, just information).
I think the federated knowledgebase exists by the way, it is called Google, or is that an federated information database. I am truly not trying to split hairs (people who say that usually are 🙂 but I do get lost in the difference and whether these differences are important, or not.
Thanks for humoring me
.-= Mitch Lieberman´s last blog ..mjayliebs: RT @scorpfromhell: (Pics) Are Retailers Ready For The FourSquare Backlash? – PSFK http://bit.ly/a4MJml | feedback = backlash, really!? =-.
LikeLike
Bringing the support perspective to the discussion, and building on Mitch’s point, the difference between information and knowledge is the ability to obtain results. Googling ‘procedure for appendectomy’ will probably yield all the information required to perform the surgery but you are still unlikely to be successful.
There are multiple problems in searching and consolidating information and presenting it to the users, even before crossing the boundaries of the individual enterprise into the multi-vendor world, such as:
1. Making the information available to users – pushing content out
2. Ensuring the information is written in a way that is usable to the user, for example, a home printer entry would be written differently from that referring to an enterprise printer
3. Ensuring that search yields the desired results. To Mitch’s point, this is where google misses since it was never built to differentiate symptoms from models from additional text, such as the following argument “my stupid printer model 123abc will not print a single damn piece of paper”
4. Allowing users to capture their interactions and return to them after trying some of the solutions and adding more information or escalating to assisted support
Federating searches effectively, even within a single enterprise is a big enough task, think about support knowledge bases, documentation, release notes, wikis, marketing materials, user forums, etc. Now trying to combine that across vendors is even more interesting. I would love to see that one happen.
Esteban – I hope I did not disrupt your plans for future articles in the series.
LikeLike
I always find the best knowledge from the users, not the vendors. Seems like you’re focusing on the vendors to supply and organize the knowledge, instead of having them create a better shared-knowledge community.
I look forward to the rest of the series, your insights are always valuable.
.-= Tim Sanchez´s last blog ..Social CRM – A Definition for Dummies =-.
LikeLike
“either you are missing steps that a vendor assumes you know”
Now that one is a hot button of mine. I have run into that too many times to tell.
That ‘search’ federated or not – is one spot that vendors fail at miserably.
I have searched for issues or problems on vendor web sites and either received no answer – or 1000’s of documents most dealing with sales or white papers – nothing to do with my support issue
I then end up using google to pull a searched document off of that vendors web site.
(assuming it even exists) which is of course, another story!
.-= Elliot Ross´s last blog ..Process Management and the Start Up =-.
LikeLike
Isn’t the crux of the matter that there is already a lot of data AND knowledge out there but folks are not able to find it easily? I would think therefore that the focus would be more on alternative “search” solutions than creating more knowledge bases. Or am I missing something here?
LikeLike