On this page

Find the right reservation before changing it

A caller may have multiple upcoming bookings or may be calling for someone else. Define the restaurant’s permitted matching and verification process with the integration owner. Do not assume a familiar phone number grants permission to alter every booking associated with it. The test should include two synthetic records that are similar enough to expose ambiguous matching.

Once the target is identified, keep its system reference through the operation. If an implementation uses a replace-and-cancel flow rather than an in-place modification, document that behavior and prove that failure cannot strand both bookings or remove the only valid one.

Recheck the changed request

Changing from two guests to six or moving from early service to a busy slot can require new availability. The original reservation does not guarantee that the new request can be accommodated. A failed modification should leave a clear, verified state and a truthful explanation to the caller.

Inspect more than the updated field. Confirm the location, guest association, original reference or documented replacement reference, and any relevant notes remain correct. Avoid silently losing accessibility requests or preferences. Do not enter sensitive real guest details into this public workbench.

Cancellation is a state change, not a deletion assumption

  • Confirm the intended booking before submitting a cancellation.
  • Verify the resulting state in the reservation system.
  • Check what happens if the cancellation request is repeated.
  • Check whether a late status event can incorrectly reopen the booking.
  • Separate cancellation of the booking from any deposit or fee process.

A reservation cancellation may have financial consequences governed by the restaurant’s terms and reservation platform. This reference does not authorize refunds, waive fees or change policy. Include those boundaries in your implementation review without using this tool to carry out the action.

Make the failure behavior explicit

For each lifecycle write, test accepted, rejected and unknown outcomes. A definitive rejection can be explained. An unknown response requires lookup and reconciliation before another write. Staff need to know which screen or record establishes the current state.

The test-pack workbench includes successful change, unavailable change, cancellation and repeated-cancellation fixtures. Record the evidence for the old state and the final state. A pass without evidence remains incomplete in the tool.

A rejected change should not erase the original booking

Illustrative case: a booking for two requests a change to six, but the new party size is unavailable. Verify that the original accepted booking remains in its documented state and that the caller hears a truthful result. If the system uses replacement records, inspect both records and the failure path.

Use Loman’s Resy lifecycle description or its SevenRooms reservation article to identify claimed operations, then request the exact supported modification and cancellation behavior for your account.