Years ago, when I was selling communication equipment, I landed a plum sales call with a senior manager that could have represented a sizable sale. During a scouting trip prior to this call, I'd learned that his department was using outdated equipment, so I knew there was an underlying need for the equipment I was selling. If I could get him to see that need I'd be home free, I thought.
During the interview I followed the four-step sales approach that I'd been taught: Approach, Needs, Present, Close. After the opening conversation, I started questioning the manager about the problems and issues he encountered, and he acknowledged there was a serious problem with his department's current communication equipment.
That's when the old sales mantra kicked in: "identify customer needs and present a solution." I began talking about the high-end product I was selling, emphasizing its most popular features and benefits.
When I reached the end of my presentation, I naturally asked for the order. My prospect told me he needed some time. He said he would check his budget figures later in the week, and asked me to call him the following Monday.
I did follow up as he requested, but had trouble getting through. Eventually I learned from his assistant that he had bought a system from one of my competitors that had fewer bells and whistles.
What went wrong? It took me some time, but eventually I realized there was a fundamental flaw in my entire sales approach. I was "presenting" to the wrong customer needs.
During the meeting, I had gotten him to recognize the first need: the need to make a change. He recognized that there was a problem and came to believe it was in his best interests to pursue a new solution.
But as I began describing my product, he'd begun identifying different kinds of needs entirely: specific needs for a desired solution. As I was lauding the strengths of the communication equipment I was selling, my prospect was thinking, "Hmmm, which of these capabilities do I need? No, not feature A. Feature B looks interesting, but I'm not sure I would use it. Ooh, feature C would be nice. And, yep, I've got to have that feature D."
Ironically, by talking so soon in the sales process about my product, I'd helped educate this prospect about what he was looking for in a solution. He then used that education to shop around with my competitors and get a better deal around a product package that met only the solution requirements he'd identified.
This kind of mismatch between sales pitches and customer needs happens all the time in all kinds of sales, big and small. Salespeople rush to their pitch as soon as they see that a customer has recognized a need to change. But in doing so, they lose the opportunity to shape a pitch around what really matters to the customer: the solution requirements.
Just the other day, a friend told me that he'd recently decided to buy a new big screen TV. His initial need to make a change was driven by the remodeling of the family room in his house. As he began shopping around, the first salesperson was glad to be talking to a customer who was intent on buying a TV. But he made the same mistake I'd made—he began talking about all the latest, greatest features without stopping to ask my friend what criteria he would use to make the decision.
A second salesperson made the same mistake.
By the time my friend reached the third store, he'd learned so much about the features and characteristics of big screen TVs that he could describe what he wanted in detail to the third salesperson. He bought the TV there, not because the salesperson was better but because he was very clear about his solution requirements.
The next time you're on a sales call and hear a customer express a need to make a change, SLOW DOWN. Do not jump into your pitch. Begin exploring the customer's needs in more detail. Ask them, "What does the ideal solution look like to you? What factors will be most important in making your decision? What's next most important?"
Only make your pitch when you know for sure that you understand all of your customers solution requirements and can link them clearly to your solution's differentiators.
Thanks to Kevin Davis / OpenForum