Solutions selling starts with a customer’s problem and works towards an offer that can address it. The salesperson needs to understand the situation before recommending a product, service or combination of the two.
The approach is useful when the buyer needs to compare possible ways to achieve an outcome. It still requires clear product knowledge and evidence. Calling an offer a solution does not establish that it fits the customer’s needs.
Begin with what the customer already knows
Ask what prompted the discussion, what the customer has investigated and which alternatives they are considering. They may have a well-defined requirement or may still be deciding whether to make a change.
Do not repeat a long discovery routine simply because it is part of your process. Explain what you need to understand and why it affects the recommendation.
Check the problem and its importance
Ask for a recent example of the problem. Find out who it affects, how it is handled today and what happens if nothing changes. Separate the customer’s observations from your interpretation.
Then clarify the decision. Who needs to contribute, what criteria will they use and what constraints must the offer meet? Missing information is a question to investigate, not a reason to invent a confident qualification score.
A problem can be real without being a buying priority. Confirm whether the customer wants to address it now and what would justify the effort.
Design an offer you can deliver
Map each proposed element to a confirmed requirement. Explain which parts are standard, which need configuration and which depend on work by the customer or another party.
Check the scope with delivery colleagues before making a commitment. Include the responsibilities, assumptions and exclusions that affect the outcome. More components do not necessarily make the solution better.
If the requirement falls outside your capabilities, state the limitation. A smaller scope or a decision not to proceed may be more appropriate than a proposal built on an untested promise.
Use evidence to discuss value
Demonstrate the relevant workflow and explain how it addresses the requirement. Use real, approved customer examples where they support the comparison. Identify differences that limit what the example proves.
For a financial estimate, show the inputs and assumptions. Ask the customer to check them. An estimated benefit is not an achieved result, and a projected saving may depend on changes beyond your product.
A solutions selling example
Consider a fictional distributor whose sales team cannot reliably confirm stock before accepting an order. The initial request is for a new CRM.
Discovery shows that stock reservations are recorded in a separate system and updated late. The proposed approach therefore needs to address the information flow and the responsibility for maintaining it. A new CRM alone may leave the problem unchanged.
The salesperson and customer agree which information must be available, when it must update and how they will test the workflow. They then compare the options against those requirements. The example illustrates the reasoning; it does not show that one software choice is always correct.
Make the handover part of the sale
Before agreement, confirm what the customer is accepting and what remains unresolved. Pass the requirements, decisions and commitments to the people responsible for implementation.
After delivery, review the outcome against the agreed measures. If the result differs from the expectation, examine the cause rather than treating contract signature as the end of the work.
Review how the team applies the approach
In a pipeline review, ask how the proposal relates to the customer’s evidence. Check for unconfirmed assumptions, unnecessary scope and promises that delivery has not accepted.
Start with a real opportunity where the proposed offer and the customer’s requirements do not yet line up. Identify what needs to be confirmed before the proposal can move forward.
