When a reservation changes unexpectedly, start with the current booking, then compare it with any available change history and guest communication. Identify the account associated with the edit, check which physical table and time slots are affected, and assign one person to resolve the conflict. An account name is a useful lead, but it does not always prove which person made the change.
Before moving a booking back to its original time, confirm what the guest expects and whether that time is still available. The aim is a service plan the host team can use: one current booking, a workable table assignment and a clear record of who will contact the guest if needed.
Start with the fields that affect the floor
Find the reservation by its booking reference when possible. Names alone can be ambiguous, especially for repeat guests or two parties with the same surname. Check the local service date and time, party size, booking status, assigned physical table and any seating requests that affect placement. Also note the booking channel and the contact details appropriate for reaching the guest.
A time change is not the only edit that can create a conflict. A party of two becoming a party of six may no longer fit at the assigned table. A status changed from canceled to active can put a party back on a floor that has already been filled. A request for accessible seating may make an otherwise available table unsuitable.
Separate the number of guest parties from the number of physical tables. One party might need two tables pushed together, while one table may serve several parties over the course of an evening. For each affected table, check its seating capacity and the time it is expected to be occupied. Your service plan should also account for the setup and clearing time your team normally needs.
Ask the software vendor which fields appear in the history, whether changes made through each booking channel are included, and how long records remain available. Also ask whether the system records the previous value, the new value and the account or channel responsible. Do not assume that a current table assignment reveals how the booking got there.
Compare the booking, history and guest messages
Open the current reservation alongside its history. Record the original and revised values, the time of the edit, the associated account or channel, and the status of any guest notice. If the system shows a shared login, ask the team member responsible for that shift who had access. A shared account can narrow the investigation without identifying the person who clicked save.
Then check the communication record. A message marked sent may show that a notice was issued; it does not establish that the guest read it or agreed to the change. A missing message record does not necessarily mean no one spoke to the guest. A host may have handled a phone call outside the reservation system. Ask the shift team before treating an empty message field as an answer.
Use the following hypothetical example to see how a short investigation log can support a service decision. The times, account and parties are fictitious. The restaurant uses 90-minute table slots for this service.
| Record | Booking time | Actor or source | Guest notice |
|---|---|---|---|
| Original booking: party of four | 6:00 p.m. | Website booking record | Original time appears in the booking record |
| Time edit | Changed from 6:00 to 6:30 p.m. | Host account shown in history; individual not yet confirmed | Not shown in the message record |
| Current booking | 6:30 p.m., assigned to Table A | Current reservation view | Guest's expected time not yet confirmed |
| Later booking: separate party of four | 7:30 p.m., assigned to Table A | Current reservation view | Not relevant to the time edit |
The table separates what the record shows from what the team still needs to learn. It does not establish why the time changed or whether the guest requested it. Keep the log in an authorized place, with only the guest details staff need to resolve the issue. Avoid copying a full message history into a shift note when a brief status will do.
For the current record and channel details, your team can start with its reservations workflow. Ask the vendor how to inspect edits and communication records in the tools your restaurant actually uses.
Resolve the time conflict without guessing
In the example, Table A seats four. A 6:30 p.m. start with a 90-minute slot runs until 8:00 p.m., overlapping the separate 7:30 p.m. party by 30 minutes. Both parties fit the table's capacity individually, but the table cannot serve both during that overlap.
Moving the first party back to 6:00 p.m. would make its slot end at 7:30 p.m. under the same assumption. That removes the scheduled overlap on paper, but leaves no buffer between parties and may not match the guest's expectation. It is not a reliable fix until the host checks the guest's time and the restaurant's turnover needs.
Suppose Table B also seats four and is available from 6:30 to 8:00 p.m., with no other party or operational hold requiring it. The host can tentatively assign the first party to Table B while keeping the second party at Table A. Before treating that as final, check whether Table B meets the first party's seating needs and whether the guest expects 6:30 p.m. If either check fails, the host needs another suitable table or an agreed time change. If neither is available, a manager should decide how to handle the conflict with the guests; the host should not silently overbook a table.
Also look beyond the two records. A table held for a large party, a seating restriction or an event setup can make an apparently open space unavailable. If your booking tool calculates availability automatically, ask how it handles turn times, joined tables and manual holds. If staff maintain part of the floor plan separately, reconcile that plan before publishing the shift assignment.
Give the correction an owner
Before service, name one person to own the resolution. That person does not have to perform every task, but should be responsible for making sure each task is complete. A practical handoff can look like this:
- Investigate: The host checks the booking reference, history, current table and message record, then asks the relevant shift team about any phone conversation.
- Decide: The floor lead checks capacity, seating needs and neighboring bookings. The lead either approves a workable assignment or escalates the conflict.
- Contact: One named person confirms the expected time with the guest when the record is unclear. Record the outcome and next action, rather than assuming a sent notice settled the matter.
- Update: The assigned host makes the agreed change in the booking and floor plan, then checks that the current reservation matches the plan.
- Brief: The service lead tells the incoming host team which table is assigned and flags anything still awaiting a response.
If the guest cannot be reached, leave a clear pending note and set a time for the floor lead to revisit it. Do not mark the change as guest-approved. The team should know both the intended seating plan and its unresolved assumption.
To reduce repeat investigations, give staff individual accounts where the system permits, review who can edit bookings, and agree on a consistent way to record phone changes. Ask how permissions work for managers, hosts and external booking channels. If you use several tools, ask which one is the source of the current floor plan and how conflicting updates are reconciled. A broader restaurant management software review can help you map those handoffs.
Next step: Bring a real, authorized booking workflow to a vendor conversation and ask to see how an edit, its actor, the guest notice and the final table assignment are recorded. Compare that workflow and current availability with Fleksa's restaurant reservation system.
Frequently asked questions
Does the account in a change history prove who edited a booking?
Not always. A shared account or channel identifier may not identify an individual. Check account access and shift notes, and ask the team member responsible before drawing a conclusion.
Should a host restore the original reservation time?
Only after checking what the guest expects and whether the original time works with the current floor plan. A later change may have been requested by the guest, even if the reason is not visible in the booking record.
What if the reservation system has no usable change history?
Compare the current booking with available messages and shift notes, then confirm unclear details with the guest. Ask the vendor what history, permissions and exports are available so your team can choose a reliable process for future changes.
