How to interview lost deals: rebuild the decision before you trust the reason

To interview lost deals, rebuild the buying decision in order first. Then test whether the stated reason was a real dealbreaker or a tidy story told afterward.

Instant Expert EditorialPublished Updated 6 min read

To interview lost deals well, rebuild the buying decision in order before you ask why you lost. The goal is to understand what the buyer chose and what constrained them, not to prove your product was better.

"Too expensive" and "missing a feature" are fine opening answers. Neither is enough to change a roadmap. You still need to know what the buyer was trying to do, what they compared, who was involved and what happened after the choice.

Below is a decision-timeline worksheet and a made-up example about a training software purchase (illustrative, not a customer story).

1. Decide which loss you are studying

A prospect who picked a competitor is a different case from one who renewed their old contract, postponed the project or dropped it. All chose an alternative, but not the same decision.

Write the question the research should answer. "Does our implementation process stop teams with a fixed training deadline from adopting?" is something you can act on. "Why do we lose?" is a mood.

The SBA's market research guidance covers direct research and the alternatives competing for customers (SBA market research guidance). Take that broad view, so "they bought nothing" stays on the list.

Keep learning and selling apart. Say the purpose in the invitation and let people decline. If you also want to pitch a new offer, make that a separate, explicit request. (A surprise win-back pitch halfway through the call is how you lose the deal twice.)

2. Talk to people who were in the room

An enthusiastic evaluator may know every demo and nothing about the final approval meeting. A purchasing contact may know the contract terms but not why users preferred one workflow.

Ask what part each person played. Note whether they evaluated options, recommended a choice, approved spending, ran implementation or heard about it afterward. When a step is outside their knowledge, find the person who was there instead of asking them to guess.

Record the buying period and product version, so feedback on an old version isn't read as feedback on the current one.

3. Rebuild the timeline before asking for reasons

Start with the event that began the search: "What was happening when the team first decided to look for a different approach?" Then walk forward through the purchase.

GOV.UK's guidance supports using a prepared discussion guide while exploring relevant experience (GOV.UK in-depth interview guidance). The timeline below is our own application of that idea to a buying decision.

StageWhat to captureNeutral prompt
TriggerEvent that made action necessary"What changed?"
Starting approachExisting tool, process or workaround"How were you handling it before?"
SearchOptions that entered consideration"How did each option come up?"
EvaluationActivities and people involved"What did the team actually compare?"
Turning pointEvent that changed the preferred option"When did the choice become clearer?"
ApprovalConditions required to proceed"What still had to happen before a commitment?"
AfterwardImplementation and present use"What happened once the decision was made?"

Let the participant correct the order. Real decisions can loop back, pick up a new approver or stall. The worksheet should keep that shape without turning into minutes of every meeting.

4. Separate requirements from explanations made afterward

When someone names a missing feature, ask when it became important and which task needed it. Was it a requirement from day one, a concern raised during evaluation or a reason given after the decision?

None of these makes the account dishonest; the distinction tells you what the participant actually saw.

For a price objection, ask what was being compared: subscription cost, implementation effort, contract length, migration work or the wider project budget. Don't assume a discount would have changed anything. Ask about the approval process and the alternatives instead of floating an imaginary cheaper offer.

Don't ask for a competitor's confidential proposal or another company's private information. You can study how they evaluated without collecting documents they aren't allowed to share.

5. Expect more than one explanation

Here is a made-up example. A training team evaluated a new platform and stayed with its existing vendor. The first answer is "We needed better reporting." Walking the timeline, the buyer mentions an upcoming training cycle, a required migration review and no time to finish that review before launch.

Now there are at least three explanations. Reporting decided it, migration uncertainty decided it, or the fixed deadline made any vendor change impractical. One account can't tell you which applies to other buyers.

Useful next moves include studying a completed purchase with a similar deadline, interviewing the implementation owner and testing whether a clearer migration plan answers the concern. Building a reporting feature is one option among several.

6. Fill in an evidence worksheet after the call

Make one row per meaningful claim:

  • Claim: what the participant said influenced the decision.
  • Event: where it sits in the timeline.
  • Basis: direct participation, a document they can discuss or secondhand knowledge.
  • Other explanation: what else could produce the same outcome.
  • Missing perspective: who or what could clear up the doubt.
  • Potential action: a change or test aimed at this specific issue.

Keep the buyer's account separate from your sales notes. If they disagree, record the disagreement. It may reflect different viewpoints, dates or an incomplete record, and none of those is a reason to pick the version you prefer.

7. Compare losses without counting mentions as votes

Group accounts by context: a fixed deadline, an existing contract, a required integration, a particular buying role. A reason that decides one situation may not matter in another.

Track who declined and who you couldn't reach: people willing to explain a loss aren't automatically typical of all lost prospects. Don't turn a small volunteer sample into a percentage of the whole pipeline.

End each round by naming the decision you can now make with more care: tighten the qualification criteria, investigate implementation friction, clarify positioning, test a feature or leave the product alone. Attach the evidence and its limits, so the next person on the team can see why.

Offer to pay for the buyer's time

A buyer who chose someone else owes you nothing, and "a quick call to learn from the loss" is easy to ignore. Paying for their time makes the request fair, though the note still has to say plainly that the call isn't a pitch. With Instant Expert you paste the email or LinkedIn URL of each person who was in the room, and offer a 30-minute call. The invitation shows only your note, the request type and the amount, and you appear as "Requester" on the call, so name yourself, your company and the purpose in the note. You set what each person receives, our fee is added on top, and you're charged only when someone books. They see your note and the amount, have 7 days to respond, and can decline.

Some employers bar staff from accepting payment from vendors. A recipient can have their amount donated to a charity they pick instead, and you pay the same either way; still let them say no if their rules forbid even that.

Rebuild the choice before acting on the reason

  1. 1

    Trigger

    Why did the buying project begin?

  2. 2

    Alternatives

    Which approaches were actually considered?

  3. 3

    Turning point

    Which event changed the choice?

  4. 4

    Approval

    What conditions governed the commitment?

  5. 5

    Next test

    Check the explanation before changing the roadmap.

Follow the decision in time. An objection is more useful once you know when it mattered and which alternative it helped.