Restaurant AI Phone RFP: What to Ask Every Vendor

Most restaurant owners meet the AI phone vendor at the demo, not at the request for proposal. You get a sales deck, a smooth demo line and a proposal whose feature grid matches every other proposal on your desk. By the time the difference shows up — a phone order that takes two minutes to confirm, a modifier the bot mishears, a caller left waiting when the confidence score dips — you have already signed.

That is what an RFP is for. Not a summary of what the vendor does, but a written set of requirements the vendor has to answer, plus a test you can run against the answers. The seven requirements below are the ones that separate a voice stack built for restaurant calls from a general-purpose assistant pointed at a phone line. It is also the procurement-stage document — the one you send to several vendors at once, including us — rather than a feature checklist for a single vendor.

You are not the first to run this process. PolyAI's published guide to writing a conversational AI RFP says an RFP for voice should test how vendors handle accents, noise and the voice tech stack. Accents and code-switching are the two we can answer from our own product facts, and the voice stack is where the rest of these answers come from.

1. Latency: ask for a number, not a promise

Ask every vendor for the response latency on a live inbound call, in milliseconds, and for the method they used to measure it. A conversational voice agent is built from speech-to-text and text-to-speech systems tuned for rapid response so the exchange mimics a natural human phone interaction; at DineCall the response latency is under 800ms. If a vendor will not put a number in the proposal, treat that as the answer: there is not one to give.

2. Language handling: ask how it decides, not which languages it claims

Saying you speak English, Cantonese and Mandarin is the easy part. The hard part is deciding which language the caller is speaking, mid-sentence, without a menu button. Ask the vendor to explain the mechanism in one sentence, and ask what happens on an accent or a code-switched sentence. Ours detects the language the caller is using on the fly — within one to two words — and dynamically switches its vocabulary and accent with no key presses. Our speech recognition is trained on diverse acoustic models, including regional accents and common bilingual phrasing, and when confidence falls below a set threshold the agent politely asks for clarification or redirects to a human operator.

3. Menu grounding: ask what happens with your real modifiers

A restaurant menu is not a price list. It is a stack of modifiers, sizes, substitutions, combos and prices that change. Require each vendor to work from your actual menu and to tell you how a modifier survives into the order. Ours builds a menu knowledge graph that covers the entire menu, including complex modifiers such as extra spicy or sauce on the side, sizes, substitutions, combos and current pricing — and the order that comes out carries the modifier, the quantity and the price as structured fields rather than a note for a human to interpret.

4. Capture: require the payload, not the promise

Ask for a sample of the order payload the system emits, in writing, during the demo. It tells you more about the vendor than any slide does. Ours is a standardized JSON webhook payload emitted on order events: an order ID, the source of the order, the language of the call, a customer record with a masked phone number, the order type, and each line item with its English and Chinese name, quantity, price and modifiers, plus subtotal, tax and total. A vendor who cannot show you a payload has not been evaluated yet — you cannot tell what your kitchen and your books will actually receive.

5. Handoff: ask what happens when the agent is not sure

Every vendor will tell you their agent escalates to a human. Ask for the trigger, the threshold and the notification path instead. Ours hands off when speech confidence falls below 70% or when the caller asks for a human manager: front-of-house staff are alerted immediately by phone ring or dashboard notification, and if the lines are busy a call-back ticket is logged instead. Those three details — the threshold, who gets notified, and what happens when nobody answers — are what you are really buying.

6. Security and call recordings: ask for the specifics

Ask which compliance regime the payments run under, and what happens to call recordings. Ours is fully PCI-DSS compliant, with payments processed through secure Stripe interfaces, so no raw credit card or cardholder verification data is ever seen or stored by our servers. Call recordings are encrypted at rest and in transit using AES-256 and TLS 1.3, one-party versus two-party call-consent rules are supported through optional voice disclosures, and frequent automated vulnerability scans run against the core API layer. A vendor who answers 'we take security seriously' has not answered the question.

7. Deployment: ask what 'go live' includes

Ask for a date, then ask for the list of things that date assumes. Ours: configuration and AI training are typically completed in two to three business days, and that window includes menu digitization, bilingual translation verification and routing tests. Nothing is installed in the restaurant — no hardware installation is required — and the restaurant keeps its existing public phone number, because we provision a localized routing number and the restaurant sets up conditional call forwarding for busy, unanswered or offline calls. If a vendor's go-live date excludes menu digitization, the delay shows up on the first order.

How to score the answers

Score the responses in writing before you speak to anyone again. Give each requirement a pass, a fail or a 'needs a demo', and record the vendor's own words next to the score. A sentence that says 'our system is built on a large language model' is not an answer to 'what is your response latency'. Weight the technical answers above the commercial ones, because any vendor can quote a price.

Then require the price in a shape you can audit: base fee per location, included minutes, the per-minute rate above the allowance, commission on orders, and whether there is a setup fee. Ours, for example, lists a base monthly fee per location, included AI minutes, a per-minute overage rate, zero order commission and no setup fee, with AI-connected time metered by the second and allowances resetting monthly without rollover. Two answers disqualify a vendor on their own: a latency promise with no number, and a refusal to let you call the line yourself.

Then test it yourself before you sign

The written answer is the shortlist. The call is the decision. During the demo, call the line the way a guest would and stay on it: order with a modifier, switch language mid-sentence, ask a question the menu does not answer, and ask for a human. Then ask where the call landed. Our orders land on a real-time kitchen order board that displays incoming orders from phone, web and tables instantly, and table bookings appear immediately in the owner dashboard.

Finally, ask which point-of-sale the tickets land in. DineCall integrates with POS KING, Square, Toast, Clover, SpotOn and NCR Aloha and more, or runs alongside via an open, documented ordering API — and we confirm your exact setup during the demo rather than guessing at it in a proposal.

FAQ