Solution selling means diagnosing the buyer’s problem before you propose anything, and then proposing only what answers it.
In a CRM that comes down to three records on the deal, written at three different moments: the problem in the buyer’s words with its cause, the impact of that problem and who on their side agreed to it, and a line that ties each named problem to the part of your offer that answers it. If the first two are empty when the proposal goes out, the deal has a catalog pitch, not a solution.
The guides we read while preparing this, Gong’s above all, explain the method well and give the steps for the conversation. What none of them says is what should be sitting in the deal record when the conversation is over, or how a manager tells a proposal built on a diagnosis from one built on the price list. On a deal review the question is never “did you ask good questions”. It is “show me where it says so”.
Solution selling starts with the diagnosis
Gong lays solution selling out in five steps: know your product, ask questions, qualify, propose the solution, close. The diagnostic part sits in the middle, and Gong splits it into three phases: find the reasons behind the problem, explore its impact, and only then help the buyer picture what becomes possible (Gong, Solution selling). That order is the whole method. Everything else is detail.
The difference between product selling and solution selling is where the rep starts: product selling starts at the catalog and looks for a buyer who might fit, solution selling starts at the buyer’s problem and looks for the part of the catalog that fits it. A rep who sells from the catalog can still ask questions, often good ones. The proposal still lists every module, because that is what the template has on it. Solution selling also means admitting that some parts of your product don’t fit this buyer at all.
There is a registered training program that carries the name, and Gong’s page points to it; we are writing about the everyday method, not the course.
It helps to keep it apart from its neighbors too, because the three records below are not a rebrand of things we have already published. SPIN selling is about the questions and their order, and Gong’s own comparison puts the difference in who draws the conclusion: in SPIN the buyer connects the dots, in solution selling the rep shows the fit. Consultative selling is a stance more than a sequence. The rep acts as an advisor and may end up recommending nothing at all, while solution selling assumes there is a solution to propose and cares about how tightly the proposal follows the diagnosis. Gap selling measures the distance between the buyer’s current and future state; here the interest is narrower, in which part of the offer closes which problem. Value selling adds the number the buyer will defend internally.
Solution selling has a failure mode of it’s own. The diagnosis happens, the rep even writes it down, and the proposal lists everything anyway. The records in the next section exist to catch exactly that gap between what was diagnosed and what was proposed. The same logic applies to conceptual selling, which we cover as its own set of CRM fields.
What lands in the deal, stage by stage
Three records, three moments. We describe them as field types rather than CRM settings on purpose; the mechanics differ between Pipedrive, HubSpot, Salesforce and Zoho CRM, and the method does not.
-
After discovery: the problem and its cause. One long text field. The first half is the buyer’s sentence, as close to verbatim as the rep can manage, with a name and a consequence in it. The second half is the cause the diagnosis turned up, which is the piece most notes skip. “Dispatch calls every technician twice a day to find out where he is” is a problem. “Because the day’s schedule is a photo of a whiteboard sent at 7 am, and two technicians share one van calendar” is a cause. Gong’s first diagnostic phase is about reasons for a good reason: a proposal written against a symptom treats the symptom. A proposal written against the cause can be checked against it later, by the buyer and by you. If the cause half is blank after discovery, discovery is not finished, whatever the stage column says.
-
Before the proposal: the impact, and who agreed to it. A number field, a short select for the unit (hours per week, jobs per week, dollars per month), and a short text field for the person who said it or nodded at it, with their role. If you already keep a value case on your deals, this is the same number. Don’t add a second field. One number, one owner.
-
With the proposal: problem to solution element. A long text field, one line per pair. The left side quotes a problem from record 1. The right side names the part of your offer that answers it: a module, a plan tier, a service hour, a configuration. Then one more line, “Not proposed”, listing what is in your catalog and deliberately left out of this deal because no named problem calls for it. This is the record no guide we read asks for, and it is the one that proves solution selling happened rather than a long discovery followed by the usual deck. A right-hand side with no left-hand side is a catalog line, and it should be visible as one.
The rule that goes with the records is short: a proposal does not go out while record 1 or record 2 is empty, and record 3 goes out with it. Whether your CRM can block a stage move on an empty field depends on the CRM and the plan. We covered how required fields behave in Pipedrive, and the same idea shows up as stage exit criteria in Salesforce. If your CRM can’t enforce it, a saved view of “stage is Proposal and record 2 is empty” does the job by hand.
One more consequence, for the forecast. A deal in the Proposal stage with records 1 and 2 blank is not at the proposal stage. It is a qualified deal with a document attached. Count it that way in the forecast call and reps learn quickly that the fastest route into the committed column runs through two fields.
A proposal built on a diagnosis, and one that wasn’t
The example below is invented. Harbor Mechanical is an HVAC contractor with six technicians; the seller offers field-service software with scheduling, dispatch, invoicing and a customer portal. Two reps, two deals, same product.
Deal A
Problem and cause: “Dispatch calls every tech twice a day to find out where he is, and we still double-book Fridays.” (Priya, operations manager.) Cause: schedule is a whiteboard photo sent at 7 am; two techs share one van calendar.
Impact: 4 jobs per week double-booked or late. Agreed by Priya on the second call.
Problem to solution element: Double-booked Fridays, shared calendar -> scheduling with per-technician availability. Dispatch calling twice a day -> live technician location on the dispatcher board. Not proposed: invoicing module, customer portal (no named problem).
Deal B
Problem and cause: “Looking to modernize dispatch and scheduling.”
Impact: (empty)
Problem to solution element: Full platform: scheduling, dispatch, invoicing, customer portal.
Read the right-hand column of record 3 first, because that is where the difference is loudest. Deal A proposes two things and names two it leaves out. Deal B proposes four things and names no problem for any of them.
Then read record 1. Deal B’s sentence could be pasted into any dispatch software deal in the pipeline without a single edit, which is the surest sign it came from the rep and not the buyer. And the impact row is empty, so nobody at Harbor has said what the mess costs them, which means nobody at Harbor is on the hook for fixing it.
Deal B might still close. Buyers do sometimes sign the full platform. But you can’t tell the two deals apart from the proposals, which probably look alike, or from the stage, which is the same. You can tell them apart from the record before you’d finish opening the proposal PDF, and that is the point of having one.
Five minutes on a Monday
Here is how we’d run the check, and it does fit in five minutes if you take two or three deals rather than the whole pipeline. Pull the deals that entered the Proposal stage this week. For each one, read record 1 aloud and ask whether the buyer would recognize the sentence as thier own. Then run your finger down record 3: every left-hand side should appear in record 1, and anything on the right with no left is a catalog line, so ask the rep why it is there. The answer is sometimes good (“they asked for it on the demo”), in which case it goes into record 1 as a problem the buyer named. Often the answer is “it’s in the standard package”, and then it comes out of the proposal or the deal gets a smaller number.
If record 2 is empty, the conversation is shorter. The proposal should not have gone out, the deal moves back one stage, and the rep books one activity whose only purpose is the impact question. Moving a deal back is is unpopular the first time. It is also the moment the pipeline report starts telling the truth, and that report is what you run the business on.
We build SalesBond, a sales management layer on top of the CRM a team already uses; we started with Pipedrive. Deal Health checks every deal against more than 20 rules and shows which deals need attention and why. It does not read your diagnosis records. That check stays with the manager and the five minutes above, and the routine checks are what Deal Health takes off your plate. Check your CRM with SalesBond if you want to see which deals in Proposal already look thin before you open the records. For the broader idea of scoring a deal’s condition, our deal health score post covers what belongs in such a score and what doesn’t.
When this is too heavy
Solution selling assumes there is a diagnosis to make. Sometimes there isn’t.
A buyer who calls with a part number, a renewal of the same plan, a like-for-like replacement of a tool that broke, a one-call sale with a published price: these deals have a problem the buyer has already solved in their own head, and three records on them are ceremony. Record 1 becomes one line, records 2 and 3 are skipped, and nobody pretends otherwise.
The honest test is the length of the cycle. If the deal typically closes in fewer conversations than it takes to fill the three fields the method is bigger than the sale, and forcing it will cost you reps’ patience without changing a single outcome. Keep the one habit that survives even transactional selling, which is writing down the buyer’s sentence, and leave the rest for the deals where a proposal can actually be wrong. If you are choosing what to read next, see best sales books for a small team.
For those deals, start small. Add the “Not proposed” line to the next proposal your team sends and see what the rep puts in it. If the line comes back empty, you have found the deal to review first.
