The prospect nods through the demo. You have a pleasant conversation, three feature ideas, and no idea who owns the decision. A founder-led call does not need more polish. It needs a harder ending.
This article starts after legitimate contact
The other person has agreed to the conversation, their role and the reason for meeting are known, and the channel used to arrange it has passed the relevant checks. This is not a prospecting script. If you are still deciding whether contact is appropriate, use the outreach eligibility and stop-rule guide first.
Open a short pre-call record:
- the person’s role and the workflow they may own;
- the reason for the conversation, in their context;
- the disqualifiers you already know;
- the one product path you may show if the diagnosis supports it;
- the capabilities and evidence you must not promise.
Ask before recording. Notes can also contain personal or confidential data, so keep only what the decision requires, control access, and remove identifying detail before any wider use. The GOV.UK consent guidance is a useful operational reference, though it is not universal legal advice.
Reconstruct the last occurrence
Open, neutral questions are good at surfacing a process without feeding the answer. This follows the interviewing approach described in the GOV.UK Service Manual. A sales conversation is not automatically research, so be clear about the commercial context.
Before I show anything, could you walk me through the last time this job came up? I want to see whether the product path matches. If it does not, we can stop there.
Stay with the event:
- What triggered the work?
- Which record, inbox, or system held the current state?
- Where did someone check, wait, re-enter, or ask for help?
- Who felt the consequence?
- Who can approve access, budget, or a process change?
If the person cannot recall a real occurrence, write that down. Do not rescue the call with your favorite version of their problem.
Show one path and expose its edge
Repeat the workflow in plain language. Ask whether you have it right. Then show only the path connected to the diagnosed job, using synthetic or appropriately redacted data instead of uploading sensitive account material.
Illustrative conversation; not a transcript, prospect, customer, or sales result. The fictional product turns emailed project updates into a draft weekly report.
Founder: Last time an update was missing, you found it while assembling the report and messaged the project lead. Is that accurate?
Buyer: Yes, though replies can land in another thread.
Founder: I’ll show the draft-report path. It flags an unresolved update but does not send a reminder. Please stop me when it no longer matches your process.
Buyer: The report shape is close, but our updates arrive through a shared mailbox.
Founder: I have not verified that mailbox setup. I’ll record it as a fit check, not as supported.
The last sentence is the useful part. An unknown stays unknown in front of the buyer. That prevents a smooth demo from becoming an accidental promise.
Route the objection; do not wrestle with it
| Objection | What it may mean | Next record |
|---|---|---|
| Problem | The current method is adequate or the consequence is minor. | No-fit unless another specific job explains the original interest. |
| Authority | The participant knows the work but cannot approve the change. | Name the decision owner and the evidence they would require, or close. |
| Capability | A required input, integration, permission, or control is absent or unverified. | Technical fit check with an owner and a date; no promise. |
| Trust | The buyer needs evidence about data handling, reliability, support, or reversibility. | Specific evidence request, not “needs confidence.” |
| Price | The package, scope, priority, or price may not fit. | Record which part is out of proportion. Do not infer budget. |
| Timing | A real dependency delays action, or “later” is a polite no. | A named trigger and owner, otherwise close the record. |
Do not treat an objection taxonomy as a closing trick. Its job is to prevent “interested” from swallowing a no-fit, a missing capability, and an unowned next step.
A mini-demo has a proof boundary
Show
- The input shape.
- The action tied to the diagnosed job.
- The output and human review point.
- The limitation that could change fit.
Do not show
- Unrelated features to fill time.
- Real sensitive data without the right controls.
- An integration you have not verified.
- A fictional result presented as social proof.
There is no universal ideal demo length. Stop when the relevant path has either matched the workflow or failed against it.
Close with a three-way decision memo
| Call log | What belongs in the record |
|---|---|
| Confirmed workflow | What the participant reported, kept separate from your interpretation. |
| Fit | The product path that matched. |
| Gap or unknown | What is missing, unsupported, or still unverified. |
| Evidence promised | The answer, document or sample to provide, with owner and date. |
| Outcome | Next step, no-fit, or closed. |
| Close condition | The event that ends the record if the next step does not happen. |
An illustrative follow-up could read:
Subject: Shared-mailbox fit check
Thanks for walking through the weekly report process. I noted that updates arrive through a shared mailbox and that reminders need manual approval.
I have not marked the mailbox setup as supported. I will verify it by [date]. If it is supported, the proposed next step is a sample-data review of the draft-report path. If that setup is a blocker, I will close the record rather than suggest a workaround that has not been tested.
Send product learning to the right inbox
A documented claim misunderstanding can become a landing-page copy task. A failed first action can become an onboarding investigation. An unverified requirement belongs in a fit check. A request belongs in an evidence log until the underlying job is clear. None of these becomes a roadmap item because one fictional or real conversation mentioned it.
Ignore the number of screens shown, the smoothness of the pitch, generic “great call” notes, and feature ideas without a decision owner. Do not invent closing probabilities or put “follow up later” in the pipeline. If there is no event that reopens the decision, close it.
Choose the outcome before leaving
End the call with a named next action and owner, a clear no-fit, or a closed record. If the only outcome is “they seemed interested,” the diagnosis did not reach a decision. Do not patch that gap with another demo or an endless follow-up stage.