Steven Spielberg’s 2002 movie, Minority Report, starring Tom Cruise, presents a world in which homicides are prevented before they happen. Three precognitives’ visions of near future events allow the Department of Precrime to capture these intended killers. Neat idea. If only we in the business world could spot product quality “crimes” before they occur — rather than reacting to problems once customers use our products. Product designers and product managers are tasked with projecting the future, but is there an organizational equivalent for Agatha, the precog who sometimes saw the future differently from her mates, Arthur and Dashiell? Also published in the April 28, 2003 edition of the Boston Business Journal.
A synopsis of Dr. Fred Van Bennekom’s research in this area.
If you have attended recent conferences in the customer support industry, you have probably been amazed at the number of products developed for our industry. Each conference brings a new technology vendor with a product addressing a particular problem area. Knowledge bases codify existing product information eliminating the need to reinvent the wheel. Call management systems direct and manage our human resources. Expert systems isolate relevant knowledge more quickly. Fax-back systems and web-based knowledge tools deliver answers to customers with no human interaction on our part. The list goes on… But step back for a moment and examine the goal of these products: their aim is almost solely to improve the efficiency of delivering support to our customers.
Am I some Luddite who is arguing against technology and the efficiency it can bring? Of course not. But it is a useful exercise to question the underlying assumptions of the paradigm from which we are working. Does more efficient rectification of customer problems increase a company’s long term effectiveness? Is efficient problem rectification the best way for support to increase a company’s competitiveness?
To answer these questions, ask your customers to describe the ideal state when they use information technologies. While some may say they want fast, accurate resolution of problems, most will prefer problem-free product use. A truly effective support organization will help achieve the latter objective. That means preventing as many problems as possible before they ever happen.
A problem prevention paradigm requires a changed mindset. One’s planning horizon now must be longer term. Interaction with customers becomes an opportunity to scout for valuable information about product quality issues rather than a costly transaction to minimize. The definition of one’s customers must now include internal groups, such as product engineering, and the support group’s product expands to include capturing data and providing advice to these internal customers. Management’s focus on controlling support costs or expanding service revenues must be augmented with identifying and exploiting synergies within the company. The support group’s mission evolves from managing the end of the value-added supply chain to a strategic partnership throughout the value-added chain.
The pay back on these prevention activities will be hard to isolate and even harder to measure. You might ask if there even is a payoff! In a recent research study, I examined the impact of customer support’s contributions to product quality improvement. I found that support cost per customer over successive product releases decreased far more rapidly — by about 20% faster — when customer support was an active participant throughout the product development process. And the customer received a higher quality product!
Implementing the problem prevention paradigm was a long and difficult change management process, and each company’s support organization followed different paths. However, the rewards reaped were well worth the effort: a more challenging, rewarding, dynamic, and effective professional organization.
For information about a major research report on best practices in Design for Supportability, follow this link. You can request a complimentary copy of Chapter 1 of that report.