Discovery calls: build a system reps actually run

A rep on a team I worked with ran a discovery call last year that I still think about. Forty-five minutes, great rapport, the prospect laughed at his jokes. He came off the call convinced it was a slam dunk. Then he sat down to update the CRM and realized he could not answer three basic questions: who signs the contract, what happens if they do nothing, and what number this problem is costing them. He had a nice conversation. He did not run a discovery call.

That gap is everywhere. Discovery is the single highest-value call in a B2B deal, and most teams treat it like a warm-up. They wing it, ask a few surface questions, and move to the demo because the demo feels like progress. Then the deal stalls in month three and nobody can say why, because the answer was buried in a call that never happened properly back in month one.

I have spent 10 years building revenue systems, and I will tell you the uncomfortable part first: your discovery problem is rarely a skills problem. Your best rep runs great discovery on instinct. The issue is that the instinct lives in his head, the questions never make it into the CRM, and the other six reps on the team are guessing. Discovery is a system you have not built yet.

What a discovery call is actually for

Strip away the frameworks and a discovery call has one job. Figure out whether there is a real deal here, and if there is, gather the information that lets you and the buyer both make a good decision later. That is it. It is not a pitch. It is not a demo. It is the call where you earn the right to have the next call.

Here is where most reps go wrong. They think discovery is about qualifying the prospect out or in for their own benefit, so they run it like an interrogation. Budget? Authority? Timeline? The buyer feels processed. Meanwhile the actual point of discovery is to understand the buyer's situation well enough that everything downstream gets easier: the demo is tailored, the proposal is priced right, the champion knows how to sell you internally.

The data backs this up. On the highest-converting discovery calls, the rep talks less than 46% of the time. Once a rep crosses roughly 65% talk time, conversion drops off a cliff. Discovery is a listening exercise disguised as a call. If you are talking more than the buyer, you are pitching, not discovering.

Why most discovery calls fail

I have listened to hundreds of call recordings across client engagements. The same failure patterns show up again and again.

The first is happy ears. The rep hears one line of interest and stops digging. The prospect says "yeah, reporting is a pain for us" and the rep mentally books the deal. He never asks how much time it wastes, who complains about it, or what they tried before. A pain you cannot quantify is a pain the buyer will not spend money to fix.

The second is the feature reflex. The prospect mentions a problem and the rep immediately says "oh, we do that." Now you are demoing on a discovery call, which means you are pitching a solution before you understand the problem. You have also given away your advantage, because the buyer now knows you can do the thing and has no reason to keep answering your questions.

The third, and the one that quietly kills forecasts, is that nothing gets captured. The rep runs decent discovery and then writes three sentences in the CRM notes field. Two weeks later the sales engineer joining the demo has no idea what pain to address. The manager reviewing the pipeline sees "good call, moving to demo" and has no way to challenge it. The information existed for 45 minutes and then evaporated.

That last number is worth sitting with. Industry benchmarks put it at roughly two real opportunities per thousand dials once you account for connect rates and no-shows. When a real prospect finally gets on a discovery call with you, that call is expensive. Treating it casually is like driving 40 dials to book a meeting and then not preparing for it.

The framework question, answered honestly

Every RevOps post about discovery tells you to pick a framework. BANT, MEDDIC, SPIN, MEDDPICC, GAP, the alphabet goes on. I have opinions here, and they are not the popular ones.

BANT is fine for a first-touch filter and useless for anything past that. It was invented by IBM in the 1960s to disqualify fast, and it still does that job, but it tells you nothing about how the deal actually gets bought. I wrote a whole piece on why BANT lets bad deals through if you want the long version.

MEDDIC and its cousin MEDDPICC are what serious deals run on. About 73% of SaaS companies selling six-figure contracts use some variant. The reason is that MEDDIC forces you to answer the questions that predict whether a deal closes: what metric does the buyer care about, who is the economic buyer, what are the decision criteria and process, where is the pain, and who is your champion. I broke down how most teams run MEDDIC wrong separately, because knowing the acronym and running it are different things.

But here is my honest take. The framework is not the point. The framework is a checklist that reminds you what to be curious about. The actual skill is the questions you ask and, more importantly, the follow-up question you ask after the first answer. SPIN understood this better than any of the letter-frameworks. Ask about the situation, dig into the problem, draw out the implication of that problem, then let the buyer articulate the payoff of solving it. That sequence does the emotional work that a qualification checklist never will.

Use MEDDIC to decide what fields go in your CRM. Use SPIN-style questioning to actually run the call. They solve different problems.

The structure of a discovery call that works

Here is the shape I coach teams to run. It is not rigid, but the sequence matters.

The framing step is the one reps skip and the one that pays off most. You open by telling the buyer what you want to cover, and you ask for permission to be direct. Something like: "I want to understand your situation properly before I show you anything, so I am going to ask a lot of questions. If any of them are off base, tell me. And if it turns out we are not a fit, I will tell you that too." This does two things. It signals you are not there to pitch, and it gives you cover to ask about budget and decision-makers later without it feeling like an ambush.

The diagnose step is where the real work happens. You are running the situation-problem-implication sequence. A buyer tells you reporting is painful. You do not move on. You ask how they do it today. You ask how long it takes. You ask who does it and what else that person could be doing. You ask what happens when the number is wrong. By the fourth question the buyer has talked himself into the fact that this problem is expensive, and you did not have to sell anything.

Aim for five to eight real questions across the call, spread over two or three MEDDIC areas. Not thirty. Once you cross ten scripted questions it becomes an interview and the buyer shuts down. Depth beats breadth. One problem understood four layers deep is worth more than eight problems skimmed.

