Voice of the Customer for Service Design – Are you Getting It … Really?
We have just finished working with a large international services company which has had challenges rolling out new services. The most difficult aspect of their business was in discovering the real customer requirements, and converting those requirements into service requirements and, ultimately, a service design. Like many service companies, they just have an immature process for this.
The service design team is essentially the sales team. They get multiple voices from many parts of both their organization and the client. It is literally a cacophony of noise which, when converted to a service, the service process map looks like a Rorschach image. It is then launched for the bugs to be worked out as the service is being delivered. The rework is expensive, taxes the companys employees, and rarely produces a happy customer.
To help them, we built a Voice of the Customer (VOC) Maturity Model with laddered capabilities for them to climb. That model was built on some basic premises and observations after working with service companies for many, many engagements over the course of my entire career. Let me lay these out to you so you understand our final recommendation to any service company struggling with the same problem.
a short Powerpoint presentation that describes a 5-stage Voice of the Customer (VOC) Maturity Model
First, there are two aspects to VOC getting it and using it. They are very different. And there are two basic ways to Get VOC: 1) directly from the customer, and 2) indirectly from all your companys customer facing team members.
Our experience has been that companies are better at using what information they have than in getting good information. Further, that what they do to get the information often relies on customer facing team members as surrogates for the customer. One thing is for sure, while only a small fraction of companies that use it well get it well, almost none of them that manage the information get good information. Why?
I think this is true because after crashing a few launches, companies suffer enough pain to cause them to start gathering information. Then as they develop the disciplines in using it, they discover it isnt very good and they need better information. So until they try to use it, they dont start improving the quality of the information gathered. Just as an aside, along with discovering they arent getting good information, they often discover they arent getting the right information as the system focuses on product specifications rather than customer requirements. So the learning curve goes from we need information to . we need good information to . we need the right information.
As a company goes through this discovery process, they have to overcome some assumptions that are being taken as truths, and are really holding them back from progressing. Why does this happen?
- The assumption that customers dont really know what they need.
- Information is gathered once at the beginning by simply asking customers what they want.
- They only gather information from surrogates.
- They only gathering information from their best relationships (often happy customers).
These are the traps that get you stuck in bad information and more rework. To overcome these traps, information must be gathered both directly and indirectly. The information gathered must be prospective and from a broad population. And gathering and incorporating information must be continuous, NOT a one-time event.
Needless to say, the process isnt easy and requires a significant effort. But the payoff is a multiple of the effort. There is no doubt that companies that have structured processes for gathering and converting customer information outperform companies that dont, regardless of whether they do it well or not. Working with a plan, even if not perfect, outperforms no plan. And needless to say, if your plan and execution are done well, then your company performs even better.
Take a look at the summary presentation of what we recommended. If you have any experiences, comments or questions youd like to share, let me know at firstname.lastname@example.org. And by the way, while this is all written based upon an experience with a B2B service organization, it is equally applicable to internal processes such as a Shared Services organization providing a service to operating units.