To close part of a dining room while keeping the rest bookable, mark the affected tables or section unavailable for the relevant service, account for reservations already assigned there, and check that the remaining tables can accommodate the bookings you plan to accept. The key buying question is whether your reservation system lets an authorized manager do that without closing the whole venue or relying on a risky workaround.
Do not judge the workflow by a floor-plan screen alone. Ask the vendor to show what happens to existing bookings, availability across booking channels, and the reservations made while the section is closed. Then test reopening: those newer bookings must remain intact when the closed tables become available again.
Decide who controls the closure
Put one manager in charge of the change for each affected service. That person should identify the tables to close, confirm the start and end times, review affected bookings, and approve reopening. A host can help check assignments and contact guests, but there should be one clear owner of the final floor plan.
The right setup depends on the reason for the closure. A dining room repair may make several tables unusable for an entire evening. A staffing shortage may call for a lower booking limit rather than a physical closure. A private event may occupy the same tables for only part of a service. In each case, specify the affected times as well as the tables; a table that is unavailable at dinner might still be usable at lunch.
Also decide which conditions cannot be compromised. For example, a party that needs an accessible table may not be movable to any open seat. Two small tables may seat four people in total but cannot necessarily accommodate one party of four. Table combinations, turn times, walk-ins, and staffing all affect what you can actually sell.
Before comparing screens, write down the outcome you need: the closed area must not receive new bookings during the restricted period, while suitable tables elsewhere remain available. Ask who has permission to make that change and whether the system records who made it.
Work out the remaining capacity
The following worksheet is hypothetical. It describes one dinner time slot, not the total number of guests the restaurant can serve over a full evening. The manager owns the closure and capacity decision; the host owns the booking review and guest communication after the manager approves a plan.
| Step and owner | Situation | Decision or result |
|---|---|---|
| Manager: mark closure | Three of eight physical tables are unavailable for the slot. | Keep five physical tables open; restrict the three closed tables for that period. |
| Host: list affected bookings | Two parties of two are assigned to two of the closed tables. | Review both bookings individually before accepting more reservations. |
| Manager: calculate capacity | The five open tables each seat up to four guests. Three are already assigned to parties of four. | Two open tables remain. Together they have eight seats, but each party must fit an available table. |
| Manager and host: decide | The two affected parties can each use one remaining table, with their requirements met. | Move both assignments if the system supports it. All five open tables are then occupied for the slot; accept no more table bookings for it. |
The arithmetic is straightforward: five open tables provide up to 20 seats in that slot. Three parties of four and two parties of two account for 16 guests across all five tables. The four unused seats do not make another table available. They are spare seats at occupied tables, not capacity for another party.
If either affected party cannot use the proposed replacement table, the manager must choose another time, arrange a suitable alternative, or contact the guest about options. Do not silently move a party to a table that cannot meet its needs. The host should record the agreed change and verify the reservation's time, party size, status, and relevant requests.
Repeat the calculation for every affected time window. A booking that overlaps the start or end of a closure matters even if its arrival time falls outside it. Ask the vendor how the system handles duration, overlapping reservations, joined tables, and booking limits. If you hold tables for walk-ins, subtract those tables from what you intend to make bookable online.
Compare workflows, effort, and guest impact
Start with the most precise approach the system can demonstrate. A table- or section-level restriction can be useful when it applies only to the affected times and leaves other suitable tables available. Ask whether it prevents new assignments to the closed area and what happens to reservations already there. Also ask whether changes apply to the restaurant website and any connected booking channels at the same time.
If a system instead offers a service-wide booking limit, ask how that limit interacts with individual table assignments. A lower limit may reduce demand, but it does not necessarily stop a booking from being assigned to a closed table. Staff may need to monitor assignments and adjust them manually. That adds work during service and creates a risk of promising a table that is not usable.
A manual approach can be reasonable for a short, predictable closure if one person maintains a reliable list and the team can promptly update every booking channel. Its cost is staff time and the possibility of a missed change. Closing all online reservations and taking calls may prevent further online bookings, but it also asks guests to use a different channel and may leave usable tables unsold. Treat it as a fallback, not the default answer to a partial closure.
Compare costs using written quotes and an estimate of the work your team will actually do. Ask about setup, ongoing software charges, channel fees, and any charges for changes or support. A quoted processing fee, if applicable, is not the all-in operating cost. Include staff time and exception handling in your own comparison, and distinguish fixed charges from costs that vary with bookings. Ask a qualified adviser about contract or tax treatment when needed.
OpenTable offers reservation and restaurant-operations tools alongside a diner discovery network. That marketplace model is different from a direct reservation path on a restaurant's website. Compare them based on the channels you want to manage, then ask each vendor about section restrictions, permissions, exports, channel attribution, and fees. Do not assume the same closure controls apply across every channel.
Fleksa offers direct restaurant reservations and Google reservation paths where available. Ask to see how an applicable setup handles this particular closure and reopening workflow. The table reservations documentation can help you prepare questions about the booking experience. For current Fleksa pricing, consult Fleksa plans, checked November 2026, and confirm the applicable setup in a quote.
Test closing and reopening before you choose
Use a vendor-provided demonstration or a safe test environment with fictional bookings. Confirm in advance that the exercise cannot create a real payment, send a guest message, or dispatch a courier. A simulated check is not a live service pilot: it lets you inspect the workflow without affecting actual guests. If a vendor cannot provide a safe way to perform it, ask for a demonstration and discuss how you would verify the process before relying on it.
Set up fictional tables and bookings that resemble your floor. Give each booking a distinct identifier, local date and time, party size, status, and an appropriate special request. Record the starting assignments and count. Then ask the person acting as manager to close one section for a defined period and review the affected bookings.
- Check the closure. Try to make a fictional booking for the restricted period. It should not be assigned to a closed table. A suitable open table should remain bookable if capacity is available.
- Handle existing bookings. Identify every fictional party affected by the closure. Reassign only those that fit, and record any booking that needs a manual decision. Check that no booking has disappeared or changed without authorization.
- Add a booking during the closure. Create one more fictional booking on an eligible open table. Record its identifier, time, party size, status, and assignment.
- Reopen the section. End the restriction and check that the previously closed tables can be considered for suitable new bookings. Compare the complete booking list and assignments with the records from before reopening.
Pass: the closed tables were unavailable during the restriction; appropriate open tables remained available; reopening makes the section available again without duplicating, removing, or displacing any existing booking. The booking added during the closure must still have the same identity and details. A conflict or unexplained change is a failure even if the floor plan looks correct.
Save screenshots or a written step-by-step record, including the time window, table assignments, booking count, and any warning shown. Ask whether the system has a history of changes and whether permissions can restrict who closes or reopens a section. Also test an overlap at the closure boundary and a party that cannot fit the remaining tables.
If the requirement fails, use a documented manual fallback only if the team can carry it out reliably: stop new bookings for the affected period where necessary, keep one authoritative list, contact affected guests through normal approved channels, and have the manager reconcile the list before reopening. Do not assume that a restriction in one channel automatically updates another. If the workload is too high or the channels cannot be controlled, choose a different workflow or keep the affected period closed to online bookings.
Put the decision into service
Give the host team a short handoff: affected tables, closure times, bookings needing attention, walk-in policy, and the person authorized to reopen. When the section returns, compare the live booking list against the manager's record before accepting that the floor is ready. A live service pilot uses real operational conditions and needs a named owner, a fallback, and a clear way to stop if the process causes conflicts; it is separate from the fictional simulation.
If you are changing systems as well as closing a section, assign a cutover owner. With authorized access and a supported method, reconcile booking counts and preserve each booking's identity, local date and time, party size, status, and appropriate special requests. Ask vendors what they can export or import; do not assume either capability. The broader restaurant management software workflow is worth checking if several staff members need the same operating picture.
Next step: Bring your floor plan and a typical affected service to a demonstration. Compare the workflow with your current process, then ask Fleksa to show the applicable capabilities in its restaurant reservation system, including how your team would verify reopening.
Frequently asked questions
Can I close some tables without closing online reservations?
Possibly. Ask the vendor to demonstrate a time-specific table or section restriction and show that suitable tables elsewhere remain bookable across your active channels.
What happens to bookings already assigned to a closed section?
Review each one before accepting more bookings. If a suitable table is available, confirm how to change the assignment; otherwise, decide on an alternative and contact the guest as needed.
Is the remaining seat count the same as booking capacity?
No. Capacity also depends on available physical tables, party sizes, overlaps, table combinations, guest requirements, and any tables held for walk-ins.
