During demos, there
is inherent risk anytime you introduce capabilities that the customer has not
yet requested – and, in particular, the level of risk depends greatly on how the capabilities are
introduced. The “So What” tactic
presumes that the customer will want or need the capability being introduced –
and there’s the risk.
An Example:
Feature
Statement: “We provide support for the
software in 22 languages…”
So What
Statement: “We provide support for the
software in 22 languages, so that your team can access the software anywhere in
the world using their native languages…”
The Risk: The customer says, “Everyone in our company
speaks English and we want to make sure that all information is captured
consistently in the system, so that everyone can access all information equally
– without having to learn 21 other languages…”
The Additional
Risk: The customer adds, “…and we don’t
want to pay for the additional 21 languages, since we won’t be using them – so
either take out the support for those languages for our implementation or
reduce your price accordingly…”
Another Example:
Feature
Statement: “Alerts can be automatically
generated and sent to you via email…”
So What
Statement: “Alerts can be automatically
generated and sent to you via email, so that can be notified of any problems
right away…”
The Risk: The customer says, “I hate email. I get way too much already and I’m always
spending too much time deleting messages – I’d be concerned that I’d delete the
alerts, thinking they might be spam. I’d
rather simply login to your system periodically…”
The Additional
Risk: The customer adds, “…and I don’t
want to pay for the email alert functionality, since I won’t be using it – so
either take it out or give me a discount…”
Same Example, Even Worse:
Feature Statement and Demo: “Alerts can be automatically generated and sent to you via email – here, let me show you how this can be done in the software…”
So What Statement
and Demo: “Alerts can be automatically
generated and sent to you via email, so that you can be notified of any
problems right away – here, let me show you how this can be set up and done with the software…”
The Risk: The customer says, “I hate email. I get way too much already and I’m always
spending too much time deleting messages – I’d be concerned that I’d delete the
alerts, thinking they might be spam. I’d
rather simply login to your system periodically…”
The Additional
Risk: The customer adds, “In addition,
that looks really complicated and confusing – too many features and functions
to remember. I think we’ll go with your
competition, whose software was much more aligned with exactly what we need…!”
Solutions
The best
solution? Introduce your capabilities
via questions in Discovery, well
before a demo. Once you’ve either
uncovered a need (and the customer confirms their desire to have the
capability), then presenting that specific capability in your demo can be done
as a benefit statement.
Michael Bosworth,
in his sales methodologies Solution
Selling and CustomerCentric Selling,
outlined the idea of Feature, Advantage, Benefit statements – simplified here:
Features: are the description of the what the feature
does
Advantages: are why it might be good for the customer
Benefits: are why it will be good for the customer, based on the customer’s previous
statements (e.g., from Discovery sessions)
This difference
between an Advantage (presumed benefit)
and a real Benefit (confirmed
benefit) can be huge!
Revisiting
Example 1
With this in mind, we might have a different conversation and result:
Feature
Statement: “We provide support for the
software in 22 languages…”
Advantage (So
What) Statement: “We provide support for
the software in 22 languages, so that your team can access the software
anywhere in the world using their native languages…”
Benefit
Statement: “You had mentioned that you
need support for 5 languages so that your team can access the software anywhere
in the world using their local native languages – we do support all five of
those languages as part of our standard offering.”
The win: The customer says, “That’s terrific – that’s
exactly what we need. Interestingly, one
of your competitors said they support a pile of languages, but we didn’t want
to pay for all of those extra capabilities since we’ll never use them…”
An alternative approach, based on what were benefits for other similar customers, is called a Biased Question – see my article, “Competitive Demo Situations – Biasing Towards Your Strengths” for further information on this idea (send me an email at PCohan@SecondDerivative.com and I’d be happy to send you the article).
No comments:
Post a Comment