Run the call as a diagnostic with a product nearby. Reconstruct the current workflow, show only the part that changes it, record the objection in the buyer’s words and leave with a named next step or a clean no.
Open a record before the call
A founder does not need an elaborate CRM to avoid fuzzy sales notes. One record should carry the account from diagnosis through the next decision.
| Pipeline field | What to record |
|---|---|
| Account and role | Who is present, who owns the workflow, who approves a change and who will use it? |
| Reason for conversation | The event, introduction, question or observed business context that made the call relevant. |
| Current workflow | Trigger, steps, handoffs, tools, output and the person responsible when it fails. |
| Recent incident | A specific occasion the buyer can reconstruct, not a general opinion about the problem. |
| Consequence | What was delayed, repeated, missed, exposed or made harder? |
| Fit boundary | Required data, integration, authority, urgency or product capability that could disqualify the sale. |
| Demo path | The one workflow to show if diagnosis supports it. |
| Objection | Exact words, category, evidence requested and whether the objection can be resolved honestly. |
| Next step | Owner, action, date or condition. “Follow up later” is incomplete. |
| Product learning | Copy, onboarding, scope, pricing or product implication. A request is not automatically a roadmap item. |
Diagnose the last real occurrence
Open by confirming the purpose of the call and asking permission to understand the workflow before showing the product.
“I’d like to understand how you handle this now, then I can show the part of the product that may fit. If it does not fit, we can stop there. Could you walk me through the last time the issue came up?”
Continue with questions that move through the incident:
- “What started the process?”
- “What did you do next?”
- “Which file, inbox, spreadsheet or system held the current state?”
- “Where did you have to check, wait or ask someone else?”
- “What happened when that step did not go as expected?”
- “Who felt the consequence, and who would have to approve a different method?”
Do not rescue a vague answer with your own story. If the buyer cannot recall an incident, record that. The product may still be relevant, but the call has not established an active problem.
Show one path, then ask what fails
Start the demo only after you can state the buyer’s current workflow back to them. Use their input shape where possible, but never upload real sensitive data casually. Sample or redacted data may be more appropriate.
“You described collecting status updates from email, copying them into a report and checking missing items with each project lead. I’ll show the draft-report path only. Please stop me where this stops matching your process.”
The demo should follow the buyer’s sequence:
- Show the input the product expects.
- Perform the action connected to the diagnosed problem.
- Show the output, including any review or manual approval.
- Name the limitation before the buyer discovers it.
- Ask what would prevent this path from fitting the real account.
Keep the demo only as long as the workflow requires. A fixed time limit is not a quality standard. The useful test is whether every screen answers something learned during diagnosis.
A labelled call excerpt
Illustrative conversation, not a sales or customer result. Assume the product creates a draft weekly report from emailed project updates. No claim is made about time saved, purchase intent or adoption.
Founder: “What happened the last time an update was missing?”
Buyer: “I noticed while assembling the report and messaged the project lead.”
Founder: “Where do you track whether they reply?”
Buyer: “I flag the email, but someone else may answer in a different thread.”
Founder: “I’ll show how the draft marks an expected update as unresolved. It does not send a reminder by itself. Would that manual approval fit, or do you need reminders sent automatically?”
Buyer: “Manual approval is fine, but our updates arrive from a shared mailbox.”
Founder: “That is a fit question I need to verify. I won’t assume the current connection handles your mailbox setup.”
The founder does not turn the shared-mailbox requirement into a promise. The record now needs a technical-fit check and a clear owner.
Give every objection a field and a response
| Objection type | Record | Founder script |
|---|---|---|
| Problem | The buyer does not experience the issue often enough or has an acceptable method. | “It sounds as though the current process is working well enough. I do not want to force a fit. Is there another part of the workflow that caused the original interest?” |
| Authority | The person can explain the workflow but cannot approve access, budget or change. | “Who would need to assess this with you, and what would they need to see before spending time on it?” |
| Capability | A required integration, input or control is missing or unverified. | “The product does not currently support that requirement,” or “I need to verify that before I make a claim. I’ll send a clear answer.” |
| Trust | The buyer needs evidence about data handling, reliability, support or reversibility. | “Which risk needs to be resolved first? I can show the relevant process or limitation rather than asking you to take it on trust.” |
| Price | The buyer cannot connect the package to the workflow, or the cost exceeds the current priority. | “Which part feels out of proportion: the problem, the scope, the timing or the price itself?” |
| Timing | A real event or dependency delays the decision. | “What changes at that point, and should we agree on a specific action or close the record until you return?” |
“Too expensive” is not a complete field. Neither is “not now.” Capture the context without arguing. If the product is not a fit, mark it clearly instead of creating an endless follow-up stage.
Send a decision memo, not a thank-you cloud
The follow-up should make disagreement easy. It can be short:
Subject: Shared-mailbox check and report workflow
Thanks for walking me through the weekly update process. I noted that updates arrive through a shared mailbox, you assemble the report manually, and reminders need approval before sending.
I need to verify whether the current connection supports your mailbox setup. I have not marked that as supported yet.
If it does, the next step would be a sample-data review of the draft-report path. I will send the compatibility answer by [date]. You can tell me to close this if the shared-mailbox requirement makes it a non-fit.
Follow-up fields
Feed the call back into the product carefully
After the call, choose the correct destination for each note:
- Repeated buyer confusion about an existing capability belongs in landing-page or demo copy.
- A failed first step belongs in onboarding or setup work.
- An unverified requirement belongs in a fit check, not a promise.
- A feature request belongs in an evidence log until the underlying job and target-buyer fit are clear.
- A no-fit reason belongs in qualification criteria so the next call can end earlier.
Prepare the next call record
Create the pipeline fields before the meeting. Write the opening diagnostic question, choose one demo path and prepare the follow-up memo with blanks for fit, gap, evidence and next owner. The call can stay plain because the record carries the discipline.
The next useful read depends on what the call exposed: find the matching product field note →