Prepare the fixture
Create a small test menu with a required modifier, an optional add-on, a sold-out item and a pickup cutoff. If reservations are in scope, prepare an allowed party size, an unavailable time and a change to an existing test booking. Ask the vendor to use a safe test environment and a provider-approved payment simulation.
Give each candidate the same menu and policies. Record the version and date. Avoid embedding a preferred answer into the caller's phrasing. The point is to test whether a natural request becomes the intended operational record.
Five ordering cases
- A straightforward order with quantity and pickup time.
- A required modifier that the caller initially leaves out.
- A correction after the agent has already read part of the order.
- An unavailable item followed by an acceptable alternative.
- A request that must go to staff, such as an unresolved payment problem.
For each run, record whether the order was read back, whether the final ticket matched the confirmed request and whether payment state was clear. Do not mark a call as correct because the spoken summary sounded right while the ticket was wrong.
Four reservation cases
Ask for an available table, an unavailable time, a change in party size and a cancellation. Verify the book after every action. If a request falls outside restaurant policy, the agent should follow the configured boundary instead of inventing availability or promising an exception.
Keep these results separate from order-taking performance. A vendor can support one workflow without meeting the other. In Loman's documented product set, OpenTable, Resy and SevenRooms are reservation connections, while POS and order-routing connections serve a different job.
Inspect handoff and failure recovery
Ask to reach a person. Verify the actual receiving line and any useful context the team receives. If the line is busy or unanswered, observe the configured next step. A transfer attempt is not a completed human interaction. Record whether the caller receives a clear expectation.
Ask the vendor to demonstrate an integration interruption safely. Confirm whether the order is held, rejected or routed for staff review. The acceptable response depends on your operating policy, but an ambiguous payment or duplicate ticket should be treated as a serious issue to resolve before launch.
Keep a complete run log
Your log should contain scenario ID, configuration version, time, expected outcome, observed conversation, destination record, pass/fail reason and retest status. Redact personal data. Mark a corrected run as a retest rather than replacing the first result.
Loman's company-reported 99.6% simulated order benchmark does not substitute for these tests. Once the demo is complete, enter your evidence in the scorecard and carry unresolved gates into the decision record. Do not select a winner while a critical requirement remains unknown.
Use one complete synthetic order as a fixture
Ask for two test items, omit one required choice, then correct the quantity after readback. The reviewer records the first outcome and checks the destination record. If setup is corrected, repeat under a new run label without removing the first attempt.
Match the fixture to the documented Toast order path or Square order path when applicable. For reservations, use the OpenTable description as separate scope; an order pass cannot stand in for a booking pass.