Prepare your restaurant menu for an AI phone-ordering trial

Bring more than a menu PDF to a phone-ordering demo. For each test item, write down the choices a guest must make, the extras that cost money, and what the kitchen should receive. That gives your team a clear answer to compare with the call and the final ticket.

This worksheet is for a restaurant preparing its menu for a trial. It helps you settle the menu rules before judging the agent. Use the phone-ordering trial checklist to follow the full call, payment, and kitchen handoff.

Choose the menu version and the person who owns it

Start with the menu your restaurant intends to offer by phone at the test location. Record where it lives, when you checked it, and who can approve a change. Ask the provider which menu source and format it supports. A printed menu, online menu, and POS menu may show different information; have the manager settle any difference before testing.

List the items you want available in the trial and those that should stay out. Keep location, service period, and pickup or delivery scope explicit. A lunch special or a second store's price should not become an unstated assumption.

Fill out one record for each test item

• Item and size: the exact menu item and the size or variant being ordered.
• Base price: the approved price for that location and ordering channel.
• Required choices: what the guest must choose before the order is complete.
• Optional changes: the allowed additions, removals, and substitutions.
• Selection limits: minimum and maximum choices, whether repeats are allowed, and any choices that cannot go together.
• Extra charges: the price of each allowed extra and the rule for included choices.
• Availability: service hours, location limits, and where staff record a sold-out item.
• Expected ticket: the item, quantity, modifiers, and notes staff should receive.
• Unresolved request: the question or change that needs a person, plus the agreed staff route.

These fields are a preparation record, not an import format. Ask the provider how each rule maps to your actual setup. Keep account credentials and customer information out of the worksheet.

Separate a required choice from a paid extra

A choice can be mandatory without costing extra. A paid addition can be optional. Write those rules separately so neither the test caller nor the reviewer has to guess.

Toast's required-modifier instructions state that an item configured with required modifiers needs a selection before staff or guests can send it to the kitchen. Its multi-select guide separately covers selection limits, duplicate choices, and modifier pricing. Those are POS settings; they do not prove that a particular phone-agent connection supports every rule. Verify your configuration during the trial.

A worked example: define the answer before the call

This is a hypothetical menu item, not a Maple customer order. Suppose a rice bowl costs $12, requires one protein at no extra charge, and permits optional avocado for $2. The guest asks for one chicken bowl with avocado. Your expected item subtotal is $14 before tax, fees, tips, or other charges that your setup may apply.

• Expected item: one rice bowl.
• Required choice: chicken.
• Paid extra: avocado, added once.
• Expected item subtotal: $12 + $2 = $14.
• Missing choice check: if the caller asks only for a bowl, the agreed behavior is to ask for the protein.
• Change check: if the caller removes avocado before checkout, the final ticket and subtotal should reflect that change.

Have the restaurant manager approve the expected ticket first. Then compare it with what the agent confirms and what staff receive. A correct spoken total is not enough if the ticket still contains an extra item.

Agree on sold-out and unsupported requests

Name who changes availability, where that change happens, and how the team checks that the phone agent has received it. Ask the provider about update timing; do not assume that a change in one screen appears everywhere at once. Include a test in which an item is unavailable and another in which it returns.

For a request outside the approved menu rules, define the next step with staff. Examples include an unlisted substitution or a change that the POS cannot represent. Agree when the agent should ask a question, explain a limit, or transfer the caller. The worksheet should show the approved action, not require the reviewer to invent it during the demo.

Keep a short change log during the trial

For each change, record the item, old rule, new rule, person who approved it, and time of the next test. Keep the expected ticket with that record. If a call fails, first check which menu version the trial used; changing the menu and the test expectation at the same time makes the result hard to interpret.

Choose cases from your actual menu: a required choice, a paid extra, repeated extras if supported, a removed ingredient, a sold-out item, and an item available only during a defined service period. Record the call result and the resulting ticket separately. For a broader comparison across vendors, use our restaurant voice AI demo guide.

Bring the worksheet to the setup discussion

Ask the provider to walk through the record and identify unsupported rules before launch. Confirm the specific POS, location, menu source, update process, and staff handoff. A logo on an integration list is a starting point for that discussion.

Maple lists phone ordering and supported POS integrations under Pro; Voice covers answering and FAQs. Start with the integration directory, then bring your menu worksheet and expected ticket to a Maple demo.

Published by Maple. This AI-assisted guide combines linked POS documentation with an original preparation worksheet and a hypothetical order. It does not report a customer trial or guarantee a particular integration's modifier support.