COURSE READING AND WORKSHEETS
How to run a SaaS sales discovery call
A discovery call should help both sides decide whether there is a useful reason to continue. Understand the buyer's current workflow, the problem and its consequences, your product's fit, and the route to a decision. End with a specific next step or a clear reason to stop.
Make the purpose clear before the call
Explain what you want to discuss and what the person can expect to get from the conversation. If the request is commercial, say so. Research, support, and sales can overlap, but a buyer should not have to guess which conversation they accepted.
Prepare using the context already available: their request, previous conversation, or evaluation activity. Treat public information as a clue, not proof of their current problem. Write down what you know and what still needs confirmation.
A contact from a conference should not have to repeat the entire original conversation. Use the notes from the conference leads guide, then check whether the situation is still relevant.
Agree on a useful agenda
Begin with a short explanation of the proposed discussion: understand the workflow, check fit, and decide whether a demonstration or evaluation would help. Invite the buyer to add the question they need answered.
A fictional opening: “You mentioned difficulty tracing failed webhook deliveries into support tickets. I’d like to understand how you handle that today, check whether our supported workflow is relevant, and agree on a next step if it is. Is there a particular question you want us to answer?”
Use the opening only when it reflects the actual context. If the buyer asks to see the product first, show enough to establish what it does and then return to the relevant questions. An agenda is a shared guide, not a rule that prevents you from helping.
Walk through a recent instance
Ask for a specific occurrence of the problem. Follow the sequence from trigger to resolution: who noticed it, what they checked, which systems they used, and what happened next.
For a webhook tool, you might ask how a failed delivery becomes a support investigation and how the team decides whether to retry. You are learning the workflow, not trying to elicit a particular complaint.
Use neutral follow-ups. “What happened after that?” can reveal more than “Was that frustrating?” If someone uses a broad term such as unreliable, ask what it means in this situation.
Keep the customer interview guide nearby for question techniques, while preserving the sales call's purpose: assessing a relevant offer and decision.
Understand consequences and priority
Ask what the problem changes: customer experience, release decisions, support workload, or another concrete outcome. Let the buyer describe the consequence in their own terms.
Find out why they are considering a change now. A recurring inconvenience can matter without being a current priority. Conversely, a single incident can create a significant decision if its consequences are substantial.
Avoid requiring the buyer to invent an exact cost to make the problem seem legitimate. If a figure matters, ask how it is estimated and what it includes. An unsupported calculation can create false confidence for both parties.
Also ask what happens if they continue with the current process. Doing nothing may be a reasonable alternative. Understanding why helps you assess whether your offer is useful now.
Check the requirements that determine fit
Identify the environment, inputs, access, integrations, scale, and other conditions your product needs. Ask the questions necessary to assess them without collecting a full technical inventory that serves no decision.
State material limits promptly. If the buyer requires an unsupported deployment model, clarify whether the current offer can meet the need. Do not turn a roadmap possibility into an available capability.
Distinguish an essential requirement from a preference that can be investigated during a demo. Record unknowns with an owner and a way to answer them. Guessing at compatibility to preserve momentum creates a worse evaluation later.
The positioning guide provides a consistent reference for suitable situations and limits.
Learn how a decision would happen
Ask who would use the product, who would help evaluate it, who can approve a purchase, and which reviews are required. One person may perform several roles; titles alone do not establish authority.
Questions can be straightforward: “If an evaluation works, what would need to happen before your team could adopt it?” or “Who should join the next discussion to assess the setup?”
Discuss offer terms and price when they are relevant to fit. Avoid withholding basic information merely to force another meeting. If budget or timing is unknown, record that state rather than interpreting it as either a rejection or a commitment.
Use the sequence to establish a shared understanding. Adapt the conversation to the buyer’s question rather than treating every prompt as mandatory.
Summarize before recommending
Briefly recap the workflow, consequence, requirements, and decision route. Ask the buyer to correct the summary. This gives you a chance to identify a misunderstanding before proposing work.
Separate confirmed facts from assumptions. “You need to trace this delivery into a support case” may be confirmed. “Your whole team will use the product daily” may remain untested.
Recommend the smallest next action that answers the most important remaining question. It could be a focused product demo, a compatibility check, a scoped evaluation, a conversation with another participant, or no further action.
Choose the next step from the remaining uncertainty
In a fictional webhook discovery call, the buyer describes a relevant investigation problem but requires an unsupported deployment model. The useful outcome is a clear no-fit decision for the current offer, not a generic demo to preserve pipeline activity.
If compatibility is plausible but the buyer needs to inspect the output, choose a focused demonstration. If the output is understood but setup in their environment is untested, choose a scoped evaluation. If urgency is absent, share the agreed resource and record that no evaluation is planned.
A next step should answer a question both sides recognize. Do not use an additional meeting to conceal a known product mismatch.
These fictional routes connect the next action to what remains uncertain. A known mismatch should not be concealed by a generic demo.
Define a mutual next step
State what each side will do, who owns it, when it should happen, and which question it will answer. “Send some information” is incomplete until you know what information would be useful.
A fictional next step: the buyer supplies a sanitized description of the delivery-to-ticket workflow; the seller demonstrates a supported example; both assess whether the output provides the context needed for investigation. No customer data or product capability should be assumed available without agreement.
If the buyer wants only a resource, respect that scope. If there is no fit, summarize the reason and close the conversation cleanly. Another meeting is not automatically progress.
Record what the next owner needs
Send a concise recap that reflects the actual conversation. Retain the relevant evidence, unresolved questions, promised work, participants, and agreed next action in the account record.
Use the sales handoff guide when another person will take over. Mark uncertainty clearly so the next owner does not mistake your inference for the buyer's statement.
Download the discovery call guide and decision record. It is a prompt for attentive conversation, not a script to read regardless of the buyer's answers.
Explore the SaaS growth guides and templates to choose another problem to work on.