The vendor has passed your RFP and the demo went well. Now they offer a reference customer: thirty minutes with someone who will say good things. You need to know something more specific. Will their results transfer to your calls, your telephony, your languages and your team?

A reference call can answer that, but only if you run it as an interview with a method, not as a friendly chat. This guide gives you a 30-minute structure that checks comparability first, then how results were measured and by whom, then what went wrong and how the vendor behaved. It ends with a one-page sheet for recording the answers, including the answers you could not get.

It is written for the evaluator in a contact centre, usually in CX operations, IT or procurement, who is in the last stage of choosing a voice AI vendor. Scoring written RFP answers is covered in the RFP checklist; demo and production testing in vendor evaluation.

NextLevel.AI is a voice AI vendor and publishes cases of its own, so it has an interest in how buyers read references and cases. This guide applies to any vendor, including NextLevel.

What a reference can and cannot prove

A reference is one customer, chosen by the vendor, describing their own experience. That makes it useful and limited at the same time.

What it can show: that the vendor has at least one live deployment it is willing to expose; how the vendor behaved during delivery and when something broke; which problems a similar buyer met; and whether that buyer would choose the vendor again.

What it cannot show on its own: that the results are typical, or that they will happen for you. US advertising guidance on consumer endorsements makes the same point: an endorser's experience is likely to be read as representative of what others will achieve, so an advertiser without substantiation for that must disclose the generally expected performance (16 CFR 255.2(b)). A private reference call is not an advertisement, but the logic holds. One good experience is not a forecast.

Two biases to keep in mind:

  • Selection. Vendors offer their happiest customers. Ask whether you can speak to a customer whose deployment had problems, or one that is smaller and more like you.
  • Relationship. Reference customers may have commercial ties to the vendor, such as discounts, co-marketing or a partnership. Ask directly; it is a fair question.

The aim is not to catch anyone out. It is to learn which parts of their experience apply to yours.

Establish comparability first

Spend the first ten minutes here. If the deployment is not comparable to yours, the results that follow tell you little, however good they sound.

DimensionAskWhy it matters
Call types"Which call reasons does the agent handle, and which go to people?"A booking agent and a Tier-1 support agent face different problems
Volume"Roughly how many calls a day does the agent take?"Low volume hides scaling and concurrency issues
Direction"Inbound, outbound, or both?"Outbound has different legal and quality questions
Telephony"Which contact-centre platform or phone system, and how is the agent connected?"Integration is often where deployments differ most
Languages and accents"Which languages, and do callers switch mid-call?"Results in one language do not transfer to another
Region"Where are your callers, and where is data processed?"Regulation, accents and data residency vary by market
Systems"Which CRM, ticketing or booking systems does it read and write?"Write-back is where many failures are found
Time live"How long has it been in production?"A three-week deployment has not met its first seasonal peak
Who did the work"Vendor, a partner, or your own team?"You may not get the same people

Send this table to the vendor before the call and ask for the reference that matches most of it. That turns the vendor's choice of reference into evidence: if no comparable customer is offered, that is an answer too.

Mark each dimension as a match, a partial match or no match. If the important ones don't match, say so in your notes and treat the rest of the call as evidence about the vendor's behaviour, not about your likely results.

Questions about results and how they were measured

Most reference calls stop at "it works great". These questions turn a claim into something you can weigh.

  1. "What did you measure, and what was it before?" A result without a baseline is a level, not an improvement.
  2. "Who measured it?" Your own reporting, the vendor's dashboard, or an independent review. Each is useful; they are not the same.
  3. "What was the denominator?" "Resolved 60% of calls" means different things if it is all calls, calls the agent answered, or calls in two chosen scenarios.
  4. "Over what period?" A pilot month, the first quarter, or a full year including peaks.
  5. "What else changed at the same time?" New staff, a new IVR, a seasonal dip. Any of these can move the same numbers.
  6. "What didn't improve, or got worse?" Every deployment has a weak spot. A reference who cannot name one has either not looked or not been asked.
  7. "Did the vendor's published figures match your own?" If the vendor publishes a case about this customer, check that the customer recognises the numbers.

