How to test restaurant voice AI with a large menu

Choose a phone-ordering agent by the orders it can complete from your menu. Ask it to distinguish similar dishes, collect required choices, handle an unavailable item, and send the agreed order to the right place. A menu-size claim alone does not show whether those steps work.

For a restaurant with many dishes and modifiers, the useful comparison is a shared test with expected results written down first. This guide proposes that test. It does not rank vendors by measured performance or report a customer trial.

What should a large-menu test cover?

Include different menu rules, not just more item names. Start with the menu preparation worksheet so the item names, prices, choices, and expected tickets are settled before the calls.

Test case	Expected behavior	Inspect afterward
Two dishes with similar names	Clarify which dish the caller means	The intended item on the ticket
A required size or protein	Ask for the missing choice	The selected option and its price
Several toppings with a selection limit	Follow the agreed menu rule	Selections, quantities, and charges
An unavailable item	Explain the limit and offer an approved next step	No unavailable item submitted
A dish the restaurant does not sell	Clarify or decline instead of inventing it	No invented item or price
A correction before checkout	Confirm the revised order	No leftover item or duplicate charge

Toast documents required modifier selections and separate multi-select, duplicate-choice, and pricing settings. These are POS rules. They do not prove that any particular phone-agent connection supports your configuration.

How do you run the same test on each provider?

1. Fix the menu version. Record the location, menu date, active service hours, and which system supplies availability.
2. Write an expected result for each case. Include the item, choices, total, and whether an order or a staff handoff should result.
3. Use the same cases. Mix common orders with less common dishes and similar names. Agree with each provider on a test setup that will not charge a guest or send unwanted food to the kitchen.
4. Read the result staff receive. Compare the spoken confirmation with the POS record or other agreed destination. Keep a missing result distinct from a wrong result.
5. Repeat after a controlled change. Change one available item or modifier rule, confirm that the provider has received the update, and repeat the affected cases.

What should you count?

Keep correct completed orders, incorrect submitted orders, unsupported requests, appropriate refusals, and staff handoffs separate. Record the attempted cases as well as the results. A provider that declines every request would submit no wrong orders but would not take useful orders either.

For example, a hypothetical test might contain eight valid orders and two requests for unavailable items. Completing all eight valid orders and correctly declining both unavailable requests is different from declining all ten. This is an illustration of scoring, not a Maple result or a recommended pass rate.

Agree on which failures stop the trial. A wrong dish reaching the kitchen may need a different response from an unclear question that the agent safely transfers to staff. A small scripted test cannot establish performance across all callers, accents, noise conditions, or menu combinations.

What should you get in writing before launch?

Ask about the supported item count, nested choices, location-specific menus, update process, unavailable-item handling, and fallback when an order cannot finish. Obtain answers for your actual configuration. Do not infer those details from an integration logo or a general menu-size statement.

Maple's published plans separate answering and FAQs in Voice from ordering and supported integrations in Pro. Bring your menu to a phone-ordering trial and confirm the supported rules and resulting ticket. This guide does not establish a tested menu-capacity limit.

Compare the same billing period, location count, and included workflow in written quotes. For a named comparison, see the Maple and Loman evaluation guide. For broader demos, use the shared vendor test checklist.

Published by Maple. This AI-assisted guide uses linked POS documentation and an original proposed test method. It does not report an independent vendor benchmark or a customer outcome.