We’re going to start this voice of the customer analysis with a disclaimer pointing out that this is in fact not a fun topic, or one you can say anything definite about. The truth is, on top of being the most obnoxious buzzword ever created, even the kernel of truth behind it is semantically irritating as well.

It Sounds Silly, What is It:

Well, voice of the customer analysis is, when you shed the buzzword and convolution, the analysis of all feedback from customers. This data comes from many sources, like BI analytics off of social network monitoring, forums, email, surveys and other such things.

This has commonly been called “feedback analysis”, or “customer input”. Voice of the customer is some grandiose term assigned to this sort of data acquisition and analysis in recent times.

Nothing New:

Just as this concept isn’t new (only the buzzword part is), the same problems always inherent in this sort of data persist as well. This kind of data, from people, isn’t hard data. It’s filtered through abstraction of human language and expression, and isn’t computational.

Unless the survey forms and the like are rigorous and tedious limited questions and multiple choice, it’s just not going to be easy to use automata to process this incoming data.

The result of this is that traditionally, you’re stuck having to use people to go through all this input, and deductively get computational information out of it for more conventional automata to handle. There’s some significant loss along the way.

Possible Solution:

The possible solution to overcoming noncomputational data like this would be to use some clever programming and implementation of an actually old science. The regular expression is a shorthand expressionary protocol used to match text without literal character analysis. Basically, gray area analysis of text.

With some clever analysis of existing customer input, smart people could design a lot of these patterns to determine requests, complaints and compliments provided by all of this fuzzy data.

This is only theory, and undoubtedly will need compromise in rules about how to write what you have to say in some cases.

Data Priorities:

Now, the thing above all that is, you also get buried in a lot of extraneous input along the way as well. So, you have to prioritize this information, and spend some time dismissing absurd things even theoretical smart parsing can’t detect by itself.

People will request already present features, completely ridiculous and unrelated features, and some will be downright purposely stupid.

It’s the complaints about navigation and the like that you really need to listen to. Those, bug reports, and aesthetic claims. Don’t listen to UX data that isn’t obvious from customer perspective, because it’ll be completely unfounded.

See the problem with this kind of approach? Now, I’m not saying it doesn’t have its stints of usefulness, but it’s absolutely unwise to depend on it too much, because it’s extremely inefficient and in many ways, unreliable.

So, that’s my take on voice of the customer analysis, and I hope you walk away at least understanding it’s something you’ve seen before, the pros and cons of which have been discussed at length here and by many others as well.