Discovery Call Framework: A PreSales Playbook

The most popular advice about discovery calls is to ask good questions, listen carefully, and earn the right to demo. That's a start, but it still treats the Solution Engineer (SE) as a guest in a process owned by someone else. In B2B SaaS, discovery is where technical fit, evaluation criteria, and the path to a technical win take shape. No discovery, no demo. The demo's polish can't rescue a story built around the wrong problem.

A useful discovery call framework gives the SE a specific job: turn the buyer's situation into evidence the team can use to decide what to validate, who needs to agree, and what should happen next. The output isn't a longer call or a fuller CRM. It's a shared, testable view of the opportunity.

Why Discovery Is an SE Problem First

Discovery is the most misassigned job in the sales cycle. The standard split hands it to the account executive (AE) and brings the SE in once someone requests a demo. That works for a simple purchase. It breaks down the moment technical fit, integration, security, migration, or adoption decides whether the buyer can move forward at all. By the time the SE joins, the team is often building a presentation around assumptions nobody tested. I've watched evaluations die in proofs of concept that were scoped off a slide deck instead of a diagnosis.

Gartner's 2025 research found that 61% of buyers preferred an overall buying experience without a sales representative, while still wanting seller input for work that demands contextual intelligence, like judging whether a product fits their organization's needs (Gartner's survey of B2B buyers). Buyers will happily do their own reading. What they can't do alone is map your product onto their environment. That mapping is the SE's contribution: connecting business needs to technical realities and saying plainly when the fit isn't there.

The practical job is making sure the evaluation tests the right thing. The AE owns the commercial thread. The SE owns the technical diagnosis: workflows, constraints, risks, and the evidence the buyer needs before anyone commits to a demo or proof of concept. Run early, discovery kills weak deals fast and gives real ones a testable path. Run late, and you inherit a demo script written for a problem you never verified.

Four artifacts that make discovery useful

An SE-led or SE-supported call should leave behind four outputs you can act on:

1. A verified problem record. Current state, business impact, the people affected, the desired future state, and how the buyer will measure progress.
2. A stakeholder and decision map. Champion, technical evaluator, users, and approvers, plus anyone who can block the decision.
3. Evaluation criteria. What the solution must prove and which technical or operational constraints it has to satisfy.
4. An agreed next step. Activity, owner, timing, and exit condition, settled before anyone starts building.

The practical test: If your discovery notes can't shape the demo, the evaluation, or the next customer conversation, the call hasn't done its job.

This diagnostic work sits at the center of the PreSales role: helping the buying team decide whether the solution fits and whether it can deliver the outcome they need. SEs who run discovery as the technical-win engine stop inheriting bad deals and start shaping them.

The Business Case for a Repeatable Framework

A framework exists to make preparation, relevance, and follow-through less dependent on which SE happens to be on the call.

As noted earlier, buyers avoid suppliers whose outreach feels irrelevant, and they notice when what a seller says conflicts with what the company published. For an SE, that translates into two disciplines: ask about the buyer's actual environment before describing capabilities, and keep every technical statement consistent with what the rest of the account team has already told them. A repeatable framework makes both habits default rather than heroic.

RAIN Group studied 488 buyers and 489 sellers and reported that top-performing sellers generated 2.7 times more conversions and 1.8 times more quality outcomes than other sellers. The research associated stronger results in part with more customized, value-focused first meetings and better targeting (RAIN Group's sales prospecting research). For a solutions engineer, that is the case for doing the work before the call. Walk in with a hypothesis about the buyer's environment, then use discovery to test it instead of opening with a generic technical overview.

Structure beats scripts. A script tells you what to say even when it doesn't fit; a framework gives you a sequence and lets you adapt the questions to the buyer. Teams formalizing a consistent process may find this overview of how to standardize team workflows useful. The payoff is repeatable behaviors that make each call specific to the people in it, which is what turns discovery from a qualification chore into the technical-win engine.

The Seven Moves of an SE Discovery Call

Most discovery frameworks assume the AE runs the call and the SE shows up for the demo. That division is why so many evaluations stall. On calls I run, the SE owns the technical thread from the first question, and the AE owns commercial context and commitment. You don't need rigid speaking blocks. You do need both people to know who steers each part before the call starts, because a buyer can tell within five minutes whether the two of you have a plan.

1. Set the joint purpose. Name the outcome you're working toward and ask what the buyer needs from the conversation. "If we finish with a clear view of the workflow and what a useful evaluation would need to prove, would that be valuable?" Skip the company introductions. If the buyer wanted your funding history, they would have read the website. Capture the agreed purpose and who leads each topic.

2. Map the current state. Have the buyer walk you through the process as it runs today: systems, handoffs, integrations, constraints. A familiar product category does not mean a familiar workflow. I have seen two "standard CRM setups" that shared nothing but the vendor logo. Record the environment and exactly where the process breaks down.

3. Surface three to four distinct problems. Ask where friction occurs, who experiences it, and whether separate teams face different issues. Don't collect a long list of symptoms and call it diagnosis. Keep distinct problems separate in your notes, even when they connect to the same workflow.

4. Quantify the impact. Ask what each problem costs in time, risk, capacity, or missed outcomes, and how the buyer knows. If the buyer can't put a number on it, don't manufacture one. Capture the available evidence and what would help establish the impact.

5. Map stakeholders and criteria. Ask who evaluates the technical fit, what the solution must prove, and how the organization will approve a purchase. The person who understands the system best is often the person with the least say over the decision. Record criteria separately from process, because conflating them is how SEs end up satisfying requirements nobody signed off on.

6. Test the cost of inaction. Ask what changes if the buyer leaves the problem unresolved, and what event could make the current approach unacceptable. Avoid manufacturing urgency. Note the buyer's own reason for acting, or the lack of one.

7. Agree on a mutual next step. Summarize what you heard, ask what you missed, then propose an activity tied to a verified problem. A technical validation with a named owner and a date beats "we'll send something over" every time. Capture the activity, owner, date, and exit criterion.

Climb the question ladder

Move from open context to a problem-specific probe, then to impact, priority, and decision process. For a hypothetical platform migration, you might ask how workloads are managed today, where the current process creates risk, what that risk affects, how soon the migration needs to happen, and who approves the target architecture. After each answer, paraphrase the finding and confirm you've understood it before moving on. That confirmation step is where SEs earn trust, and it is the part that gets skipped when the call runs long.

Gong reports a 46:54 seller-talk-to-listen ratio for winning discovery conversations (Gong's discovery-call analysis). Treat it as a coaching signal rather than a quota. If you talked more than the buyer across a forty-five minute call, you presented, and presenting is a different meeting. The AE can open and set the commercial context, then hand the technical thread to the SE. The SE should hand it back when the team needs to confirm business priority or secure commitment. Planned handoffs look like coordination. Unplanned ones look like two vendors competing for airtime.

The moves fall apart without preparation, so build the hypothesis, the question split, and the exit criterion in advance with a solid pre-call planning routine.

A short video can help teams compare call mechanics during practice:

Watch the video on YouTube

Finding Decision Friction, Not Just Pain

A buyer may describe a real problem clearly and still be unable to move the purchase forward. One contact wants speed; security wants evidence; operations worries about implementation; finance needs a business case. If discovery captures pain but misses those competing needs, the SE may design a convincing demo for a decision the group hasn't made.

Gartner reported in 2025 that 74% of B2B buyer teams experience unhealthy conflict during the decision process, and teams that reach consensus are 2.5 times more likely to describe the deal as high quality (Gartner's research on buyer-team conflict). That makes decision friction a better discovery target than pain alone. You're trying to learn where the group is misaligned and what evidence could help it reach a decision.

Ask questions that reveal how the group will decide:

• Who benefits if this works, and who takes on implementation risk?
• Who can pause or veto the purchase, even if they aren't on this call?
• What evidence does each stakeholder need to support approval?
• Where do teams define success differently?
• What would make someone reopen a decision the group thought it had settled?

Make the decision map easy to share

After the call, create a one-page decision map the champion can circulate. Include the problem, affected groups, each group's success criteria, unresolved objections, evidence required, and the next consensus-building action. Don't turn it into a sales deck; the point is to give the buyer a useful summary of their own decision.

Gartner describes buying as nonlinear, with buyer teams moving among problem identification, solution exploration, requirements building, supplier selection, validation, and consensus creation. The practical question for the SE is which job remains unresolved and what evidence or conversation could move it forward.

A shared artifact needs to be easy to find and circulate. Teams assessing ways to find the right sharing tool can use that resource as a starting point, but don't let tooling distract from the content. The map only helps if it reflects the buyer's actual disagreements. For a broader qualification structure that distinguishes people, process, and evidence, see MEDDPICC for Solution Engineers.

From Call to Record to Mutual Action Plan

The call ends, the SE writes three lines in the CRM, and two weeks later the demo brief reads like it came from a different company. I've inherited that brief more than once. Discovery only pays off if what the buyer said survives the handoff, so capture enough during the call, write a clean record after it, and send the buyer-facing recap while the conversation is still fresh.

For each verified problem, the record needs:

• Current state: The workflow, systems, and constraints the buyer described.
• Impact: The operational or financial consequence, plus the evidence supporting it.
• People affected: Users, technical evaluators, approvers, and possible blockers.
• Desired future state: What the buyer needs to change or achieve.
• Validation method: The activity and evidence that would demonstrate fit.

Keep stakeholder roles distinct. The Economic Buyer holds authority over the purchase and owns the business outcome. The champion advocates internally, the technical evaluator assesses fit, and the day-to-day user lives in the workflow. An enthusiastic technical contact proves interest, not engagement from whoever signs.

Decision Criteria and Decision Process go in separate fields, because they fail in different ways. "What must the solution prove?" captures criteria like security, integrations, implementation requirements, and cost of ownership. "How will the organization approve it?" captures steps, people, approvals, and timing. A solution can clear every technical criterion and still stall because procurement, legal, security, or an executive approver was never addressed.

Turn the record into a mutual action plan

Every verified problem gets an evaluation activity with an owner, a date, and an exit criterion. If security needs evidence about data handling, name who provides it, who reviews it, when that review happens, and what conclusion counts as done. The entry and exit criteria guide gives teams a useful structure for defining what must be true before an evaluation advances. A proof of concept with no buyer-owned success measure is a hope, not a plan.

Score calls on observable behavior rather than confidence or charisma:

Recording calls makes reviewing them easier, but run it through your organization's consent and retention policies first. This practical guide for revenue teams covers the operational side of that decision.

A durable record feeds the wider responsibilities of a Sales Engineer and turns the technical win into something you can measure instead of something you argue about in the forecast call.

Five Failures SEs Cause or Inherit in Discovery

Bad demos rarely start on the demo itself. They start a week earlier, when someone decides the demo is the next step before discovery has established what it should prove. I've sat in enough of those calls to recognize the pattern: the SE inherits a broken setup, or creates one, and the evaluation dies two meetings later.

Here are the five failure modes that show up most often, with the correction for each:

• The slide ambush. The SE opens with architecture diagrams or product slides, and the buyer becomes an audience instead of a source of context. Gong's call analysis, cited earlier, found slide-heavy discovery calls cut questioning and lengthen seller monologues. Lead with the buyer's workflow. Slides earn their place only when they answer a question the buyer has already validated.

• Premature demo pressure. The AE promises a demo to secure the next meeting, and the SE arrives with no clear problem to solve. This is the failure you inherit rather than cause, but you still own the fallout. Push back before the invite goes out: ask the AE what the demo is supposed to prove. If nobody can answer, propose another discovery conversation instead.

• Single-stakeholder capture. The champion gives a coherent account, and the SE mistakes coherence for consensus. Ask who benefits, who absorbs the risk, and who can block approval. Then ask for a path to that person, or record explicitly what remains unknown.

• Impact theater. The buyer names a frustration and the team inflates it into a business case without evidence. A pain without a measurable consequence is a complaint. Ask what the problem affects and how the buyer measures it today. If they can't quantify it yet, record the gap and agree on how to test it together.

• The no-next-step call. The meeting ends warmly, but nobody owns what happens next. A friendly close is not commitment. Before hanging up, confirm the activity, participants, owner, timing, and exit condition out loud.

Each fix runs on the same discipline: return to what the buyer has verified, then make the next action specific. Polish can't substitute for that work.

Making This Stick Without Burning Out

Frameworks fail when teams treat them as training content instead of a working habit. The fix is a cadence small enough to survive a busy quarter and specific enough to change what happens on live calls.

• Each week: Review one discovery call against the scorecard. Choose one behavior to improve, not a dozen.
• For every live deal: Write a mutual action plan that connects verified problems to evaluation activity, owners, dates, and exit criteria.
• Every other week: Run a peer roleplay using a current scenario, then practice the part of the call that felt least natural.

The RAIN Group research cited earlier supports this direction: stronger first meetings are a marker of top performers. For an SE, the more useful benchmark is internal. Did the call produce a verified problem, a map of decision friction, and a next step the buyer owns? If the answer stays no for three weeks running, the framework is decoration, and the cadence above is where you correct it.

Use the discovery call guide to strengthen call structure, and the PreSales training guide to assess what kind of practice will fit your team. The outcome PreSales owns is the technical win. Discovery is where you decide what that win must prove.

PreSales Unleashed GmbH offers the Trusted Advisor Academy, a year-round program with structured learning, live practice, and feedback tied to active deals. If you want to apply this discovery call framework to real opportunities with your team, visit PreSales Unleashed GmbH.