On this page

Confirm the final details, then inspect the write

The guest’s last agreed details are the source for the booking request. A conversation can contain several dates or party sizes before the final choice. Test whether a correction replaces the earlier value rather than leaving two conflicting instructions. The destination record should match what was confirmed.

Use a synthetic guest and an approved test environment where possible. If the provider requires a controlled production test, obtain the restaurant’s permission and ensure that any real capacity used is released through the agreed cleanup process. The workbench itself performs none of these actions.

Require a usable reservation reference

  • Venue or location identifier.
  • Reservation ID returned by the system of record.
  • Confirmed local date, time, timezone and party size.
  • The accepted booking state, separate from a message-delivery state.
  • Source request reference and timestamp for later reconciliation.

Do not expose more guest information than staff need to verify the test. Evidence can refer to a redacted screenshot or a test record in your controlled workspace. This site should not receive real guest names, phone numbers, payment data or account credentials.

Test the interruption window

The highest-risk moment is after the booking system accepts a request but before the caller receives the final response. Simulate that case using a method the integration provider supports. Confirm that the recovery process searches for the existing booking before attempting another create request.

A repeated call should not automatically become a second reservation. Staff or the integration need a documented way to identify the intended booking without merging unrelated parties. A matching surname alone is weak evidence, especially in a busy venue.

Do not confuse reminders with booking success

A confirmation text or email may be sent by the reservation platform, the phone provider or another connected service. Document who owns it. The absence of a message does not prove the reservation failed; the presence of a message does not excuse an incorrect record.

For the creation fixtures, verify the reservation book first, then check any guest notification as a separate event. Finish by confirming how test bookings are cleaned up and how evidence is retained. The test result should remain reviewable after the temporary booking is removed.

What a creation pass must show

Use a synthetic booking request with an explicit venue, local date, time and party size. A pass needs one intended reservation, a usable reference and a final state matching the confirmed request. A successful audio readback or delivered message cannot replace the reservation-book evidence.

For a supported Loman implementation, compare the intended fields with its OpenTable booking description or Resy booking description. Preserve the reference for the change and cancellation cases instead of starting unrelated bookings each time.