How to run reference calls when buying software
Guide · Enterprise · 4 min read · last verified 2026-07-28
A reference call is a conversation with someone who already lives with the software you are considering — an existing customer, asked to describe what the product is like after the demos end. Run well, it is some of the cheapest diligence available in a purchase. Run the way many calls actually go — twenty polite minutes of "so, are you happy with it?" — it mostly confirms whatever you walked in believing.
One caveat frames everything else: the references a vendor hands you are drawn from the happy end of its customer distribution. That is not deception; it is selection doing what selection does, and no vendor volunteers the churned account. The seller's side of this dynamic — how reference calls quietly decide deals — is covered in reference calls decide deals you thought you already won. This piece is the buyer's playbook: choosing who you talk to, asking questions that get past politeness, and weighing what you hear.
Choose the reference before the questions
The person matters more than the question list. Ask the vendor for a customer that resembles you: similar size, a similar stack, an adjacent use case, and — importantly — tenure past the honeymoon. A customer a few weeks after go-live can describe the sales process; a customer approaching a second renewal can describe the product. Ask, politely, whether the vendor can connect you with an account that downgraded or left. Most will decline, and the manner of the declining is itself information. Then go beyond the list entirely: your own network, community forums, people who mention the product publicly. Off-list conversations carry no selection filter, and they run shorter, blunter, and more useful per minute than anything the vendor arranges.
Ask questions that outflank politeness
References want to be kind — to the vendor who asked the favor and to you, the stranger on the call. Direct questions about satisfaction invite ratings, and ratings flatten everything interesting. Ask for stories instead:
- What surprised you after go-live — good or bad?
- If you were doing the rollout again, what would you do differently?
- Who inside your company stopped using it, and why?
- What did you stop doing, or stop paying for, to make room for it?
- Tell me about the last time something broke. What did support actually do?
- If your renewal were tomorrow, what would you push back on?
Each of these asks for a narrative rather than a verdict, and narratives tend to leak the specifics that verdicts conceal. The follow-up matters as much as the opener: when you hear a generality, ask for the example behind it.
Listen to the shape of the answer
Content is only part of what a reference call returns. Listen for form: pauses before praise; generalities where specifics ought to live; warmth about the vendor's people substituting for enthusiasm about the product; excitement about the roadmap standing in for satisfaction with the present. When someone says the team is wonderfully responsive, it is fair to ask what the team has been responding to. None of this is proof — it is signal to triangulate against other evidence. One practical note on candor: consider leaving recording tools off. In a period when AI note-takers join most meetings by default, saying explicitly that this call is just two people and handwritten notes can buy an honesty that no question list will.
Write it down before it fades
Capture verbatim phrases, not summaries. The difference between "support was fine" and "support was fine once we learned to escalate through our account manager" is the finding, and paraphrase destroys it. Put the notes into the same evaluation record as your hands-on results, so the calls are weighed alongside firsthand evidence rather than recalled later as a vague impression. A structured trial answers different questions than a reference call does — how to run a proof of concept with a market intelligence tool covers that side — and a good evaluation record shows both, plus a skeptical read of the vendor's own claims (how to read a vendor comparison page as a buyer).
Know what the call cannot carry
The limits are structural: a reference call is a small sample of someone else's context. Their team, their data, their expectations differ from yours in ways neither side fully sees. One glowing call proves little; so does one bitter one. What starts to mean something is repetition — the same theme surfacing across calls with customers in different situations. Treat references as one leg of diligence alongside the trial and the contract read, feeding the finance conversation that follows (what CFOs ask before approving new software), and the calls will earn their minutes. Treated as the deciding vote, they mostly return the answer the vendor arranged for you to hear.