The Discovery Call Preparation Checklist

A useful discovery call preparation checklist covers account context, testable problem hypotheses, questions about impact and buying, and two checks: why the meeting exists and who will attend. Prepare a short opening that confirms the purpose, asks permission to investigate, and gets the buyer talking about a real problem within the first ninety seconds.

The output should be one screen of notes you can use during the call. Not a company biography. Nobody needs you to read their About page back to them.

What should you research before a discovery call?

Start with the meeting history, not a search engine. The strongest clue is usually what the buyer already said.

Read the booking note, email thread, previous call notes, and relevant CRM activity. If an SDR booked the meeting, ask what earned the reply and what expectations they set. An AE should not make the buyer repeat discovery because the handoff was inconvenient.

Then check the company website, relevant job postings, and attendees' public professional profiles. Look only for context that could change your questions.

Use this research checklist:

• Business: What does the company sell, and who buys it?
• Relevant workflow: Which team likely owns the process your product supports?
• Possible trigger: Has the buyer mentioned growth, a new responsibility, a renewal, or a broken process?
• Existing approach: What tools or manual work have they actually disclosed?
• Meeting history: What did your team promise, ask, or already learn?
• Unknowns: What must the buyer explain because public research cannot?

Keep facts separate from assumptions. A job posting for sales operations is evidence of hiring. It is not evidence that forecasting is broken.

Stop researching when you can explain why this conversation might matter and name what you still need to learn. More tabs are not a qualification method.

Which hypotheses should you form?

Prepare a primary problem hypothesis and a plausible alternative. Add a reason the buyer might reasonably do nothing.

I would rather enter with a narrow theory I can abandon than a broad list of problems I hope the buyer recognizes. The point is to direct discovery, not rehearse a diagnosis.

Here is an illustrative example for a generic software seller discussing a sales workflow:

Hypothesis	What would support it?	What would weaken it?
Handoffs cause repeated discovery	Buyers repeat information and reps rebuild context	Context transfers reliably
Ownership is the real issue	Notes exist, but nobody owns the next action	Responsibilities are clear
Changing tools is unnecessary	The team can fix the workflow with its current setup	The current setup cannot support the needed process

Under each hypothesis, write one test question. For the handoff example, a suggested question is: “Walk me through what happened between booking the last meeting and the AE taking it.”

That asks for an event, not agreement with your pitch.

Also write down what would make the opportunity a poor fit. If a process change solves the problem without a purchase, you want to learn that now, not after borrowing a sales engineer for three calls.

What questions belong on your discovery call preparation checklist?

Prepare questions in the order you need to understand the situation. Do not open with budget before you know whether there is anything worth funding.

Use these as suggested prompts, not a questionnaire to read aloud:

1. Trigger: “What made this worth discussing now?” If the meeting came from outbound, ask what caught their attention rather than assuming an active project.
2. Current process: “Can you walk me through the last time your team handled this?” Ask who did what and where work changed hands.
3. Friction: “Where did that process become difficult?” Follow the buyer's answer instead of introducing every problem your product solves.
4. Consequence: “What happened because of that?” Look for rework, delayed decisions, missed follow-up, or another specific effect.
5. Priority: “What happens if you leave this as it is?” Then ask what other work competes for attention.
6. Buying path: “If fixing this becomes a priority, who else would help evaluate a change, and how would it get funded?”

Choose the follow-ups that would change your next move. If the buyer says reporting takes too long, ask who prepares it, what makes it slow, and which decision waits for it. Do not supply an impressive cost estimate on their behalf.

Define the call's desired outcome in your notes: enough evidence to decide whether another conversation is justified, what it should resolve, and who should join.

“Book a demo” is an activity. It is not a discovery finding.

What are the two things to verify beforehand?

Your discovery call preparation checklist should end with two checks. These catch avoidable mismatches that account research cannot fix.

Verify why the buyer believes they are attending.

Compare the invitation, booking thread, and handoff notes. Did they agree to explore a problem, see a specific capability, or simply hear what you do? Those are different meetings.

If the purpose is unclear, send a short confirmation. Suggested wording: “I have us down to discuss your current handoff process and whether there is anything worth changing. Is that still the most useful focus?”

If someone promised a product walkthrough, honor that expectation or agree on a different plan. Do not quietly turn it into an interrogation.

Verify who is attending and their relationship to the work.

Check the attendee list and confirm responsibilities where needed. A title alone does not tell you whether someone runs the process, uses the tools, or approves spending.

Ask whether anyone else should join to explain the current workflow. Do not demand an executive before you have established a reason for one to care.

For an SE joining the call, specify the technical unknown they should help resolve. “Support discovery” is not much of a brief.

How should you use the first ninety seconds?

Prepare the opening as a sequence, not a speech. Use these time ranges as a rehearsal guide, not a stopwatch exercise.

First thirty seconds: confirm the purpose.

For the illustrative handoff scenario: “You mentioned that context gets lost between booking and the first AE meeting. I'd like to understand where that happens and whether it's worth fixing. Is that still the right focus?”

Next thirty seconds: agree on the approach.

Suggested wording: “Could we start with a recent example, then cover the impact? If there seems to be a fit, we can decide what would be useful to look at next.”

Final thirty seconds: ask for the actual event.

Suggested wording: “Think about the last handoff that didn't go well. What happened?”

Skip the company overview unless they need it. If they correct your premise, update your notes and follow their version. That correction is useful evidence, not a failed opening.

Keep your brief visible. During the call, capture the buyer's words, evidence against your hypothesis, and unresolved questions. Before ending, propose a next step tied to a specific unknown, with an owner and agreed timing. If there is no meaningful problem, say so.

FAQ

How much research should I do before a discovery call?

Research until you understand the meeting context, can form a testable problem hypothesis, and know what to ask next. Stop when additional information would not change your opening or questions.

Should I send discovery questions before the call?

Send the purpose and a brief agenda, not a long questionnaire. If a specific example would help, ask the buyer to bring one without making attendance feel like homework.

What if the buyer asks for a demo immediately?

Honor an explicit demo commitment. Ask what they most want to see, then use a few context questions to choose a relevant workflow instead of giving the full product tour.