Writing a Voice AI RFP: The Questions That Actually Matter

A voice AI RFP works when it swaps vague checkboxes — "Do you support AI?" — for specific, testable questions a vendor cannot answer with marketing. The questions that actually matter fall into six areas: how the assistant is grounded in your content, which languages it truly supports, how it meets your security bar, how and how fast it deploys, what it integrates with, and what you are contractually owed. Get those right and the shortlist sorts itself.

Think of this as the procurement companion to our voice AI buyer's checklist: where that piece helps you decide what you need, this one gives you the question set to put in front of vendors — and the follow-ups that separate a real platform from a good demo.

Why most RFPs fail at voice AI

Traditional software RFPs run on feature checkboxes, and voice AI quietly defeats them. "Supports multiple languages" scores a yes for a vendor that machine-translates an English-only flow and a yes for one that detects and switches languages mid-conversation — two very different products behind the same tick. The same trap hides inside "AI-powered," "enterprise-grade security," and "easy integration." The fix is to write questions whose answers are specific and demonstrable: numbers, named standards, described processes, and a live demo on your own content.

A simple discipline helps: for every capability that matters, ask one question that forces a number or a name, and one that forces a description of how it works. Vague answers to sharp questions tell you as much as the answers themselves.

Grounding and accuracy

Start here, because this section decides whether the assistant is trustworthy or merely fluent. A raw language model will confidently invent answers; a grounded one retrieves from your sources before it speaks. Ask the vendor to describe the mechanism that keeps replies tied to your content — the pattern you want to hear is retrieval-augmented generation, where every answer is pulled from your documents rather than the model's imagination. Then press on the operational reality:

• How does the assistant handle a question that is not in our knowledge base — does it say it does not know, or does it guess?
• How do we add, correct, and retire content, and how soon do changes take effect?
• Can you demonstrate on our documents during evaluation, rather than a canned dataset?
• What analytics surface the questions it could not answer, so we know what to add next?

That last question matters more than it looks: an assistant that reports its own unmet queries — alongside volume, intents, and resolution rate — turns every gap into a to-do list instead of a mystery.

Languages

If you serve a multilingual public, treat language as a core requirement, not a line item. Separate real multilingual support from bolted-on translation with three questions: How many languages are supported, and which ones specifically? Are they auto-detected, or must the user pick from a menu? Can the assistant switch languages mid-conversation when a person starts in one and continues in another? For reference, Kuyil detects and switches across 50+ languages automatically, with no settings menu — a reasonable bar to hold every vendor to.

Security and compliance

This is where InfoSec earns its seat at the table, and where vague answers should cost the most points. Anchor the section to named standards and concrete controls rather than adjectives. Ask for the vendor's posture against SOC 2 and ISO 27001, alignment with GDPR and CCPA, and, if you handle protected health information, whether they are HIPAA-ready and will sign a BAA. Then get specific about how your data is handled:

• Is data encrypted in transit and at rest, and is each customer's data kept isolated?
• Do you train public models on our data? (The answer you want is a flat no.)
• What are the retention and deletion options — can we configure retention and auto-purge?
• What access controls exist — SSO via OIDC or SAML, and role-based access for admins, editors, viewers, and auditors?
• Can we get audit logs, penetration-test summaries, and a DPA on request?
• Where is data processed, and can it stay in-region or run on-premise — even air-gapped — if we require it?

Our security page maps how Kuyil answers each of these, and it doubles as a template for what a complete response looks like. If a vendor cannot address isolation, encryption, retention, and access control without escalating, that is itself a data point.

Deployment and timeline

Timelines expose whether a vendor has done this before. Ask for realistic ranges by deployment type and what drives them. Honest answers look something like this: a website assistant can go live in days; a first kiosk typically takes about four to six weeks through discovery, build, tuning, pilot, and go-live; deeper integrations run roughly eight to twelve weeks. Be wary of anyone promising a fully tuned lobby kiosk "next week" — far-field acoustics need on-site work. Ask, too, what a pilot looks like: a structured 60- to 90-day pilot with agreed success metrics signals a vendor that expects to be measured.

Integrations

An assistant that cannot reach your systems is an island. List the systems it must touch and ask about each specifically, rather than accepting "we integrate with everything." Useful prompts: How do staff get notified — Slack, Teams, email, SMS? How do captured leads or requests reach our CRM or ticketing system? Do you support SSO through Azure AD, Google Workspace, or Okta? Are there REST APIs and webhooks so we can wire up anything not on your list? Industry-specific systems belong here too — EHR and scheduling in healthcare, SIS and LMS on campus, event platforms and badge printers at events. Match the question list to your stack, and treat "custom integration" answers as scope to price, not to wave away.

SLA, support, and commercials

Finish with what you are actually owed. Ask for the uptime SLA in writing — 99.9% is a reasonable bar — how support is structured, and who owns tuning and content updates after go-live. On pricing, insist on the full shape rather than a headline number: is it a flat subscription, and are interactions unlimited or metered per message? Are there setup fees? Is hardware included or quoted separately? Predictable, published pricing — for example, a website assistant at $299 per month and a kiosk at $500 per kiosk per month, both with unlimited interactions and no per-message fees — is far easier to defend to finance than a usage meter that spikes exactly when the assistant succeeds. Our product overview, and a structured head-to-head such as Kuyil vs Intercom Fin, can help you frame apples-to-apples questions across vendors.

Scoring the answers

An RFP is only as good as how you read it. Weight the sections by what will actually make or break your deployment — for most physical-space projects that is grounding, languages, and security, not the length of the feature list. Score specificity: a vendor who gives numbers, names standards, and offers to demo on your content should outrank one who returns confident adjectives. And insist on a live proof-of-concept on your own knowledge base before you sign. The RFP narrows the field; a demo on your content is what tells you the truth.