A founder loses a major infrastructure deal after three months of conversations. The product worked, the team was responsive, and the technical demo landed well. Yet the buyer chose a competitor who arrived with a migration cost model, a rollout plan the CFO could defend, and a clear answer to the question, “What happens if this goes wrong?”
The feedback was blunt: the founder's team was friendly but generic. That's a painful outcome, but it's also a useful diagnosis. In complex B2B technology sales, buyers rarely need another catalogue of features. They need a partner who can understand the business problem, shape a workable response, and help them build internal confidence around the decision.
Why Solutions Based Selling Matters for B2B Tech
Solutions based selling is an operating discipline, not a softer version of product pitching. It asks a sales team to diagnose before prescribing, quantify the consequences of inaction, and connect technical capability to an outcome the buyer can defend internally.
That distinction matters most when implementation risk is high. A cloud migration, managed database service, developer platform, or security programme affects engineering, finance, operations, procurement, and executive stakeholders. Each group evaluates a different form of risk. Engineering cares about integration and reliability. Finance cares about cost and payback. Operations cares about continuity. The executive sponsor cares about whether the initiative supports a wider business priority.
A rep who only demonstrates features leaves those questions unanswered. A rep who runs a structured discovery process can turn them into a commercial case.
The modern history of this approach reaches back to the 1970s, when solution-based selling developed as a move away from transactional, product-first sales. Mack Hanan's 1970 book, Consultative Selling, helped popularise the idea that sellers should diagnose business problems and sell measurable results rather than promote products alone. This history of consultative selling and its commercial implications also cites McKinsey research covering 175 commercial organisations and almost 23,000 sales representatives, which found that companies with above-average commercial capabilities grew revenue 56% more than the average for their market.
Practical rule: If the buyer can repeat your pitch without mentioning their own business, you haven't reached a solution.
The discipline also changes how marketing and sales work together. Marketing research should give sales useful account context, language, and buying signals. Sales conversations should return objections and qualification evidence to marketing. A practical sales and marketing alignment process makes that feedback loop explicit instead of leaving each team to guess.
Solutions based selling doesn't win because it sounds more empathetic. It wins when it helps a buying committee make a difficult decision with less uncertainty. The trade-off is real: reps need stronger preparation, better qualification, and closer coordination with technical and delivery teams. But in high-risk B2B technology deals, that work is often what separates a credible commercial partner from a vendor with a polished demo.
What Solutions Based Selling Actually Means
Solutions based selling means diagnosing a buyer's business problem, co-authoring a response, and selling the measurable outcome rather than the feature set. The response may combine software, configuration, services, integrations, implementation support, training, and process change.
Product selling starts in a different place. The rep presents capabilities, compares packages, answers configuration questions, and negotiates price. That motion can be efficient when the buyer already understands the problem and wants a standard purchase. It becomes weak when the buyer has competing priorities, unclear requirements, or several stakeholders who need different reasons to support the decision.
General consultative selling can also stop too early. A rep may build rapport, ask thoughtful questions, and fill a whiteboard with pain points, then return to a generic demo. Solutions based selling demands the next step: turn the diagnosis into a coherent design and connect each component to a business result.
The doctor and pharmacist analogy is useful. A pharmacist fills the prescription a customer brings in. That's fast and appropriate when the diagnosis is already clear. A doctor runs tests, forms a diagnosis, recommends treatment, and monitors recovery. The doctor's process takes more time, but it's more credible when the problem is complex, high-stakes, or politically sensitive.
The buyer is part of the solution
B2B buyers increasingly arrive with substantial research already completed. A Corporate Executive Board study of more than 1,400 B2B customers found that buyers had completed, on average, nearly 60% of a typical purchasing decision before speaking with a vendor, including researching solutions, ranking options, setting requirements, and benchmarking pricing. The analysis of solution-based selling and self-directed B2B buying explains why a rep must add value to the buyer's existing work rather than restart the process with a product tour.
That doesn't mean the buyer has solved the problem. It means the seller must quickly identify what has been decided, what remains uncertain, and which business outcome still needs an internal owner. The strongest conversation doesn't force the prospect through a scripted diagnosis. It improves the diagnosis they've already begun.
The Four Processes That Make It Work
Research on solution selling identifies four linked relational processes, customer requirement definition, customisation and integration, deployment, and post-deployment support. The model is based on co-creation, not persuasion. The seller and buyer shape the answer together, often across broader stakeholder networks, with the relationship extending beyond the signature to adoption, growth, and renewal. The academic analysis of solution selling's relational structure makes the operational implication clear: a strong pitch can't compensate for a weak handoff.
Consider a managed database provider speaking with a fintech.
Discovery defines the actual problem
The rep starts by mapping the performance gap, not by presenting uptime options. They learn that the engineering team isn't merely looking for a higher service level. Its real problem is recurring incidents, slow root-cause analysis, and an on-call burden that is delaying product work.
Discovery also identifies stakeholders. Engineering owns the technical risk, security reviews the operating model, finance evaluates the commercial case, and a senior product or technology leader may sponsor the change. Each person contributes requirements that affect the final design.
Customisation turns a product into a fit
The provider then configures the solution around the fintech's architecture, data sensitivity, migration constraints, support expectations, and internal skills. Pricing should reflect the scope and risk of the engagement rather than treating every prospect as a standard package.
Customisation doesn't mean promising anything the product team can imagine. It means making explicit which elements are standard, which require integration, and which assumptions must be tested before a proposal is approved.
Deployment proves the commercial promise
A migration plan coordinates technical implementation, internal owners, partners, data movement, testing, and change management. The seller's credibility depends on whether the promised outcome survives contact with delivery.
The rep should keep the buyer involved in launch criteria and escalation paths. A solution that looks elegant in a proposal but creates operational disruption will damage renewal potential and return the account to competitive review.
Support creates the next commercial conversation
Post-launch support should track adoption, performance, unresolved issues, and optimisation opportunities. The provider can use those observations to guide expansion or renewal discussions, but only after demonstrating that it owns the outcome beyond go-live.
Treating these stages as separate departmental transactions breaks the model. The discovery rep may promise a customized result, the implementation team may receive incomplete context, and the support team may inherit expectations nobody documented. A linked process preserves trust and gives the account team evidence for the next opportunity.
Discovery Questions That Uncover Real Problems
Discovery should feel like a working session, not an interrogation. Reps need a repeatable structure, but they also need permission to follow an unexpected answer. The framework below gives a call enough shape to qualify the opportunity without scripting the buyer into silence.
Start with business context
Ask what triggered the project now and which business goals connect to it. A weak answer sounds like, “We're reviewing vendors because the contract is up.” A stronger answer names a business event, a deadline, an executive priority, or a consequence the team is trying to avoid.
The next action depends on the answer. A clear trigger supports account research and stakeholder mapping. A vague trigger calls for more diagnosis before a demo or proposal.
Quantify the pain without forcing false precision
Ask what the current issue costs the business and how much time the team loses dealing with it. Buyers may not have an exact figure. That's fine. Look for a credible direction, such as repeated incidents, delayed releases, missed service commitments, or engineering capacity diverted from planned work.
Emotional language can be useful evidence. “We're tired of firefighting” or “the board keeps asking about this” signals that the problem has organisational weight. Pair that language with a follow-up question about who feels the impact and how the team currently measures it.
Map the decision process
Ask who signs off and in what order. Then ask who can block the project, even without formal purchasing authority. A contact who can describe the process, name the stakeholders, and explain the approval sequence is giving you a path to qualify and multi-thread.
If the contact can't access budget authority or refuses to introduce the people who own the risk, don't treat the opportunity as fully qualified. Agree on a specific next step that tests access. If that step doesn't happen, reduce the forecast rather than spending weeks building a solution for one friendly contact.
Examine the current workaround
Ask what the buyer uses today and where it falls short. The current solution may be a competitor, an internal tool, manual work, or a decision to tolerate the problem. Each option creates a different competitive position.
Listen for workarounds that consume skilled labour or create risk during peak periods. Those details often matter more than a request for feature parity because they reveal the cost of maintaining the status quo.
Define success before showing the product
Ask how the buyer will measure a win after implementation. Strong answers connect to a metric, operating condition, or executive commitment. Weak answers sound like, “We'll know when the team likes it.”
Disqualify or pause when there's no urgency before the next budget cycle, no credible cost of inaction, no access to decision authority, or a solution has already been selected. The lead qualification process should make those decisions visible in the CRM.
The Hidden Time and Revenue Trade-Offs
Solutions based selling consumes more commercial capacity than transactional selling. Leaders who ignore that cost create a bad implementation: they ask reps to conduct deeper research, involve more stakeholders, produce custom designs, and maintain the same activity target. Reps then rush discovery, overpromise customisation, or work unpaid hours to keep deals moving.
McKinsey's analysis shows the time trade-off directly. Typical reps spent less than a third of the working week in client sales interactions, with transactional sellers at 29% and solutions sellers at 22%. Solutions reps spent 28% of their week on preparation, compared with 21% for transactional reps. The source analysis of consultative selling techniques links those figures to the higher preparation demands of a solutions motion.
The right question isn't whether solutions reps should have more meetings. It's whether preparation produces better-qualified opportunities, stronger internal alignment, and a more defensible commercial case.
Compare the operating economics
| Metric | Solutions Rep | Transactional Rep |
|---|---|---|
| Live customer interaction | Lower share of working time, 22% in the cited McKinsey analysis | Higher share of working time, 29% in the cited McKinsey analysis |
| Preparation | Higher preparation load, 28% in the cited analysis | Lower preparation load, 21% in the cited analysis |
| Deal design | Tailored scope involving product, services, integration, and delivery | Standard package, configuration, and price discussion |
| Qualification | Requires stakeholder access, business impact, and implementation confidence | Can proceed with a clearer, narrower buying request |
| Commercial risk | More capacity tied up in each opportunity | More opportunities can be handled with lighter preparation |
| Best fit | Complex, consequential purchases with integration or change risk | Repeatable purchases with known requirements |
The model fails when the segment cannot support the effort. Low-value, highly standardised deals may not justify bespoke discovery and solution design. It also fails when the rep discovers the actual problem only after the proposal, forcing a late-stage pivot that consumes technical resources without improving qualification.
Capacity rule: Don't add a solutions methodology on top of an unchanged activity model. Remove low-quality work, narrow the target segment, or change the rep's coverage expectations.
Solutions selling also demands better opportunity governance. Managers should inspect the quality of the problem statement, the named stakeholders, the agreed success criteria, and the delivery assumptions. A forecast stage shouldn't advance only because a demo happened. It should advance when the buyer has helped validate the solution and the internal path to approval is credible.
B2B Tech Examples in Practice
A managed database provider can begin with uptime, resilience, and support coverage. Those topics matter, but they may not be the buyer's commercial priority. During discovery, the engineering lead reveals that the team's real burden is the recurring incident load and the time senior engineers spend on emergency response.
That changes the solution. The rep maps incident patterns, escalation ownership, monitoring requirements, migration constraints, and the work the engineering team wants to recover. The proposal becomes an operational improvement plan supported by managed infrastructure, rather than a list of service-level features. The close now depends on whether the buyer believes the provider can reduce operational strain without creating migration risk.
A developer platform creates a different trap. The prospect asks for feature comparisons because that's the easiest way to structure vendor research. Discovery shows that the underlying problem isn't missing functionality. Several teams have fragmented CI pipelines, inconsistent deployment practices, and duplicated integration work.
The rep resists the urge to run a feature-by-feature demo. Instead, the team builds an integration roadmap around the existing tools, identifies the first workflow to standardise, and agrees on the technical and business conditions that would justify expansion. That design gives the developer champion something concrete to take to platform engineering and leadership.
An IT consultancy may uncover the most valuable insight in a joint workshop. Bringing security and operations leads into the same conversation can expose compliance gaps, ownership confusion, or resilience assumptions that a procurement-led vendor comparison won't reveal.
The consultancy then scopes discovery, remediation, implementation, and ongoing support as connected work. It doesn't pretend every issue requires a large project. It separates urgent risks from longer-term improvements, assigns owners, and makes the buyer's internal sequence part of the proposal.
These examples share a commercial pattern. A discovery moment changes the problem definition. The team customises the response around that problem. The close becomes a decision about a credible business outcome instead of a preference between similar feature lists.
The same principle applies to outbound. H2's Grafbase case study describes an engagement that combined platform-engineering roles, competing technology usage, relevant social engagement, and signs of dissatisfaction with alternative solutions to shape outreach. That kind of account research gives a rep a reason to start a relevant conversation, but the sales call still needs to test whether the inferred problem exists and matters now.
A 30-Day Plan to Start Selling This Way
A practical rollout should change behaviour without pretending that a new framework will fix weak targeting or unclear positioning. Start with a baseline, define the evidence required to progress an opportunity, and pilot the motion on live deals.
Week 1 focuses on the baseline
Sales leaders should record the current win rate, average discovery call duration, demo-to-opportunity conversion, rep preparation time, opportunity age, and forecast accuracy. The point isn't to create a perfect dashboard. It's to identify the capacity and quality problems the new operating model must address.
AEs should review recent won and lost deals, marking where the team first identified the business problem, when decision-makers joined, and whether delivery assumptions were tested. SDRs should review booked meetings for fit, trigger quality, and the presence of a plausible business problem.
Week 2 standardises discovery
Choose SPIN or a similar framework, then create a one-page account research template. It should capture the trigger, business context, current workaround, quantified impact, stakeholders, decision process, and success criteria.
Sales leaders define qualification and disqualification rules. AEs use the questions on every live call, while SDRs use a lighter version to establish relevance before booking a meeting. Don't turn the template into a form-filling exercise. Managers should coach from call recordings and inspect whether the rep followed the evidence, not whether every box was completed.
Week 3 introduces solution mapping
Before a demo, the AE links each confirmed problem to a technical outcome and a business metric. The solution map should show what the product does, what services or integrations are required, who owns implementation, and how the buyer will assess success.
Technical specialists should challenge assumptions early. Delivery teams should identify dependencies before the proposal. If the solution cannot be explained without hand-waving, the opportunity needs more discovery or should be paused.
Week 4 runs a controlled pilot
Select five live deals with enough complexity to test the model, but don't force every account into a bespoke process. Review cycle time, deal size, forecast accuracy, stakeholder coverage, and the quality of the documented success criteria.
Track the operating indicators below alongside commercial outcomes:
- Discovery calls booked: Separate volume from meetings that meet the agreed fit criteria.
- Qualified opportunities created: Count opportunities with a real problem, a plausible business impact, and a credible decision path.
- Average deal size: Compare scope quality, not just price, and record what services or integrations shaped the value.
- Sales cycle length: Identify where additional preparation creates progress and where it merely delays a weak opportunity.
- Forecast accuracy: Check whether evidence-based qualification improves the manager's view of close likelihood.
At the end of the pilot, keep the parts that improve decisions and remove the bureaucracy. Solutions based selling should help reps spend preparation time where complexity justifies it, disqualify weak opportunities earlier, and give buyers a business case they can carry through their organisation.
H2 helps B2B technology teams put that discipline into practice through managed outbound, custom GTM system builds, and private workshops covering research, qualification, Clay, AI workflows, and sales operations. Visit H2 to discuss your audience, current pipeline challenge, and the next practical step.
