When a table becomes unusable during a booked service, the manager needs to record the table and the time it cannot be used, identify every affected booking, and decide where each party can sit. A reservation system should make that work visible to the host team and prevent the table from being offered again during the affected period.
Before buying, ask the vendor to show you how a manager would do those steps. If the system cannot block one physical table for a defined period, find out what manual process is needed and how staff will avoid booking it by mistake.
Decide who owns the table outage
A loose leg, damaged top, or spill that needs repair may take one physical table out of service while the rest of the dining room stays open. The issue is not just the number of seats lost. A single table may be assigned to several guest parties at different times, and each party may need a different solution.
The manager on duty should own the decision to take the table out of use and name a host or other team member to update bookings. That owner also needs to decide when the table can return to service. An estimated repair time is useful, but it should not become an automatic reopening unless someone has confirmed the table is usable.
Record enough detail for the next shift to act:
- The physical table identifier and why it is unavailable.
- The start of the outage and the expected end, if known.
- Each affected booking, including arrival time, party size, and relevant seating requests.
- The replacement table or pending decision for each party.
- Who will contact the guest, if needed, and whether that contact has happened.
Keep the table marked unavailable until the responsible person confirms the repair. If the expected end changes, review later bookings again. A note alone may inform a host, but ask whether it also stops the table from being assigned through every booking channel you use.
Compare ways to handle the outage
The most direct approach is a time-limited block on the physical table, followed by reassignment of its existing bookings. Ask whether a block affects only new availability or also flags reservations already assigned to the table. Those are separate jobs: preventing another booking does not resolve the parties already on the schedule.
A second approach is to remove the table from the active floor plan or make it unavailable for the whole service. This can be practical when repair timing is unknown. It may also withhold more capacity than necessary, so check how easily a manager can restore the table after inspection and whether existing assignments remain visible.
A third approach is a manual exception list. The host records the outage and checks every incoming reservation against the floor plan. This may work for a short service with a small team, but it depends on clear handoffs and repeated checks. It is a poor substitute for a reliable block when bookings arrive through several channels and staff cannot review each one immediately.
Whichever method is available, compare replacement candidates against the full seating window, not just the arrival time. A table that appears empty at 7:00 may already be needed for a later party. Also check physical capacity, accessibility, location requests, and whether combining tables would displace another booking. Do not assume a guest will accept a different arrangement.
When evaluating a restaurant reservation system, ask to see the floor plan and booking list together. Can the manager identify every affected party without opening each reservation individually? Can another host see the reason for a change and the next action?
Use a broken-table worksheet
The following service is hypothetical. Table 4 seats up to four guests and becomes unusable at 6:00 p.m. The manager expects it to remain out of use through the end of service. Two parties were assigned there. The restaurant uses a 90-minute seating window for this exercise; actual timing should follow your operation.
Table 6 seats up to four and is available from 6:00 to 7:30. Table 8 seats up to two and is free for the evening. No other suitable four-seat table is available during the second party's window. These are physical tables, not counts of guest parties.
| Booking | Impact | Candidate and decision | Owner and guest action |
|---|---|---|---|
| 6:00 p.m.; party of 4 | Table 4 unavailable; expected window ends at 7:30. | Move to Table 6, available for the full window and large enough for four. | Host records the move. No guest contact is needed if the seating arrangement still meets the booking's requests. |
| 7:30 p.m.; party of 4 | Table 4 unavailable; expected window ends at 9:00. | Table 8 holds only two. No equivalent table is available, so leave a decision pending rather than assign an undersized table. | Manager reviews options; host contacts the guest only after the manager agrees on an offer. |
The first row has a workable replacement because Table 6 covers the party's whole window and has sufficient capacity. The second row is the important exception. Two empty seats are not a four-person replacement. The manager might check whether another booking can be moved without creating a new conflict, offer a different arrival time, or ask whether the party would accept a different arrangement. Any change that affects the guest needs the guest's agreement.
Record the outcome as well as the intention: “host to call” is not the same as “guest accepted 8:00.” If the guest cannot be reached, leave the action open, identify who will try again, and tell the next host what to do if the party arrives. Do not mark the reservation resolved merely because a message was planned.
If the table is repaired earlier than expected, the manager should inspect it, update its availability, and recheck the reservations before making further changes. A party that has already accepted another arrangement should not be moved back without considering the guest and the rest of the floor plan.
Run a pass-or-fail vendor demonstration
Ask each vendor to demonstrate the same scenario in a training environment using fictional bookings. The exercise should not send a real guest message, process a payment, or dispatch a courier. Have the vendor explain any step that requires a separate tool or staff workaround.
- Block the table. Mark one four-seat table unavailable for the service. Pass if the team can see the outage and prevent a new assignment to that table for the stated period. Fail if staff must rely on an unseen note while the table remains available for assignment.
- Find existing bookings. Show every fictional reservation assigned to that table during the outage. Pass if the manager can identify both affected parties and their relevant details. Fail if an affected reservation is missed or its status is unclear.
- Move the first party. Assign the four-person party to a four-seat table free for its full seating window. Pass if the new assignment is visible to the host team and does not overlap another booking. Fail if the move creates a conflict or leaves staff unsure which table is assigned.
- Handle the exception. With only a two-seat table available for the later party, leave the decision pending and record an owner and next action. Pass if staff can see that the party still needs a solution. Fail if the exercise treats the two-seat table as a valid four-person assignment or silently marks the issue resolved.
- Recover manually. Ask what happens if the manager cannot complete a step in the system. Pass if the vendor can describe a workable staff handoff, how to prevent a duplicate assignment, and how to reconcile the record afterward. Fail if the workaround depends on someone remembering an undocumented change.
Then ask support: “During a busy service, how do we get help if a table block or reassignment does not behave as expected, and what information should we have ready?” Clarify support hours, contact methods, permissions, and whether a manager can see who made changes.
If the practice run succeeds, decide whether to run a separate live service pilot with trained staff. Use real bookings only under your normal operating procedures. Brief the team on who can make changes, how guest contact is handled, and when to revert to the manual list. A successful simulation does not prove that every live-service condition has been covered.
Also ask how bookings from your website, phone, and Google bookings, where available, appear in the same workflow. OpenTable offers reservations, restaurant operations, and a diner discovery network; compare that discovery-led model with direct website bookings according to your needs. Ask each vendor about channel attribution, staff permissions, exports, and fees rather than assuming the same terms.
Request a written quote for the setup and support you need. Separate recurring software charges from any booking-related or other variable fees, and ask about charges for exceptions or additional locations. Compare those quoted costs with the staff work each approach leaves you to do. Fleksa's plans page provides its pricing details, checked November 2026; confirm current availability and terms before deciding.
Take the worksheet to your next vendor call and ask for the exception to be demonstrated, not just described. Compare your reservation requirements with Fleksa and confirm which features and setup are available for your restaurant.
Frequently asked questions
Should I cancel every booking assigned to a broken table?
No. First identify all affected parties and check replacement tables for capacity, timing, and guest requests. If no suitable table exists, decide on an offer and contact the guest before treating the booking as resolved.
Is a note on the floor plan enough?
A note can help staff understand the problem, but it may not stop a new assignment. Ask whether the system actually blocks the physical table for the relevant time and how it flags existing bookings.
When should an unusable table return to availability?
After the responsible manager confirms it is usable. Update the table's status and review affected bookings before offering the space again; an estimated repair time alone is not a confirmation.
