The reference call is a casting decision

Late in almost every technology selection, someone says it: "Let's speak to a couple of references."

It feels like the moment the evaluation gets real. No more slides, no more demos. Just a customer, someone like you, telling you how it actually went.

So you get on the call. The customer is friendly and clearly knows the product. Implementation "went well". Support is "very responsive". They'd "definitely choose them again". You thank them, tick the box and move on.

Six months after go-live, you discover the things nobody mentioned. The integration that took far longer than planned. The module that never quite worked for your type of building. The feature that was on the roadmap, and stayed there.

The reference didn't lie. You just never heard from the customers who would have told you.

Every reference is selected

I've sat on both sides of this. As a seller, I knew exactly which customers to put forward for which prospect. Not the unhappy ones. Not the ones halfway through a difficult rollout. The ones who'd had a good experience, liked us, and would say so well.

That isn't dishonest. No vendor will put an unhappy customer on the phone with a prospect, and no buyer would expect them to. But it means a reference call isn't a sample. It's a selection.

Think of it as a funnel. Out of all a vendor's customers, some are happy. Of those, some are willing to spend an hour talking to strangers. Of those, the vendor picks the ones who best fit your situation, and best fit the story. By the time someone joins your call, you're hearing from the top of a very narrow funnel.

That doesn't make the conversation worthless. It makes it a specific kind of evidence, with specific limits.

What a reference can and can't tell you

A vendor-selected reference can tell you that the product can work. Somewhere, for someone, it has been implemented and is in use. It can show you what a good implementation looks like, and what the relationship feels like when things go right.

What it can't tell you is whether it will work for you. It doesn't tell you how often implementations go well, what happens when they don't, or how the vendor behaves when a customer is unhappy. It doesn't show you the customers who left.

There's a quieter problem too: reference calls are often vague. "Implementation went well" is an impression, not a fact. Unless you ask specific questions, you collect sentiment instead of evidence.

The questions most buyers ask, and the ones that matter

Most reference calls follow the same script. Are you happy with the product? How is the support? Would you choose them again?

Those questions almost always get a yes. They're the questions the reference was chosen to answer.

Better questions are specific, comparable and hard to answer with enthusiasm alone:

• How long did it take from contract to go-live, and what was the original plan?
• Which integrations did you build, and which one caused the most trouble?
• What did you expect the system to do that it doesn't do today?
• What would you do differently if you started again?
• Which outcome did you expect, and have you measured it?

You won't always get a full answer. But a vague answer to a specific question is useful information in itself.

Make references real evidence

A few habits change the value of references considerably.

Ask for customers like you. Same size, same type of portfolio, same systems around the product, same region. A reference that runs a different estate on a different ERP tells you little about your project.

Ask who left. Ask the vendor which customers stopped using the product in the last two years, and why. How a vendor answers that question tells you a lot, whatever the answer is.

Find one reference yourself. Your network, user groups, a peer at a similar organisation. One conversation the vendor didn't arrange can be worth more than several it did.

Ask every vendor the same questions. If every reference for every vendor gets the same questions, you can compare the answers. If each call is a free conversation, you end up comparing impressions.

Record it as evidence, not as a feeling. Write down what was said, by whom, about which capability, and who arranged the call. "Customer selected by the vendor said go-live took nine months against a plan of six" is evidence. "Reference was positive" isn't.

Where references sit on the evidence ladder

At Prove TDI we treat every statement about a vendor as having a level of confidence. At the bottom is a claim: something the vendor says. Above that, something backed by a source you can point to. Higher still, something confirmed by more than one independent source. At the top, an outcome actually measured in production.

A vendor-selected reference is useful, but it sits lower on that ladder than it feels. It's closer to a claim than it looks, because the vendor chose who says it. A reference you found yourself, asked the same structured questions, sits higher. Several independent customers confirming the same thing sit higher still. A measured outcome sits highest of all.

The mistake isn't using references. It's treating a curated conversation as if it were independent proof.

Three questions before your next reference call

Before you dial in, ask yourself:

1. Who chose this customer, and why?
2. Which specific capability or risk is this call supposed to confirm?
3. How will I record what I hear, so I can compare it with the other vendors?

If you can't answer those, the call will probably make you feel more confident without making you more right.

Less pitch. More proof.

Prove TDI helps workplace, property and facilities teams make technology decisions they can defend. Every statement about a vendor carries a label for what backs it, so a curated story is never mistaken for independent proof.

See how it works at provetdi.com.