Quality in Practice: Improving Customer Satisfaction at a Software Support Call
Centeri
This case study describes how one company improved customer satisfaction statistics at a
software support call center by 43% in one month in an industry where the monthly norm
is a low single digit percentage. The company, which provides technical support
services to software publishing companies, had managed to slowly improve customer sat-
isfaction figures over a three-year period. The improvement had occurred through efforts
initiated by management to implement common sense business practices such as con-
Facing a potential disaster, management formed committees of technical support staff
and asked them for suggestions. The results were initially discouraging. Suggestions only
mirrored those already thought of by management. The logjam was broken when
someone discovered the work of Gary Klein.ii Klein specializes in the anatomy of expert
decision making with the aim of developing ways to speed up the training process. He
reasons that experts in high-pressure emergency occupations are often unable to explain
explain their reasons for success in making good instant decisions. The company
carefully analyzed calls, looking for patterns that would explain the success of the most
successful support engineers. Once they could effectively describe these patterns to the
non-expert support engineers, they were able to improve their customer satisfaction
ratings quickly.
They began by interviewing experts in a department that supported a popular word
processing package. They could do no better than management in suggesting new
The suggestions in the first group rested on one basic assumption: Since the customer’s
objective is to get the right answer, technicians could produce satisfied customers by
simply giving the right answer. This assumption seemed reasonable because all
technicians could recall certain types of problems that could be resolved instantaneously,
and customers were always very satisfied with these calls. There were, however, three
problems with this solution:
1. Some technicians of below average technical ability nevertheless consistently earned
high customer satisfaction ratings. Even more puzzling, some technicians earned high
2. Customers frequently gave low satisfaction ratings despite the fact that they received
the correct answer. Take, for example, Joe, a technically competent support engineer
who solved a customer’s problem with a complex development software product in 10
minutes. This was excellent service for the level of complexity involved, yet the cus-
tomer complained that the service was inadequate because “it took too long.”
3. Even with the best training, most technicians need some experience with
troubleshooting before they can give correct answers. Beginners, then, will always
The company concluded, that although the correct answer could be important under
certain conditions, another factor seemed to be involved — the personal factor. These
suggestions assumed that the technician did something on a personal level; such as using
a particular tone of voice or a friendly greeting that satisfied the customer. One
be treated,” “Smile because a customer can hear your smile” and “Don’t say no.” These
types of guidelines and suggestions comprised 60% of the procedures listed in the
employee manual. Yet these apparently did little for customer satisfaction ratings.
In the ensuing research, 20 engineers responsible for supporting a well-known word
processing package were chosen out of 200. Were divided into two groups — experts and
sub-experts. The first group was comprised of those engineers who achieved an average
customer satisfaction rating of greater than 74 percent during a six-month period. The
second group achieved ratings below 75% during the same period. The company taped
and analyzed two support calls per engineer. Because the engineers were not chosen
randomly, the focus was not on gathering a statistically significant sample, but trying to
The greatest surprise was discovering how little the personal factor counted. They
found that those experts who do establish a more personal relationship fare no better than
those who do not. One engineer acted almost robotic while another took every
opportunity to use the customer’s name in an effort to be more personal. Yet these
differences did not affect the ratings. It seemed that short of openly obnoxious behavior,
the personal dimension was irrelevant. This result surprised us until they thought about it
further. It appears that the customer seeking help for a technical problem has no reason to
When following the transparency principle, the expert support engineer signals
throughout the call that he or she is constantly applying troubleshooting skills to the
customer’s problem. Some of these signals are obvious –restating the problem in the
beginning, asking questions to clarify the problem, and giving explanations. Some are
less obvious — admitting that a wrong course of action has been recommended, or simply
grunting something like “uh huh” instead of restating the entire problem initially. This
method is simple but powerful – so powerful in fact, that when it is properly executed,
Although simple in principle, this method is more complex in practice. Following is
an example of how it~ works when the engineer must probe a moderate amount to find a
solution for a caller.
Stage 1- Immediate establishment of status of engineer as a problem solver and expert.
The expert engineer communicates that he or she understands the-problem the customer
is describing. The standard previously set by management was that the engineer should
explicitly restate the problem. Only about half the experts in this study did this con-
sistently. The other half simply issued a series of uh huhs. The important thing is for the
engineer to issue audible signals as evidence of paying attention to the customer’s words.
This technique may present a problem for the beginner who encounters a particularly
Stage 2: Initiating the troubleshooting. After completing Stage 1, the engineer must
quickly show evidence of mental activity directed toward problem resolution. There are
several ways to indicate this activity, and the engineer may use any combination of them:
1. The engineer asks the customer to do a series of operations on his or her computer. The
aloud. The engineer then issues the commands. This sets the expectation that he or she
might have a solution.
4. The engineer cannot think of a way to attack the problem and must consult information
databases or other technicians. He or she apprises the customer of this so the customer
understands the reason for the long silence. If Stage 2 leads to a solution, the call
produces a satisfied customer. If not, Stage 3 begins.
Stage 3 Open admission of a wrong hypothesis. The engineer immediately shows he or
she is working on finding another strategy by recycling through a variation of Stage 2.
The research showed that the difference between the expert and subexpert groups in
Joe, the support engineer mentioned previously, exemplified this improvement.
Despite his expertise as an engineer, at least 20% of the surveyed customers gave him a
low rating. After learning about transparency, he realized where he went wrong.
Whenever Joe put a customer on hold to research a problem, he did not apprise him or
Key Issues for Discussion
1. What does this case suggest about the importance of understanding customers’ true
needs and expectations?
2. What are the implications of the “transparency principle”?
3. The concept of studying the best people in an organization as a method of learning to
improve others’ skills has long been advocated by Joseph Juran. How might the
learning from this case be applied to other organizations?