The questions that actually earn answers

I am not going to give you a list of fifty questions. You will not use them and half are filler. Here are the ones that consistently pull real information.

For metrics, the best question I know is a version of: "If this works, what number changes, and who notices?" It forces the buyer to connect your solution to something measurable and to a person who cares. If they cannot answer it, you do not have a metric, and a deal without a metric is a deal that dies at the budget conversation.

For the economic buyer, I like: "If everyone on your team loves this but one person says no, whose no actually kills it?" That question cuts through the org chart fiction and finds the person who really decides.

For pain and implication, keep it simple and keep asking why. "Walk me through the last time this went wrong." Stories carry more information than abstractions. A buyer describing a specific bad Tuesday will tell you the real stakes better than any answer to "what are your challenges."

For the decision process, ask: "Say we agree this is worth doing. What happens between that moment and a signed contract?" You are mapping the paper process, the approvals, the procurement gauntlet. Most reps discover a legal review exists in week eight. Good discovery finds it on call one.

The part everyone skips: capturing discovery in the CRM

This is the RevOps half of the problem and it is the half that gets ignored. A great discovery call that lives only in a rep's memory is worth almost nothing to the business. It cannot be forecasted on, coached on, or handed off. And the single biggest barrier to fixing this is brutally practical: filling in MEDDIC fields properly takes a rep 15 to 25 minutes of post-call recall after a call that already ran long. So they do not do it. They type three sentences and move on.

I have watched teams try to solve this with willpower and it never works. You cannot manager your way to consistent CRM hygiene by asking reps to try harder. The fix is to make capture cost the rep almost nothing. That is a systems job, and it comes down to three moves.

First, build the discovery fields into the CRM as structured properties, not a free-text notes box. If your deal record has fields for metric, economic buyer, pain, decision process, and champion, and those fields are required to move the deal to the next stage, then discovery quality becomes visible and enforceable. This is the same principle behind well-defined pipeline stages: a stage should mean something specific happened, rather than that time passed.

Second, use call recording and AI to do the data entry. This is where the last two years actually changed the game. Tools like Gong, Clari, and a stack of newer call-intelligence products transcribe the call and auto-populate your MEDDIC fields from what was actually said. The rep reviews and corrects instead of reconstructing from memory. That 20-minute recall tax drops to a two-minute review. When you remove the cost, the behavior follows.

Third, connect the pieces so nothing falls through. In the builds we run for clients, the recording tool drops a transcript, an automation layer parses it into structured fields, and the CRM updates the deal record and flags anything missing. The rep gets a Slack nudge if the economic buyer field is still empty two days after a discovery call. We build a lot of this glue with n8n and AI automation so it runs on the client's own infrastructure and stays clean under GDPR.

What good discovery does to the rest of the funnel

When discovery is run well and captured properly, everything downstream gets cheaper. The demo stops being a feature tour and becomes a targeted response to the two problems the buyer actually named, which is exactly how a demo should close. The proposal is priced against a quantified pain, so the budget conversation is a formality instead of a fight. The champion has the metric and the business case written down, so he can sell you internally when you are not in the room.

And forecasting gets real. A manager looking at a pipeline where every deal has a documented economic buyer and a quantified metric can tell the difference between commit and hope. A pipeline built on "great call, good energy" is a pipeline built on vibes. I have seen the reporting difference firsthand, and it maps directly to CRM data quality: the forecast is only as trustworthy as the discovery data feeding it.

Here is the thing that took me too long to internalize. You do not fix discovery by sending reps to a workshop. Workshops wear off in three weeks. You fix discovery by building a system where good discovery is the path of least resistance: the fields are there, the AI does the typing, the stage gate enforces the questions, and the manager can see who is skipping the work. The rep who wants to wing it finds it is actually harder to skip the process than to follow it. That is what a RevOps team is for.

Frequently asked questions

How long should a discovery call be?

Thirty to forty-five minutes for most B2B deals. Shorter and you cannot get past the surface. Longer and you are either pitching or letting it wander. What matters more than length is talk ratio. If you are speaking more than 45% of the time, you are not running discovery, you are giving a presentation. Watch the recording and count.

Should I use BANT or MEDDIC for discovery?

Use BANT as a quick filter on the very first touch to decide if a deal is worth a real discovery call. Use MEDDIC or MEDDPICC to structure the discovery call itself and to decide what fields belong in your CRM. They answer different questions. BANT tells you whether to bother. MEDDIC tells you how the deal actually gets bought.

How many questions should I prepare for a discovery call?

Prepare five to eight core questions spread across two or three areas, and be ready to follow up on each one two or three layers deep. Thirty scripted questions turns the call into an interrogation and the buyer shuts down. The follow-up question, the one you ask after the first answer, is where the real information lives.

How do I get reps to actually fill in the CRM after discovery?

Stop relying on discipline. Reps skip CRM entry because doing it from memory takes 15 to 25 minutes after a long call. Make discovery fields structured properties required to advance the deal stage, then use call-recording AI to auto-populate them from the transcript. When capture drops to a two-minute review, reps stop skipping it. It is a systems fix, not a motivation fix.

What is the biggest discovery call mistake?

Hearing one problem and jumping straight to "we do that." The moment you start solving, you stop discovering, and you give away your advantage. Sit with the problem. Ask what it costs, who it affects, and what they tried before. Let the buyer talk himself into the fact that the problem is worth paying to fix. Then, and only then, show them how you help.

Discovery is where deals are won or lost, and most teams are still treating it like small talk before the real pitch. Build it into a system and it stops being the weakest call in your process and becomes the one that makes every call after it easier. If you want help turning your discovery into something you can forecast on, let's talk.