TrainingConferencesAbout UsContact UsAdvertiseSQE.comRSS Feed

StickyMinds.com: brain food for building better software

Log In
 Clarify Your Search Criteria

Tips on Using Our Search Feature(s)
 
StickyMinds.com Home
ResourcesTopicsCommunityPowerPassBlogs
Home  >  Detail: How Not to Create Customer Satisfaction



A StickyMinds.com Original
Article Picture
How Not to Create Customer Satisfaction

By Naomi Karten

Send This Content to a FriendGet a Short Link to This ContentPrint This ContentSee User Comments About This Content

Summary: Given a choice, most people would rather have happy, satisfied customers than angry, complaining customers. But how to create customer satisfaction is sometimes a mystery. In this week's column, Naomi Karten describes one person's experience that backfired and taught him some lessons.


TechExcel, Inc.
During one of my seminars, we were discussing experiences people had in striving to create customer satisfaction. Striving might have been just the right word, because as reported by Josh, a seminar participant, you can strive and still not succeed. As Josh described it, in reviewing his customers' specs, he saw a way to give them something much better than what they had asked for. So he proceeded to build his own grand solution.

One minor detail: He didn't let his customers know he was doing this.

In listening to Josh, I sensed that as he developed this solution, he was pleased with himself for his insight, creativity, and initiative. And his customers would, of course, be pleased with him as well. But when he presented his solution to Ginny, his key customer contact, she rejected it outright. "It's not what we asked for," she told him. End of discussion.

"Why even bother trying to please them?" Josh asked, agitatedly. "You go above and beyond and they're still not happy."

But might there have been some other explanation for Ginny's reaction? As quickly as I asked the group what they thought, several possibilities surfaced as to why the customer rejected his solution.

One possibility concerns surprises. Namely that many people don't like them. When suddenly confronted by something other than what they were expecting, they may reject it, belittle it, or find fault with it. I can almost imagine Ginny shouting, "You what?" If customers ask for A, and with no advance notice you deliver B, don't expect them to jump up and down with glee.

A related possibility is that of wanting to be involved in key decisions. Often it's not the solution that customers reject, but rather the fact that they had no say in its formulation. Not having had a chance to provide input, they may react negatively to a solution they might otherwise have welcomed. At that point, even the most compelling benefits may not make a difference; rejecting a superior solution delivered unexpectedly is an emotional response, not a logical one.

Clearly, Josh would have been much wiser to describe his solution to his customers before proceeding. At that stage, he could have presented it as an idea, not a done deal. He might have offered it as a proposal and sought their opinion. He could have cited the benefits they hoped to achieve and shown how his solution could go even further in achieving those same benefits. Under these circumstances, his customers might have loved his idea and given him their go-ahead.

But even if they still favored Plan A, they might have been impressed with his initiative. Furthermore, by accepting their preference for the original plan, he would have shown himself to be flexible and easy to work with, factors that could enhance his reputation.

As Josh listened to this discussion, he started to realize that focusing single-mindedly on the project while ignoring his customers' perceptions, preferences, and expectations was not a route to customer satisfaction. But we were just warming up; there were many other explanations that might have accounted for Ginny’s rejecting his solution. For example:
  • Ginny may have been acting on orders from her manager. "Here's the system we need; now go make it happen." In that case, the expectations to be met would not have been Ginny's, but her manager's. Even if Josh's solution appealed to Ginny, she may not have been in a position to approve it if her next performance review was to be based on how well she carried out her manager's mandate.
  • Ginny may have been trying to recover from falling short in past projects. Perhaps, her manager's confidence in her abilities had decreased as a result of these past failures. This time around, she knew she had to get the project done right or else—and "right" meant to exact specifications. The direction of Ginny’s career path might have been at risk if she didn't carry out the project as stated.
  • Josh's solution may have missed some elements that were critical to what the customers wanted. Regardless of how spectacular his solution may have been, it may have focused on certain functionality that excluded other functionality that was a higher priority for the customer. If Josh had taken the customer's priorities into account in his "better" solution, he might have won his customers over even if the solution diverged from their specifications.
  • Josh may have done a mediocre job of describing his solution to Ginny. Maybe his explanation was too abstract. Maybe, in his enthusiasm, he omitted relevant details. Maybe he neglected to mention benefits. Maybe he garbled the facts. Maybe he gushed. Very likely, he didn't give nearly as much thought to how he would describe his solution as he did to creating it in the first place.
The end result: Instead of being seen as doing something extra for his customers, Josh may have planted the seeds of doubt in their minds. They now had cause to wonder whether he could be trusted in future projects or if he'd again take matters into his own hands. And he still had work to do on this current project, such as starting over and meeting the original commitment.

Of course, even if Josh had gotten his customers' approval for his solution, he still might have faced challenges. Invariably, exceeding customer expectations has both benefits and potential pitfalls. If you complete a project in a way that exceeds customers' expectations, they may be delighted. But they may expect you to do the same next time around and each subsequent time after that. If you then complete these projects exactly as promised, they may be disappointed. After all, you've already demonstrated that you're capable of going beyond what you promised. So, the very process of raising customer satisfaction can result in subsequently lowering it below where it was to start with.

I'd rarely discourage anyone from striving to exceed expectations if they were eager to do so. But I'd strongly suggest that they consider the potential consequences and plan accordingly. Hopefully, Josh, now more aware of the consequences of his actions, will have many opportunities to strive conscientiously to create customer satisfaction.


