
Account Research
Discovery Call Teardown: Where Good Calls Quietly Go Wrong
The discovery call mistakes that quietly kill deals are pitching before understanding the problem, accepting vague answers, and summarizing interest as intent to buy. Fix them by following one concrete problem through its consequences, checking your interpretation with the buyer, and earning a next step that resolves a real unknown.
Below is a fictional discovery call between a software rep and an operations lead evaluating workflow software. All dialogue and account details are invented for this teardown. The timestamps show where the conversation goes wrong, not a schedule every call should follow.
The buyer sounds engaged. The rep leaves pleased. Unfortunately, neither has established why anyone would buy.
Minutes 0 to 4: Did your research produce a question or a conclusion?
The rep's prep note reads:
Observation: The account's careers page lists operations roles across several locations. Assumption: Expansion is creating inconsistent handoffs. Opening angle: Pitch standardized workflows.
The observation is useful. The opening angle skips a step. Hiring could reflect growth, replacement, or a reorganization. None proves a workflow problem.
Before
Rep: I saw you're expanding the operations team. Our platform helps growing teams standardize their workflows. Is that a priority? Buyer: Yes, consistency is definitely something we care about.
The buyer hears a broad claim followed by an easy question. Who is going to argue against consistency? The rep has collected agreement, not evidence.
Better line
Rep: I noticed operations hiring across several locations. I wondered whether handoffs between teams were getting harder, but that may be unrelated. What prompted you to take this call? Buyer: Our weekly review keeps surfacing requests that nobody picked up.
Now there is something to investigate.
Use account research to form a hypothesis you can discard. Keep observations and assumptions separate in your prep notes. I would rather enter with one testable question than a page of company facts the buyer already knows.
Minutes 5 to 9: What follow-up did you leave unasked?
Before
Buyer: Requests fall through the cracks, and people spend time chasing updates. Rep: Got it. How many people would need access?
This is the first serious loss of control. The rep hears a familiar problem, labels it, and moves to sizing.
The buyer experiences a topic change just as they start explaining the work. The rep still does not know what a request is, where it gets stuck, or whether chasing updates is a nuisance or a reason to buy.
Better line
Rep: Walk me through the most recent request that got missed. Where did it start, and where should it have gone? Buyer: It came into a shared inbox. Each team thought the other had picked it up. Rep: How did someone eventually notice? Buyer: The requester escalated it during our weekly review. Rep: What happened because it sat there?
Follow the incident before asking about the whole organization. A useful sequence is:
- Trace it: Where did the work start and stop?
- Find the consequence: What was delayed, repeated, or left undone?
- Check the pattern: Was this unusual, or does it keep happening?
- Identify ownership: Who has to fix it when it happens?
If the buyer cannot describe a consequence, do not supply one. “That must hurt productivity” is your claim, not their evidence.
Minutes 10 to 14: The pitch arrives before the diagnosis
Before
Buyer: We track most of this in a spreadsheet. Rep: Perfect. Let me show you our automated routing and dashboards.
“Spreadsheet” is not a diagnosis. Sometimes the spreadsheet works. An inconvenient possibility for the person selling its replacement.
The exact failure is the word “perfect.” The rep has decided the solution fits before checking whether the problem is visibility, unclear ownership, inconsistent behavior, or something else.
The screen share makes recovery harder. The buyer starts responding to features rather than explaining their process.
Better line
Rep: What does the spreadsheet handle well, and where does it stop helping? Buyer: We can see the requests. We can't reliably tell who's responsible for the next action. Rep: Is that because ownership isn't recorded, or because the teams haven't agreed who should own it?
That distinction changes the deal. Software might make agreed ownership visible and enforce routing. It cannot decide which team should accept responsibility.
If ownership is agreed but poorly tracked, earn a narrow demonstration:
Rep: I can show how an owner gets assigned and how an unclaimed request gets flagged. Would that help you test whether we address this gap?
Show that workflow. Stop. Ask what would fail in their environment before opening another tab.
Minutes 15 to 21: Interest is not a buying process
Before
Buyer: That looks useful. I'd want my manager to see it. Rep: Great. Are you the decision-maker, or is your manager?
The rep needs to understand authority, but this question turns a buying process into a status check. It also assumes the manager's involvement means an evaluation is underway.
Better line
Rep: What would your manager need to understand before deciding whether this is worth evaluating? Buyer: Whether the missed requests are serious enough to justify changing the process. Rep: Have they asked you to find a solution, or are you exploring this yourself?
That last question can be uncomfortable. Ask it anyway. An exploratory conversation is useful, but it is not an approved project wearing casual clothes.
Then test urgency without demanding a close date:
Rep: If you keep the current process, what happens next? Buyer: We keep handling escalations in the weekly review. Rep: Is there anything making that unacceptable now?
If the answer is no, record it. Do not convert “we'd like to improve this” into a compelling event.
The next step may be helping the buyer establish whether the problem deserves action, not arranging a larger demo.
Minutes 22 to 30: Rewrite the happy-ears summary
Before
Rep: So you're looking to replace spreadsheets, improve efficiency, and move quickly. I'll send a proposal and set up a demo with your manager. Buyer: Sure, send something over.
The summary introduces three claims the buyer never made. “Send something over” accepts an email. It does not confirm a buying plan.
Here is how those discovery call mistakes contaminate the CRM:
| Optimistic note | Evidence-based replacement |
|---|---|
| Replacing spreadsheets | Current tracker shows requests but leaves ownership unclear |
| Strong business case | Consequences beyond escalation handling remain untested |
| Manager is decision-maker | Manager's role in approval is unknown |
| Proposal requested | Buyer agreed to receive information |
Better line
Rep: You described requests sitting unclaimed until someone escalates them. We haven't established whether that warrants new software or whether your manager wants to change the process. What have I missed?
Pause. Let the buyer correct you.
Then propose a next step with a job to do:
Rep: Would a working session with your manager help determine whether this needs fixing? We could trace a recent missed request and check who should own each handoff. If that isn't useful yet, I'll send a short recap for your internal discussion.
Pick that over a proposal. There is no agreed scope to propose.
Before ending, confirm who will do what. If the buyer wants an internal discussion first, ask whether and when a follow-up would help. Record the gap, not the outcome you hoped for.
FAQ
What are the most common discovery call mistakes?
Common mistakes include leading with an untested assumption, skipping follow-up questions, pitching too early, and treating positive feedback as buying intent. Another is writing a summary that overstates what the buyer confirmed.
How do you recover after pitching too early?
Stop the demonstration and acknowledge the jump: “I moved to the solution before understanding how this works today.” Ask the buyer to walk through a recent example, then return to the product only if it addresses the confirmed gap.
What should you capture after a discovery call?
Record the current process, a specific problem, its confirmed consequences, and who is involved in deciding whether to act. Separate buyer-confirmed facts from your assumptions. Include the agreed next action and the question it needs to answer.
Salesfleet turns plays like these into the next move on every account, written for you.
Try Salesfleet