Restaurant AI phone launch tests: calls, tickets and rollback

Test the public entry path

Use an authorized outside test line to call the planned entry point. Verify the correct restaurant and location answer. Check a normal-hours and a configured after-hours case without assuming the kitchen accepts orders whenever the AI answers. Record the configuration version and test date.

Test the staff route in both directions required by your setup. Confirm there is no forwarding loop and that the receiving team can identify the call's purpose. For a hosted PBX, verify that unrelated extensions and routes remain as intended.

Inspect an order in the destination system

If ordering is in scope, place a provider-approved test order with a required modifier and a mid-call correction. Check item, quantity, modifier, location, fulfillment detail and payment state in the actual destination record. Then test an unavailable item and a kitchen cutoff.

A clear spoken readback is useful but insufficient. The ticket must reflect the final confirmed request. Loman's company-reported 99.6% order accuracy comes from a proprietary simulated 1,000-call benchmark. Your launch test verifies your configuration, not that benchmark.

Inspect the reservation lifecycle

If reservations are in scope, test an available time, an unavailable time, a change and a cancellation. Verify the same booking record at every step. Include a request outside the restaurant's policy and confirm that the agent follows the configured boundary or escalates appropriately.

Keep the reservation test separate from ordering. OpenTable, Resy and SevenRooms handle bookings; POS and order connections serve a different workflow. Passing one branch is not evidence that the other is configured.

Test a controlled failure and recovery

Ask the vendor or administrator to demonstrate a safe failure scenario in an approved environment. Observe what happens when the required system cannot complete the request. The caller should not receive an unsupported promise, and the restaurant should know where the unresolved item appears.

Then restore the prior phone route and place another outside test call. Confirm the old path works and inspect transactions that may have been in flight. A successful rollback test should be documented, not assumed from a settings screenshot.

Use a go / hold decision

Go only when the scoped workflow, phone route, staff fallback and restoration procedure have been verified by the responsible owners. Hold if any gate is unknown or failed. A partial success is useful evidence, but it does not justify exposing untested critical paths to guests.

During the limited pilot, review outcomes and hidden staff work before expanding. Save the planner export with the test log in the restaurant's approved system. Recheck affected tests after any change to menus, routing or integrations.

Customer evidence for your rollout

Keep a one-row record for every launch gate

Use: test ID; intended route; configuration version; expected result; actual result; evidence reference; owner; retest status. A failed test stays in the record when the corrected configuration passes. A blocked test stays unknown, not passed.

Match transaction cases to the relevant Loman Toast order path or OpenTable booking path. Test their failure handling separately from the public number and restoration route.