A discovery call is the conversation in which a seller finds out what problem the customer actually has, what it costs them, who is affected, and how they will decide. In B2B software it comes after qualification and before the demo. Its output is not a list of requirements. It is an agreed problem, a number attached to it, and a next step with a date.
TL;DR
- The goal of discovery is an agreed problem, not a filled-in form. Customers describe symptoms. Your job is to get from the symptom to cost, revenue or risk — and then to a number.
- No discovery, no demo. A demo built without discovery is a guess at what matters, delivered with confidence.
- Questions work as a ladder, not a list: symptom, consequence, business impact, metric. Fifty flat questions produce an interrogation; four rungs produce a business case.
- In enterprise deals the Solution Engineer should lead it. They have the depth to push past vague answers, and they see more deals than any single account executive.
- Discovery quality can be scored. Five dimensions, 0–2 points each. Below 5 out of 10 the deal is at risk, whatever the forecast says.
What is a discovery call?
A discovery call is a structured conversation to understand a prospect's situation well enough to decide what to show them, to whom, and why they should care. It is the step that separates a relevant demo from a feature tour.
What it is not: a second qualification call, a questionnaire read aloud, or a courtesy before the "real" meeting. If the customer leaves a discovery call having learned nothing about their own problem, the call was for your benefit only, and they will notice.
One distinction matters before anything else. Discovery is also where you separate what the customer thinks they need from what they actually need. Sometimes those are identical. Sometimes a question you ask opens up a problem they hadn't consciously framed yet — which is a good reason to ask it.
What is the difference between qualification and discovery?
Qualification asks whether there is a deal worth pursuing. Discovery defines the problem in depth. In practice the line between them is fluid: qualification is a subset of discovery, and the transition happens as soon as you're convinced there is business to be done.
Early in a cycle, qualification dominates — do we want to invest more time, capacity and resources here? Frameworks such as MEDDPICC describe what you need to know at that stage. They say nothing about how to run the conversation that gets a CFO to share a real number. That second part is discovery, and its output is what belongs in those fields.
This is also a capacity question. If your Solution Engineer sits in the first or second qualification call, something is broken in the sales methodology rather than in the headcount plan. A useful gate is to bring PreSales in once win probability is past roughly 25% — we explain why in Lies in PreSales.
How do you structure a discovery call?
Around one movement: from what the customer says hurts to what it costs the business. Everything else is scaffolding.
Customers start at the bottom rung. The business case lives at the top — and nobody climbs there unasked.
- Open with what you already know. Prior research, your understanding of their industry, the reason the meeting exists. This earns the right to ask hard questions and saves the customer from explaining the basics.
- Start with the symptom. Let them describe what is going wrong in their own words. Don't correct, don't pitch.
- Ask for the consequence. What happens because of that? Who feels it? How often?
- Reach the business level. Every real problem ends in one of three places: it costs money, it loses revenue, or it raises risk.
- Quantify. How much, how often, how slow. This is where cost of inaction comes from — and the basis for judging whether your price is small or large.
- Map the people and the decision. Who else is affected, who decides, by which criteria, by when.
- Agree the next step. A specific action with a date and an owner. "We'll follow up" is not a next step.
Steps 3 to 5 are where most calls stop too early. Customers are excellent at describing symptoms and poor at explaining pains. Nobody volunteers a number; you have to ask for it, and often twice.
What questions should you ask in a discovery call?
Questions that move up the ladder — not a list of fifty. A long flat list turns the call into an interrogation and produces answers nobody can use. Grouped by rung, a handful is enough:
| Rung | What you're after | Discovery call questions |
|---|---|---|
| Symptom | What is going wrong, in their words | "What made you take this meeting now?" · "Walk me through how this works today." · "Where does it break?" |
| Consequence | What the symptom causes | "What happens when that goes wrong?" · "Who has to fix it, and what doesn't get done meanwhile?" · "How often does that happen?" |
| Business impact | Cost, revenue or risk | "What does that mean for the business — cost, lost revenue, exposure?" · "Who above you cares about this, and why?" |
| Metric | A number | "If you had to put a figure on it — hours, euros, deals — what would it be?" · "What would it be worth to halve that?" · "What does it cost you to leave this as it is for another year?" |
| Decision | How they'll choose | "How will you know the problem is solved?" · "Who else needs to be convinced?" · "What has to happen before you can sign?" |
Two questions from that table do more work than the rest. "How will you know the problem is solved?" produces decision criteria that you helped shape, instead of a feature list you were handed. And "why is that important to you?" — asked whenever a detailed technical question arrives — tells you whether the gap you were about to confess to matters for the use case at all. Nine times out of ten the answer changes what you say next.
Who should lead discovery — the AE or the SE?
In enterprise deals, the Solution Engineer, with the account executive in the room. The AE owns the relationship and the commercial thread. The SE has the technical and domain depth to push past "it's inefficient" to how much, how often and how slow — and the credibility with the people who will actually use the product.
There is a structural argument too. With coverage ratios of one SE to three, four or five account executives, a single SE sees far more deals — sometimes 20 or 30 in a quarter against a strategic AE's handful of accounts. That breadth means the SE recognises patterns across industries and knows what a realistic metric looks like for this type of customer.
What an SE leader at a vertical SaaS company in the DACH region told us is the upgrade most teams need: move away from feature-and-function description toward industry-specific value discovery. "Not just: how does the process run, where does the button need to be, what mobile features are needed — but really with prior research, industry knowledge, and an understanding of typical pain points in the sector."
What are the most common discovery mistakes?
- Feature-checking dressed up as curiosity. "Do you need mobile access? Approvals? SSO?" That is a requirements interview. It tells you what to tick, not why anyone would buy.
- Stopping at the symptom. "Our reporting is slow" is where discovery starts, not where it ends.
- Pitching at the first opening. The customer mentions a problem your product solves and the demo starts in your head. Stay with the problem until it has a number.
- Answering at speed instead of at depth. A technical question arrives and the SE answers it fully, instantly — including the three caveats nobody asked about. Ask why the question exists first.
- Finding three problems and showing all three. Knowing about a second and third use case doesn't oblige you to put them on screen. Solve the one you both agreed is real and urgent, and land the rest later — the argument is in Do LLMs Give Good Demo Advice?.
- Leaving without a next step. No date, no owner, no deal.
How do you know whether a discovery call was good?
Score it. Discovery gets filed under "soft skills", which is code for "we don't measure it, so we don't coach it". A rubric with five dimensions, each scored 0–2 from the call recording, makes it observable:
| Dimension | 0 — absent | 1 — partial | 2 — strong |
|---|---|---|---|
| Problem clarity | Talked features, never the problem | Problem named, not explored | Root problem and business consequence surfaced |
| Impact quantified | No numbers | Vague "it's costly" | Money, time or risk attached to the pain |
| Stakeholders mapped | Single contact | Roles named | Buying centre and decision process understood |
| Success metrics defined | None | Loose goals | Explicit, measurable criteria agreed |
| Next step committed | "We'll follow up" | Soft next call | Specific step with date and owner |
Treat 8–10 as strong, 5–7 as coachable, and below 5 as a deal at risk. Anything that can't be evidenced from the recording scores zero. Conversation-intelligence tools such as Gong or KickScale record and transcribe calls so the rubric can be applied across a team rather than to four sampled calls a quarter.
One warning. The moment a review becomes predictable, people prepare for the review instead of the customer — Goodhart's law in a lanyard. Score real calls, not rehearsals, and rotate the reviewers. The full set of five qualitative metrics is in Qualitative Metrics: Making Discovery & Demo Quality Coachable.
Frequently asked questions
What is the goal of a discovery call? To leave with an agreed problem, a number attached to it, the people and criteria involved in the decision, and a specific next step. Not a list of requirements, and not a filled-in CRM form.
How long should a discovery call be? Long enough to get from the symptom to the business impact, which rarely happens in one sitting. In complex deals discovery is a series of conversations with different stakeholders rather than a single meeting.
What is technical discovery? The part of discovery that covers the customer's environment: systems, integrations, data, security requirements and constraints. It matters for the proof of concept and for technical validation — but it comes after the business problem is understood, not instead of it.
Should you demo during a discovery call? As a rule, no. No discovery, no demo: until you know which problem is real, acute and agreed, any demo is a guess. In fast, low-value deals a short, unpersonalised first demo run by the account executive can be part of qualification — that is a different thing from the demo that follows discovery.
How many discovery questions should you prepare? Fewer than you think. Prepare the ladder — symptom, consequence, business impact, metric, decision — and a couple of questions for each rung, then follow the customer's answers. A call in which you got through all your questions was probably not a good one.
Can AI help prepare a discovery call? Yes, for the research that earns you the right to ask: the customer's industry, business model and likely pressures. And afterwards, by scoring a transcript against your rubric. It can't have the conversation for you, and everything it produces later — demo scripts, summaries, MEDDPICC fields — is only as good as what that conversation uncovered.
If you want your team to run discovery that ends in a number instead of a requirements list — pain chains, quantified impact, criteria shaped rather than recorded — that is the core of the Trusted Advisor Academy. Book a discovery call with us. Yes, we'll run it the way this guide describes.
Tim Brömme & Jan-Erik Jank are the co-founders of SE Rockstars, with 30+ years in enterprise PreSales and 350+ SEs coached.