Write down the answer and its source separately: "reference says, from their own CRM report" is stronger than "reference says, from memory".

Questions about delivery, failures and support

The second half of the call is where references are most useful, because it is about behaviour you will experience directly.

  1. "How long from contract to first live call, and was that what you were told?" Plans and outcomes both matter.
  2. "What broke in the first month?" Ask for one specific incident: what happened, who noticed, how long it took to fix.
  3. "How did the vendor respond when something went wrong?" Named people or a ticket queue? Did they explain the cause?
  4. "How are changes handled?" New scenarios, prompt changes and knowledge updates: who makes them, how long they take, and whether they are billed separately.
  5. "What did you have to provide that you didn't expect?" Internal effort is a real cost.
  6. "What would you do differently?" Often the most useful answer of the call.
  7. "Would you choose them again, for the same scope?" And if the answer hesitates, ask why.

Recording and weighing the answers

Use one sheet per reference. Record every answer as confirmed (the reference could say and give a source), stated (said, without a source), or unknown (could not or would not say). Keep unknowns visible. An unknown is not a zero and not a pass.

Reference sheet: comparability, measurement and delivery rows, each marked confirmed, stated or unknown, plus deal-breakers kept separate.
One sheet per reference. Fictional example entries; deal-breakers are never averaged away.
SectionItemAnswerStatusSource
ComparabilityCall types"Order status and returns; refunds go to people"ConfirmedReference's routing description
ComparabilityTelephony"Same platform as ours, connected over SIP"Stated—
ComparabilityLanguagesNot asked in timeUnknown—
ResultsBaseline and metric"Transfers fell from about half to about a third of calls in scope"StatedFrom memory
ResultsWho measured"Our own weekly report"ConfirmedReport named
DeliveryFirst-month incident"Calendar write-back failed for two days; vendor fixed and explained"ConfirmedIncident ticket mentioned
DeliveryWould choose again"Yes, for this scope"Stated—

The rows above are fictional, to show the format. A copy-ready sheet is available to download (CSV).

Two rules for weighing:

  • Deal-breakers stand alone. If something you require fails, such as no comparable telephony or an unresolved data concern, record it as a deal-breaker. Do not let a strong average across other rows hide it.
  • Weigh comparable references more. One closely comparable reference with confirmed answers tells you more than three generic ones with stated answers.

After two or three reference calls, compare the sheets side by side. Repeated themes, good or bad, are the signal.

Where NextLevel fits

NextLevel publishes case studies with results reported for those deployments by the vendor, not independently audited. Of the nine case cards on that page (read 9 Nov 2026), none names a US geography, one is labelled United Kingdom and five are labelled UAE or KSA; four are labelled POC. If your callers are in the US or UK, treat their results as evidence about the vendor's work in another market, and use the comparability questions above to decide what transfers. A POC result is a proof of concept, not a production result.

Next step: ask NextLevel which published cases match your scope on a call booked from the pricing page. Bring your call types, telephony, languages and region, and use the comparability table to judge the answer.

Frequently asked questions

How many vendor references should we check?

There is no standard number. Prioritise comparability over count: one closely comparable reference tells you more than several generic ones.

Can we ask for a reference whose deployment had problems?

Yes. Ask for a customer who had an incident or a slow start and stayed. How a vendor behaves when things go wrong is the most transferable evidence.

Should we trust the vendor's published case study figures?

Treat them as reported by the vendor for that deployment. Ask the reference whether they recognise the figures and how they were measured.

What if the reference won't answer a question?

Record it as unknown, not as a pass or a fail. If it is a deal-breaker question, find the answer another way before you sign.

Sources

About the Author

NE
NextLevel.AI Editorial Team
NextLevel.AI Editorial Team

The NextLevel.AI Editorial Team publishes evidence-led guides to conversational and voice AI. Articles distinguish confirmed capabilities from configuration-specific guidance and recommended practices.