Microsoft performed an analysis of the questions that were being asked about Vista, in order to understand how many of those 8,000 articles were actually in common use. What Microsoft found was very, very interesting. 60% of all the questions being asked about Vista were being answered with only 200 knowledge articles. That's only 2.5% of all of the knowledge for the Vista domain!

This is a truly stunning finding, particularly given the size and technical complexity of the Vista operating system and the number of incidents and requests that could potentially be expected to arise for those supporting it.

I went back and looked at projects that we have done at Conversive, to determine whether the knowledge that we worked with fit into this same pattern. This is a tricky exercise for several reasons. One big difficulty is that many domains are not as thoroughly documented as Vista. The average company may not have a very clear idea about how many pieces of knowledge are required to support their products, their web site or their sales process. That makes determining an accurate denominator difficult for the purpose of establishing a percentage of the knowledge domain that actually does the lion's share of the work. Another difficulty in addressing this issue is that many of our deployments address knowledge from multiple domains. To use the Vista example, if your deployment is supporting not just Vista, but also the entire MSFT Office suite, 200 knowledge articles will no longer get you 60% results. So in my examination I had to make some decisions about how many knowledge domains we were actually supporting in a deployment. We have done deployments across multiple discrete knowledge domains that scaled into the thousands of answers, so this determination was an important one.

After all of the sorting, however, I did find some very interesting anecdotal information. Consistent with the MSFT results, we were able to determine that answering 60%, 70% or even 80%, of the questions about a domain had never taken us more than 200-400 questions. Often it was less. And even in more challenging deployments, the idea that 200 or so questions were doing the majority of the work seemed to hold.

Having concrete evidence that so much work is typically done by so few knowledge articles, even in technical domains, was a real revelation to me. I think that this evidence is actually critical to making good decisions about how to use knowledge in a support environment. I will talk about this more in my next article.

I was really struck by this sad example of online customer service. Obviously Company X was getting worst of both worlds in this case, with a poor self-service quality customer experience being provided at live assistance rates. A perfect nightmare. Yet they seemed to have all of the right elements in play to provide a reasonable experience. They had live agents, the gold standard for online customer service. And clearly they had some type of knowledge management system, one that appeared to include a number of shortcut answers. Maybe not the most advanced system, but certainly one that should provide at least competent results. It seemed to prove the old rule that no technology is going to be a success if it's implemented poorly. I had to wonder how these agents were being compensated, and what KPI's were being used to manage their contact center. It also made me curious whether the managers had any real reporting that would alert them to their situation.

Obviously no technology is fail-safe. In the end, as the old saying goes, "it's the Indian, not the arrow." But Company X always serves as a strong reminder to me of the importance of having all of the pieces in alignment. Management goals, Key Performance Indicators, and employee compensation all have to be set correctly. And vendors like ourselves have to provide as much insight as possible and as many levers as possible so that managers can see problems as they arise and correct course. We're all in this together if we want to create great customer service.

This is a very good question and one we have spent a lot of time discussing, both internally and with customers. Our view is, it's a good idea to start where you plan to end up. The ultimate decision should be made based on the customer experience that you are trying to create.

If you are planning to put in a self-service solution that will only escalate under very unusual circumstances, and will exhaust all possibilities of self-service first, you will probably need to heavily emphasize automation from the outset. This becomes unavoidable, because every question that the automation doesn't know becomes a failed customer experience. You will have to start with a "big bang" approach to the knowledge that you put into the system, and also optimize your automation very quickly once it goes live. It's the only way to avoid failures, poor customer experience and poor adoption. So, in this scenario you will need to start "big" with lots of knowledge, lots of planning and a whole bag of tricks. If you have the traffic to support this approach, and a real aversion to providing live support, it could be worth the investment in professional services to pull this off. But it's not what we usually recommend.

If your goal is to provide a level of service that is as good as or better than a stand-alone live chat solution, and you plan to commit agents to that experience, it's a no-brainer to start with a live, staffed solution. In this scenario you can start with little or even no automation, because people will be there to insure a good (albeit initially expensive) experience. Our recommendation would be to have at least the beginnings of some automation as well. By starting in this way you gain a number of very real advantages.

By watching the most common questions and best answers, the knowledge can be optimized rapidly, starting from day 1. Unlike the "automation first" model, you can see exactly how well the system is performing and make your own decisions as to whether more automation would be useful. You're seeing the actual questions that your customers are asking, so there's no mystery. No need to overbuild or attempt a "big bang."