A strong B2B sales discovery call checklist helps account executives understand a buyer's situation before recommending a solution. For SaaS and ERP teams, discovery can involve operational workflows, stakeholders, existing systems and decision constraints. Skipping this context can lead to irrelevant demos, weak qualification or proposals that do not address the real business problem.
Discovery is not a scripted interrogation. It is a structured conversation that gives both parties a clearer understanding of whether another step makes sense.
This guide offers a practical discovery call agenda, stakeholder-specific questions, a fictional SaaS and ERP conversation example, an evidence-based CRM note template, and a decision framework for what should happen after a call. It is aimed at SaaS and ERP teams targeting the United States and Canada.
Quick answer: Before presenting a solution, confirm why the buyer agreed to talk, understand their current process, explore the problem in their own words, identify what a better outcome would look like, learn which stakeholders and constraints matter, and agree on a clear next step. Do not invent an approved budget, active project or quantifiable savings simply to make a lead appear sales-ready.
Before the call: know why the buyer agreed to meet
Read the SDR's notes, confirm the prospect's role, and check the account against the approved ideal customer profile (ICP). Learn what was actually said in prior contact and what remains unknown.
A useful SDR-to-AE handoff should include account fit, buyer-stated need, meeting objective and relevant history. An AE who arrives uninformed may force the prospect to repeat the first conversation.
Avoid assumptions such as "they definitely want to replace their ERP" unless the buyer confirmed that.
Discovery, qualification and demo are not the same thing
| Conversation | Typical purpose | What it does not establish |
|---|---|---|
| Initial SDR qualification | Check company fit, role relevance, plausible need and a mutually understood meeting purpose | A confirmed deal, budget or complete technical scope |
| AE discovery | Understand workflows, business consequences, desired results, decision process, constraints and next steps | An automatic opportunity or product recommendation |
| Product demo | Show verified capabilities for needs already understood | That every requirement or integration will be supported |
| Technical/commercial evaluation | Validate architecture, security, procurement and implementation feasibility | A signed contract or guaranteed outcome |
A prospect may be qualified for a discovery conversation without being ready for a detailed demo or formal procurement. Our qualified sales meeting checklist addresses meeting acceptance; this article focuses on what to learn during the conversation.
Pre-call preparation checklist
Before the AE joins, confirm the verified account domain and target ICP, the attendee's actual role, the agreed agenda, the SDR's buyer-stated context, any current tools the buyer explicitly identified, the correct meeting link/time zone, and any contact restrictions. Record unknowns instead of guessing.
HubSpot's discovery guidance recommends reviewing prior interactions and setting an agenda. Research is preparation for better questions—not evidence the prospect has a particular problem.
A suggested discovery agenda
Use a flexible sequence rather than a rigid stopwatch.
| Stage | Goal | Sample question |
|---|---|---|
| Confirm purpose | Agree on the conversation's objective | "What would make this discussion useful?" |
| Business context | Understand the organization and process | "How does the workflow operate today?" |
| Challenge and impact | Explore the problem and consequences | "Where does the process create friction?" |
| Stakeholders | Identify who owns or evaluates change | "Who else would need to contribute?" |
| Requirements and constraints | Discover essentials and exclusions | "What could rule out a possible solution?" |
| Timing and next step | Decide what happens afterward | "What would be a helpful next step?" |
Do not insist that every conversation cover every item. The buyer's needs should shape the order and depth.
A natural opening for an agreed call
"Thanks for making time. I understand from our earlier conversation that [confirmed topic] is worth exploring. I'd like to understand how the process works today, where you see opportunities to improve it, and what success would mean for your team. Then we can decide together whether a technical discussion or another step would be useful. Does that match what you hoped to cover?"
This is illustrative, not a scripted claim that a buyer said something they did not. Confirm permission, purpose and how much time the attendee has, rather than beginning with a lengthy sales deck.
Salesforce's discovery-call guide similarly emphasizes buyer goals, problems, stakeholder influence and explicit next actions. Its question frameworks are guidance, not universal checklists or proof that all buyers will make a purchase.
1. Confirm the current business context
Start with open questions about the current way of working.
For SaaS workflow software, ask how teams coordinate activity, what systems are involved, and how work is reviewed. For ERP, ask about processes spanning finance, operations and IT.
Examples:
- "Can you walk me through the process your team uses today?"
- "Which departments depend on the information being accurate?"
- "What is working well that you would want to preserve?"
- "What prompted the discussion at this time?"
Asking what works well prevents discovery from becoming a search for problems that do not exist.
Compare SaaS and ERP current-state questions
| Area | SaaS-focused example | ERP-focused example |
|---|---|---|
| Existing process | "How does a request move from one team to another?" | "How are orders, inventory and finance records reconciled across sites?" |
| Systems | "Which apps support the current workflow?" | "Which systems feed the reporting and transaction process?" |
| Business context | "What changes have affected the team's workload?" | "Have new entities or locations changed how your teams work?" |
| Existing strengths | "What would you definitely preserve?" | "Which current controls and workflows must not be disrupted?" |
| Desired direction | "What would better visibility look like?" | "What would an improved reporting or integration process enable?" |
All questions are hypotheses to adapt. Do not assert that the company has disconnected systems, bad data or operational losses before the buyer confirms it.
2. Explore the need without manufacturing urgency
A credible pain point is one the prospect recognizes. Ask where time is lost, where quality or visibility breaks down, and what business consequences follow.
For example, a manufacturer might describe inconsistent inventory reporting across sites. A SaaS buyer might describe manual approvals between applications. These are illustrative scenarios, not verified claims about real LeadUp prospects.
Use follow-up questions such as:
- "How often does that happen?"
- "Who is affected by the issue?"
- "What have you tried so far?"
- "What happens if the current approach stays in place?"
- "What improvement would be meaningful?"
Avoid converting every inconvenience into an immediate buying decision. The buyer may be researching possible future improvements.
Separate the symptom from the impact
Use a question sequence that keeps the buyer—not the seller—in control:
- Symptom: "What happens when that process breaks down?"
- Frequency: "How often does it happen, roughly?"
- Affected work: "Who has to resolve it, and what does that interrupt?"
- Business relevance: "What makes improving this process worth considering?"
- Desired improvement: "How would you know an alternative was working better?"
If the buyer volunteers figures, label them as buyer estimates until verified. Do not translate "we spend some extra time" into a fictional ROI calculation.
A hypothetical SaaS conversation
AE: "What happens when a customer request needs input from another department?"
Buyer: "Our coordinators manually send updates between two teams."
AE: "Does that cause a problem, or is it manageable?"
Buyer: "It is manageable most of the time, but status updates get delayed during busy periods."
AE: "What would you want to improve first?"
Buyer: "I want to know who owns each handoff."
AE: "That helps. Before discussing a tool, may I ask which other teams would need to evaluate a change?"
This is entirely fictional dialogue. It demonstrates asking follow-up questions rather than claiming the customer needs a specific product or that a purchase decision exists.
3. Understand existing systems and constraints
The purpose is not to demand a technical architecture review in an introductory conversation. Capture the systems and requirements that could shape a potential solution.
For ERP, relevant constraints can include integrations, data migration, security review, multi-entity accounting, process standardization and implementation resources.
For SaaS, evaluate dependencies such as APIs, user permissions, data handling, onboarding capacity, and workflow compatibility.
If the buyer asks for a detailed certification, implementation commitment or legal assurance, involve the appropriate technical and legal specialists. Do not promise what has not been validated.
A practical ERP constraint map
For an ERP discussion, potential constraints may include:
| Category | What to ask | Who should validate it later |
|---|---|---|
| Data and migration | "What information would need to move or stay accessible?" | Technical/implementation lead |
| Integration | "Which systems must exchange data?" | IT/architecture specialist |
| Financial controls | "What approvals, audit trails or reporting must remain intact?" | Finance process owner |
| Operations | "Which workflows cannot be interrupted during a transition?" | Operations/project lead |
| Security and privacy | "What security or data-handling review would be required?" | Security/legal stakeholders |
| Rollout and change | "Who would train users and own process adoption?" | Implementation/change lead |
A first call can identify these topics without collecting confidential architecture diagrams or implying that a migration is already approved. Oracle's ERP implementation planning overview is useful context on why these projects often require coordinated business and technical stakeholders.
4. Map stakeholders and decision roles
The first attendee may be a champion or evaluator rather than the economic buyer. Ask respectfully how decisions about this kind of system are made.
Useful questions:
- "Who owns the business outcome?"
- "Which functions would need to review a potential change?"
- "Who evaluates technical fit?"
- "Is there a project lead coordinating requirements?"
- "What would trigger a formal decision?"
For complex ERP purchases, finance, operations, IT and an executive sponsor may be relevant. See our ERP buying committee guide for a more detailed role map.
Role-specific questions for the buying group
| Stakeholder | Question to prioritize | What remains to verify |
|---|---|---|
| Operations/process owner | "Which part of the workflow should improve first?" | Whether this function leads evaluation |
| CFO/controller | "Which reporting or control requirements matter most?" | Budget ownership and financial approval |
| IT/architecture | "What dependencies could rule out a solution?" | Detailed integration and security feasibility |
| Department champion | "Who else needs to see the problem and proposed approach?" | Whether they can sponsor change |
| Project/procurement lead | "What internal steps would an evaluation require?" | Actual decision process, timing and criteria |
Do not label an executive the sole "decision-maker" merely from a title. Map influence, evaluation and formal approval separately as the buyer explains them.
5. Clarify timing and commercial context appropriately
Budget, timing and procurement matter, but the first discovery call does not always require the buyer to have an approved project.
Ask whether this is early exploration, an active initiative or a planned evaluation. Understand any deadlines the buyer volunteers and what internal steps precede procurement.
If the buyer has no approved budget, record it as unknown or not approved—not as evidence that the conversation has no value. Apply the sales team's actual opportunity criteria.
The goal is to make the next step proportional to the buyer's readiness.
Budget and timing without a forced BANT interrogation
Frameworks such as Budget, Authority, Need and Timing (BANT) can organize what remains to learn, but they are not an instruction to demand all four answers on an exploratory call.
Instead, ask questions like: "Is this a formal evaluation or early research?" "What has to happen internally before you could review options?" "Would cost be assessed by your team or another group?" If the buyer says the budget is not yet allocated, mark it Not approved / Unknown rather than asserting that the opportunity is dead or that money is available.
Some enterprise ERP decisions require several stakeholder discussions before a timeline or budget is meaningful. Your CRM should represent the stage honestly rather than optimizing for a falsely complete qualification score.
6. Close with a mutually agreed next action
A good discovery call ends with clarity. The prospect should know what information will be shared, who owns the action and whether another conversation is needed.
Examples include a technical fit discussion, a product walkthrough adapted to the use case, inclusion of another stakeholder, or a decision not to proceed.
Do not book a second meeting automatically just to keep the pipeline looking active. A respectful no-fit conclusion is a valid discovery outcome.
Decide the next step using evidence
| Discovery outcome | Evidence | Appropriate next step |
|---|---|---|
| Relevant and ready for deeper evaluation | Supported use case, appropriate stakeholder and mutual interest | Technical discovery, tailored demo or stakeholder session |
| Potential fit, too early | Plausible need but no current initiative or approval | Provide requested material; revisit only where permitted |
| Open questions | Important capability, migration or security details unresolved | Document and route to a qualified specialist |
| No fit | Product, geography or hard requirement mismatch | Clearly close or disqualify the opportunity |
| No interest / opt-out | Prospect declines further contact | Update preferences and stop prohibited follow-up |
End by summarizing what the buyer actually told you and asking whether your understanding is correct. The next action should have a named owner and an agreed reason for occurring, not a default "demo scheduled" tag.
A short close and follow-up example
AE: "To make sure I understood, the main issue is [buyer-confirmed issue], and the team hopes to achieve [buyer-stated result]. We still need to verify [open requirement]. Would it be useful for us to share an approved technical overview, or should we leave it there?"
Follow-up (only when agreed and appropriate): "Thanks for our discussion about [topic]. My notes are that [accurate summary]. I will [specific approved action] by [agreed date]. You mentioned [known constraint]; we will verify it rather than assume compatibility. If the next discussion is useful, we can include [agreed role]."
The examples are not universally send-ready templates. Follow applicable contact preferences, privacy and communications rules for the actual recipient and message.
A copyable discovery call note template
Use a structured CRM record so the account executive, technical specialist and account owner can continue without repeating the same questions.
Fictional example — none of the following describes an actual LeadUp buyer:
Account: Example Service Operations Inc. (fictional)
Meeting ID / date: CRM reference and agreed buyer-local time zone
Attendee and role: VP of Operations, role verified in this scenario
Purpose: Understand potential workflow standardization
Current process (buyer-stated): Regional coordinators exchange status updates manually
Buyer-confirmed challenge: Some updates arrive late during busy periods
Business impact: Buyer has not yet provided a measurable estimate
Desired outcome: Clearer ownership of cross-team handoffs
Systems and technical scope: Specific applications and integration requirements unknown
Stakeholders: Operations involved; IT and finance participation to confirm
Budget/timing: Early exploration; no project date or approved budget shared
Fit and open risks: Initial product fit plausible; capabilities still to validate
Decision: Further discovery could be useful; no opportunity automatically created
Next action / owner: AE sends approved process overview only if buyer requested; technical review by named specialist if agreed
Contact preferences: Check suppression, channel and recording restrictions before follow-up
CRM fields for implementation
| CRM field | Why it matters | Quality rule |
|---|---|---|
| `account_id`, `contact_id`, `meeting_id` | Links company, attendee and actual event | Verify identity; no duplicates |
| `meeting_purpose`, `attendee_role` | Preserves what was agreed and why attendee is relevant | Role and agenda must be accurate |
| `buyer_stated_problem` | Records the issue in the buyer's words | Keep fact separate from inference |
| `current_process`, `desired_outcome` | Captures as-is and potential future state | Unknown is allowed |
| `impact_evidence` | Preserves frequency and impact without invented ROI | Label buyer estimates vs verified data |
| `stakeholders`, `decision_process` | Tracks buying roles and authority | Never assume approval from a job title |
| `systems_constraints` | Identifies technical, security or workflow risks | Escalate unvalidated claims |
| `budget_status`, `timeline_status` | Distinguishes active initiatives from early research | Record Unknown / Not approved where appropriate |
| `meeting_attendance`, `ae_acceptance` | Separates held calls from meeting quality review | Do not merge the two |
| `opportunity_decision`, `reason` | Documents whether genuine opportunity criteria are met | Buyer need alone is not a closed deal |
| `next_action`, `next_action_owner`, `due_at` | Makes follow-up accountable | A promised action needs an owner |
| `contact_preferences` | Ensures a lawful, respectful next interaction | Honor opt-outs and restrictions |
Only collect data necessary for a legitimate sales process. Protect sensitive information and adhere to the organization's retention and access policies. Keep factual notes, not speculative judgments about the individual.
Who should update what?
The SDR typically owns the initial qualification and handoff. The AE owns the discovery outcome, next step and opportunity decision. Product, implementation or security specialists validate specific technical claims. Sales Operations maintains stage definitions and data-quality checks. These are suggested roles; the actual organization should assign accountable owners explicitly.
Discovery call review and qualification checklist
The purpose of this checklist is to evaluate what the team learned during discovery, not to re-label every meeting as qualified simply because it took place.
| Question | Evidence expected | Decision |
|---|---|---|
| Was the agreed agenda respected? | Buyer understands the topic and purpose | Yes / Needs review |
| Does the account still fit the ICP? | Confirmed business context and exclusions | Fit / Exception / No fit |
| Is the role relevant? | Actual responsibility and influence | Verified / To verify |
| Was a real business issue identified? | Buyer's own description of a problem or initiative | Confirmed / Unknown |
| Was the desired outcome understood? | Buyer-stated goal or measurable preference | Confirmed / To explore |
| Were key constraints recognized? | Business, technical, privacy or timing notes | Known / Open |
| Were stakeholders and decision process explored? | Named functions, not assumed approvers | Partial / Clear |
| Is a next step justified and owned? | Mutual agreement and named responsible person | Proceed / Pause / Close |
An unknown answer should stay unknown. Do not equate discovery quality with a fully approved procurement project, and do not assign an arbitrary score that claims to predict revenue.
Discovery is not an automatic opportunity
A meeting may be Booked, Held and even AE-accepted for quality, while the buyer remains at the exploratory stage. A formal opportunity should be created only when the sales team confirms the organization's actual opportunity criteria.
Likewise, a discovery call can reveal a no-fit outcome. That is not a failed conversation if it prevents a misleading demo or forecast. Keep the historical meeting attendance and AE acceptance records intact, then record the accurate discovery outcome and reason.
Read What Is a Qualified Sales Meeting? for the SDR/AE acceptance standard. The SDR-to-AE Handoff guide explains how to transfer buyer context and responsibilities.
Coach discovery quality without invented benchmarks
Review a sample of call notes and recordings where permitted. Ask whether the AE confirmed the agenda, listened, explored the problem without leading the buyer, identified open risks, checked understanding, and owned an agreed next step.
Qualitative ratings such as Effective / Needs coaching / Critical issue can support feedback if accompanied by specific evidence. Do not present an arbitrary 0–100 grade, universal talk-time ratio or "guaranteed conversion improvement" as a market standard.
Track reliable follow-up completion, opportunity acceptance, disqualification reasons and buyer complaints using defined stages and comparable time windows. An increased demo count is not proof that discovery improved.
Train your team to listen and summarize
Review selected call notes and, where permitted, recordings. Examine whether the AE listened, asked relevant follow-ups, clarified conflicting information and summarized the buyer's stated needs accurately.
Coaching can focus on reducing leading questions, avoiding unverified promises, and making the next step useful. There is no universal discovery script that fits every buyer or product.
Maintain appropriate permissions, recording notices and privacy safeguards for US and Canadian participants as required by relevant laws.
Recording, privacy and follow-up in the US and Canada
Call-recording and privacy obligations can differ by location, participants, call method and applicable federal, state or provincial rules. Determine the requirements before recording or using AI meeting summaries; do not assume a single consent rule works throughout North America. When recording is unavailable or not permitted, use accurate, minimum-necessary written notes and appropriate access controls.
If the discovery call leads to an email follow-up containing commercial promotion, applicable requirements can include the FTC's CAN-SPAM guidance for US B2B email and the CRTC's CASL rules for Canadian commercial electronic messages. An agreed meeting does not automatically authorize unlimited marketing. Respect opt-outs and data-handling preferences; obtain qualified legal review for the actual communication.
Operational distinction: A neutral summary of an agreed discussion is different from launching an unsolicited promotional sequence. Classify the actual message by its content and purpose under applicable rules; do not assume a subject line alone determines legality.
Common discovery mistakes
Delivering the entire product pitch before learning the problem. Context should guide the demonstration.
Assuming the contact is the only decision-maker. Verify role and stakeholder process.
Treating conjecture as a confirmed problem. Separate fact from hypothesis.
Pushing for budget too early. Ask at a stage appropriate to the buying process.
Promising unsupported capabilities. Escalate technical or legal questions.
Ending without ownership. Agree on an outcome and named next-action owner.
Frequently asked questions
How long should a B2B discovery call last?
The appropriate duration depends on product complexity, the buyer's availability and the scope of the discussion. Agree on a realistic agenda and respect the scheduled time.
Is discovery the same as a demo?
Not necessarily. Discovery explores requirements and fit; a demo shows how the actual solution works. Some sales motions combine them, but clarify expectations.
Who should join an ERP discovery call?
Start with the relevant functional owner and include technical or financial specialists when their input is needed and agreed.
What if the buyer is not ready?
Record the real status, offer an appropriate next step if welcomed, and respect communication preferences. Do not misclassify the account as an active opportunity.
Can an AE create an opportunity directly after discovery?
Yes, if the evidence meets the organization's actual opportunity-creation rules. A held or accepted meeting alone does not justify automatically creating an opportunity.
How should a team quantify the buyer's problem?
Ask how often an issue happens, who it affects, and what results the buyer would like to improve. Record reported estimates as estimates and avoid asserting an ROI figure without a supported calculation.
Should we record SaaS or ERP discovery calls?
Only after checking the applicable recording, notice, consent, security and privacy requirements for the actual participants and jurisdiction. Use protected written notes if recording is not appropriate.
What if discovery reveals that our product cannot meet a requirement?
Document the incompatibility, involve a specialist if uncertainty remains, and avoid making unsupported promises. Disqualifying an unfit opportunity can be the right buyer-focused outcome.
Build on discovery before advancing the deal
For ERP-specific first conversations, our ERP cold calling discovery questions help an SDR identify a relevant function and invite a useful next step without claiming a replacement project is underway.
After the discovery call, use the MQL vs SQL vs Sales-Accepted Meeting guide to distinguish the buyer's actual sales stage from the meeting's attendance or AE acceptance status. A good conversation need not become an opportunity automatically.
Better discovery creates better decisions
A useful B2B sales discovery call checklist helps SaaS and ERP teams evaluate fit, clarify the business problem, map stakeholders and agree on an honest next step.
LeadUp Solutions supports targeted B2B lead qualification and appointment setting, so sales teams can start discovery with more context. To discuss your ICP and qualified-meeting rules, contact LeadUp Solutions.