About the Author
Naomi Karten (www.nkarten.com) is the author of numerous books and ebooks, including Communication Gaps and How to Close Them and Managing Expectations, as well as her popular newsletter, Perceptions & Realities. As a highly experienced seminar leader and speaker, she draws from her psychology and IT background to help organizations improve customer satisfaction, manage change, and strengthen teamwork. She has delivered seminars and presentations to more than 100,000 people all over the US, Canada, and Europe, as well as Tokyo and Hong Kong. She would enjoy hearing from you at naomi@nkarten.com.

Back to Top
 

StickyMinds.com Weekly Column From 5/21/2007 

Member Comments
Add Your CommentExpand Comments
 
Comment:    
by Robert Cowham 5/27/2007

Just to reinforce the other comments on communication:

A large part of Agile development methods is about increasing feedback - the longer you wait before getting feedback the more chance you have of diverging from what the customer wants (or as importantly from what they actually want which they didn't realise isn't what they specified!).

Thus keep close to your customer and get them involved all the way through to minimise surprises on both sides...

Author's Response:
5/28/2007    
Hi Robert. Feedback-gathering is so important, and you are right -- Agile methods are highly conducive to gathering that feedback sooner rather than later (or not at all). People are sometimes reluctant to check in with customers too often, but it’s just the opposite, avoiding or delaying contact with them, that leads to trouble.

 
 
Comment:    
by Grant Bellamy 5/25/2007

Good article. I support the concept from the reader who stated it is a social activity. It is. Any software development project must involve the client from beginning to end. Especially in design where it must be an iterative process.

Developing software is not rocket science and if you learn to involve the 'user' in the process you will avoid: budget overrun, disapointment, poor quality, loss of future revenue, etc.

Author's Response:
5/25/2007    
Grant, thanks. I’m really pleased by your emphasis, and Wayne’s, on viewing software development as a social activity. A focus on communication and user involvement will steer development in the right direction, even when formal methodologies are not in use.

 
 
Comment:    
by Wayne Mack 5/24/2007

To reinforce the point, we need to remember that design is as much a social activity as a technical activity. Even though Josh may have created a solid technical solution, by going silent, he created anxiety with the customer. When the design was unveiled and differed from client expectations, I would expect the client to be concerned, no matter how good the technical solution might be. The initial reaction was going to be, "We spent this time and money and this is what he came up with?" There is no way the technical solution could have been given a fair evaluation.

The solution, as always, is communicate, communicate,...Read On

Author's Response:
5/24/2007    
Hi Wayne. Design as a social activity. Yes, absolutely, this is a great point – one that deserves an article of its own. (Perhaps you will write it????) And you are right on target about the importance of communication not just when things are going as planned, but also (and especially) when they are not. Thanks for your comments.

 
 
Comment:    
by MG Hariharan 5/22/2007

I could add some more to this confusion. Quality is not defined. That is why CMM and ISO 9000 etc ask you to define the quality Policy etc. The section where Josh bungled was in assuming the customers needs. In CMMi now they explicitly define the Process as RD where you gather the customers Needs( not requirements) understands the constraints and compulsions of the customer then come out with specifications which define the customers requirements and then only proceed. Another mistake that Josh did was Gold plating the Requirements ( If it was according to him better than the Original design)- strictly prohibited as it becomes costlier and...Read On

Author's Response:
5/22/2007    
MG, as you noted, CMM and ISO 9000 would have avoided Josh’s experience. But even though Josh's organization was deficient in its processes, a thought he might have kept in mind is that if something happens in interacting with customers that is other than expected, it’s advisable not to immediately blame the customers. Instead, start by looking within and asking, What might we have done (or failed to do) that led to this result?

 
 
Comment:    
by Robert Rose-Coutre 5/21/2007

Hi Naomi, I am wondering if/how QA and the test team were allowed to interact with development during Josh's project. The developer would normally follow the QA-authored requirements documents. Any suggested change or addition in requirements would typically trigger a meeting or conversation with the customer. It sounds like Josh is with a very small development shop where there isn't an established process. But even then, a chat with the customer should be a reflex when "extra-requirements" development is contemplated. There could be many reasons the company wouldn't want non-specified features or functionality, even if it appears to make...Read On

Author's Response:
5/21/2007    
Robert, hi! I agree with you. At minimum, a chat with the customer should be automatic in situations like this one – if not a full-scale meeting with a presentation/discussion of the proposed solution. In Josh’s organization, the processes were inadequate but a little common sense might have sufficed in this case. Your point about customers having bad experiences with consultants is an excellent addition to the list of possible reasons that the customer rejected his solution.

 
 
Comment:    
by Sanat Sharma 5/21/2007

Naomi, I only believe in quality and according to my analysis, Customer satisfaction is quality. I memorize when I was working for one of my telecom client. We got the requirement from the customer and we develop a solution after working 6 months on it. When we showed it to them, they said this is not the thing that we want from you. We all were shocked and we re-worked again.

I believe that Customer Satisfaction (or quality) means:
Presence of the features, components, functionalities which customer wants and absence of features, components, functionalities which customer doesn’t want.

Customer satisfaction =...Read On

Author's Response:
5/21/2007    
Thanks for your comment, Sanat You make a good point that customer satisfaction should include what the customers want AND exclude what they don’t want. It’s easy to fall into the trap of thinking that by going above and beyond, customers will be even happier. Sometimes, they will, but it’s not a given.





 
Back to Top



 
Ads By Google
What's This?
 
 



Home   |   Resources   |   Topics   |   Community   |   PowerPass



© 2010 StickyMinds.com. All rights reserved.
StickyMinds.com is a division of Software Quality Engineering.
Privacy Policy    Terms & Conditions    Link to StickyMinds.com    Feedback


MicroFocus




STAREAST 2010 


Better Software Conference