Ask better customer reference questions

A customer reference call is most useful when it helps you understand a decision you are about to make. Asking whether someone likes a product will usually produce an opinion. Asking how their team prepared for a specific change can reveal work your own plan has missed.

Before arranging the call, write down the uncertainty you want to reduce. Perhaps you need to understand implementation effort, ongoing administration or how a system fits a particular workflow. Choose one primary question. You can learn other things along the way, but a clear purpose helps you select the right person and use the time well.

Find a reference who knows the relevant work

Start with experience rather than company prestige. Ask the vendor who at the reference company was directly involved in the part of the project you care about. An executive sponsor can describe the buying decision. An administrator can describe configuration and maintenance. A team leader can describe adoption. These perspectives complement each other, but they are not interchangeable.

Request a short description of the reference’s situation before the call: their role, when the project happened, the scope they observed and any major differences from your environment. You do not need a dossier. You need enough information to judge whether the conversation can answer your question.

Suppose you are replacing a spreadsheet process used by twelve people. A reference from a large enterprise may still be helpful, but ask whether their implementation relied on a dedicated team that you will not have. The important comparison is the work and resources involved, not the number of employees on the company website.

Set expectations before you start

Send a brief note describing your purpose, proposed topics and available time. Tell the reference who will attend. If a vendor representative will join, make that visible. Let the reference decline questions outside their experience or information they are not permitted to share.

Ask permission before recording. Explain who would receive the recording and how you would use it. The GOV.UK guidance on informed consent is written for research, but offers a helpful practical example of explaining participation and data use clearly. Your organization should apply its own rules to the call and its records.

For a short conversation, one interviewer and one note taker may be enough. Agree who will ask follow-up questions so the reference does not face a rapid sequence of unrelated prompts. Keep several minutes free at the end for anything the reference thinks you missed.

Use six questions as a working sequence

The sequence below moves from context to experience to advice. Adapt the wording to your decision. It is a guide for listening, so there is no need to force every question into the call if an earlier answer reveals something worth exploring.

1. What were you trying to change, and what did the process look like before? Ask for the actual starting point. Learn which teams were involved and what problem was important enough to act on.
2. What did you have to prepare before the first useful version was working? Invite details about data, people, approvals and outside help. Ask what the vendor did and what the customer did.
3. Can you describe one moment when the implementation became difficult? A particular incident is easier to interpret than a general rating. Follow the sequence: what happened, who responded and how it ended.
4. What does your team have to do to keep it working now? Separate initial effort from recurring effort. Ask who owns administration and what happens when that person is unavailable.
5. Which part of your experience would be different for a team like ours? Briefly describe your circumstances. Give the reference permission to say that their experience may not transfer.
6. If you started again, what would you do earlier or differently? Look for a practical change you can consider in your own plan. Avoid turning their hindsight into a guarantee about your outcome.

The GOV.UK guide to in-depth interviews recommends open, neutral questions and prompts that explore specific experience. That is a useful discipline here. “How did you handle the first data import?” leaves room for an honest answer. “The import was easy, right?” tells the participant which answer you expect.

Follow the details that change your plan

When a reference says onboarding took longer than expected, ask what they mean. Was the delay caused by scheduling, cleaning data, training or a missing feature? These imply different actions for your team. A broad label such as “difficult implementation” hides the part you need to understand.

If they mention a successful outcome, ask how they observed it. Did they compare a recurring task before and after the change? Was the result measured, estimated or simply felt by the team? You can record all three, provided you preserve the distinction.

Do not pressure the reference for figures they cannot share. A description of the measurement method may be useful even when the number is private. For example, learning that someone counted manual corrections each week can help you design your own evaluation without borrowing their result.

A short pause can be more useful than another question. Give the reference time to remember the event. If you need clarification, repeat the part you heard and ask whether you understood it correctly. That reduces the risk of building your notes around an assumption.

Separate observations from your interpretation

Use three columns in your notes: what the person reported, the context attached to it and the implication for your decision. This keeps a direct account from becoming an unsupported conclusion as it passes through your team.

An example might read: the reference assigned one administrator during rollout; the deployment covered three departments and included a data migration; our project plan needs a named owner and a better estimate of their time. The first two points describe the reference’s circumstances. The third is your proposed response, which still needs discussion.

Flag uncertainties explicitly. If the reference joined after implementation, note that their account of the early phase is secondhand. If the product has changed since their project, ask the vendor to explain the difference separately. Do not silently merge the two accounts.

Close the call and use what you learned

Finish by repeating two or three points that could affect your plan and asking whether you have captured them fairly. Thank the reference for the time. Ask before contacting them again, and keep any later request focused.

Afterward, compare your original uncertainty with the notes. What did the call answer? What remains open? Which point requires another source? A reference call can reveal useful experience, but one customer’s story cannot establish how every implementation will go.

Turn the findings into actions. Add an internal owner, request a sample migration plan, schedule a technical discussion or revise your evaluation criteria. Assign those actions to people and dates. Otherwise a thoughtful conversation can become a document that nobody uses.

Your next step is small: draft the six questions for one upcoming decision. Put your own circumstances beside them, remove anything that will not affect the decision and send the topics in advance. A prepared conversation gives the reference a fair chance to help and gives your team something more concrete than enthusiasm to take away.