Test restaurant reservation availability before offering a table

Define the request precisely

A meaningful availability request identifies the venue, local service date, party size and requested time or time range. A multi-location brand cannot infer the correct restaurant from a shared name. A late-night service may cross midnight, so the calendar date and service date need explicit interpretation.

Record the venue’s configured timezone in an IANA format such as America/Chicago, not a fixed UTC offset. Offsets change with daylight saving rules. Ask the implementation owner how ambiguous or nonexistent local times are handled, and include the applicable transition dates in testing if the restaurant operates then.

Test more than one offered slot

• A normal available slot with the expected party size.
• A time with no availability and a supported alternative.
• A party size outside the automatic-booking limit.
• A slot that becomes unavailable before final confirmation.
• A location or date correction made during the same conversation.

The integration should carry the guest’s final choice into booking creation. If it offers two alternatives, verify it creates the one selected, not the first result returned. If the guest changes the party size, rerun availability for the new party instead of reusing an earlier response.

Separate availability from policy

The reservation system may expose an available time while the restaurant still has rules about large parties, special events or deposits. Identify which restrictions are enforced by the booking platform and which require a staff decision. Do not assume a generic availability result contains every policy.

A phone service should not invent capacity when the book returns no suitable options. Define the allowed fallback: offer another time, capture a request through an approved process or transfer to staff. A waitlist request and a confirmed reservation are different outcomes and should be described differently.

Evidence to keep

Capture the request parameters, the offered response, the guest’s final selection and the resulting booking reference if creation follows. Record the test timestamp and timezone. If a stale slot is rejected, retain the rejection and the response given to the guest.

The workbench includes stale-availability and party-size fixtures. It supplies expected outcomes, not live inventory. Test only through an approved environment or controlled restaurant process; this public site does not reserve or release capacity.

A disappearing-slot test

Illustrative fixture: a party of four is offered 7:00 p.m. at the test venue. Before confirmation, an approved test action removes that availability. Expected behavior: the system rechecks, explains that the original option is no longer available and offers only supported alternatives or a staff handoff.

Ask how the availability workflow described on Loman’s OpenTable page and Resy page behaves in your configuration. Do not use real guest capacity for this test without an approved setup and cleanup plan.