Manage restaurant booking changes without double work

A guest books for four, emails to ask for six and then calls during service to move the time. The request itself may be simple. The difficulty is making sure the guest, the host and the person preparing the dining room all work from the same confirmed details.

For an independent restaurant, a useful booking-change process starts with one reservation record and a clear distinction between a request and an accepted change. The workflow below is a suggested approach to test with your own team and reservation provider.

Choose where the confirmed booking lives

Identify the system that holds your live reservation record. Staff should check that record before confirming a change received by phone, email or a website form. A conversation about a booking should carry its reference or enough information to locate it reliably.

Avoid keeping a second diary that people update only when there is time. If you need a printed service sheet, show when it was produced and agree how later changes reach the shift team. The sheet is a snapshot, so it needs a clearly defined handover when the live record changes.

Give the duty host responsibility for checking unresolved requests before service. Name a backup for breaks and shift changes. A message received by the restaurant needs an owner even when the person who first read it is unavailable.

Make the request easy to understand

Whether a guest calls or sends a message, capture the same essentials: the existing date and time, the booking name or reference, what they want to change, and how you will confirm the answer.

Ask only for details needed to process that request. A change of arrival time should not make a returning guest repeat an entire enquiry form. For additional requirements that need discussion, route the conversation to an appropriate member of staff rather than promising suitability through an automated reply.

Use distinct messages for distinct outcomes:

• Request received: the team has the proposed change and will check it.
• Change confirmed: the reservation record now contains the accepted details.
• Alternative offered: the requested arrangement is unavailable, and the guest needs to choose.
• Original booking retained: the existing reservation remains in place while an alternative is discussed, according to your process and provider’s rules.

Decide how long an offered alternative can be held and communicate that clearly. Check the reservation system’s actual hold behaviour rather than assuming an unsent proposal reserves a table.

Check the room before confirming

Review the whole arrangement: party size, table configuration, arrival time, expected table duration and surrounding reservations. Define which changes staff can approve directly and which need the duty manager’s decision.

If a guest moves from four people to six, the available time may stay the same while the suitable table changes. If they move later, the original table may be needed for another sitting. The final confirmation should match the accepted arrangement in the live record.

After saving, check the guest-facing message and tell the relevant shift staff what changed. Use a short handover such as “Booking reference 214: six guests at 19:30, updated from four at 19:00”. This is an illustrative format, not real guest information.

Use existing messaging and waitlist features carefully

Your reservation provider may already support the necessary communication. OpenTable describes direct messaging between restaurants and guests, including saved message templates. Its direct-messaging overview is an example of keeping booking conversations closer to the reservation workflow. Check current availability and settings for your own account.

Templates still need the right facts. Include the final date, time and party size in a confirmation, and review it before sending when a member of staff has handled an exception. Do not let a generic acknowledgement look like a confirmed amendment.

OpenTable also describes an online waitlist with queue updates and configurable party sizes. If you use a waitlist, explain its status to the guest. Joining a queue should not be presented as having a confirmed table at a particular time unless that is what your system has actually confirmed.

A worked example: a larger party on a busy evening

Suppose a neighbourhood restaurant receives a request to increase a Saturday reservation from four to six and arrive half an hour later. This is a hypothetical example of the process.

The host locates the existing booking and records the requested changes. The room plan cannot accommodate six at the requested time, but a suitable table is available earlier. The host offers that alternative and explains what happens to the original reservation while the guest decides.

When the guest accepts, the host updates the live record, checks that no duplicate reservation remains and sends a confirmation containing all three accepted details: date, time and party size. The shift handover highlights the revised table arrangement.

If the guest does not reply, the request stays visible with a next action. The team follows the agreed process instead of silently treating the proposal as accepted or cancelling the original reservation by assumption.

Test the journey from a guest’s phone

Use a test booking to try a time change, a larger party, an unavailable request and a cancellation. Read each message on a phone. Check that links open the correct booking and that failed actions produce a useful next step.

Also test a message arriving near service, a staff handover and an interrupted connection. Decide how the team will record changes temporarily during an outage and reconcile them afterwards. Check for duplicate bookings before resuming normal operation.

Track the number of requests requiring a second clarification, pending requests at service time and mismatches between the live record and the shift handover. These are suggested measures for your own pilot, not industry benchmarks.

Our restaurant and hospitality overview connects booking with the wider website journey. Where enquiries arrive through several channels, integrations and connected systems can support a process that your team has first agreed and tested.