Offer a party several nearby tables when no suitable single table is available, the tables can remain separate without disrupting service, and the guest agrees to the seating arrangement. Treat it as one guest party occupying two physical tables, not as two unrelated reservations.
That distinction matters when a booking changes. Your host needs to see which tables belong to the party, and both tables need protection for the full reservation period. If your system cannot show or maintain that relationship, use a host-managed process rather than offering the arrangement automatically.
Map one party to two physical tables
Start with the floor plan, not the party-size field. Give every physical table a distinct identifier and a realistic seating limit. A table that normally seats four should not become a five-top on the booking screen simply because a chair can be squeezed into an aisle.
Next, identify pairs that are genuinely adjacent for your dining room. Two tables on opposite sides of a busy walkway may be close on a diagram but awkward for conversation and service. Walk the floor and check sightlines, chair clearance, access routes, and whether staff can reach both tables without disturbing other guests.
Set a maximum for each approved pair as well as for each individual table. The pair limit should never exceed the sum of the two table limits, and it can be lower if the room layout makes full occupancy impractical. Decide which table combinations are eligible and which times or service periods need tighter rules.
Hypothetical worksheet: Tables A and B are separate, adjacent four-tops. Each has a maximum of four seats, and the operator allows at most eight guests across this pair. The tables cannot be physically joined, but guests at both tables can see one another. For a six-person party, the host can plan three guests at each table.
| Request or condition | Decision | Reason |
|---|---|---|
| Six guests; A and B free for the full booking | Offer A and B as separate tables | Three guests per table is within both four-seat limits. |
| Four guests; A alone is free | Offer A as one table | The party fits at one table without separation. |
| Nine guests; only A and B are available | Do not offer this pair | Nine exceeds the pair limit of eight. |
| Six guests; B has an overlapping booking | Do not offer A and B for that time | Both physical tables must be available for the full period. |
The boundary is deliberate: this pair works for six guests under these assumptions, but not for nine or when either table is occupied. A different floor plan may need a lower pair limit. If a single table can seat the group comfortably, offer that option first; it avoids asking guests to split their party unnecessarily.
When reviewing reservations software, ask how a single booking can be associated with multiple table identifiers. Also ask whether the availability view accounts for the full booking period at each table, including any turnover time your restaurant chooses to use.
Set the service and guest-expectation rules
Nearby seating is not the same as one shared table. Some groups will be happy to sit in two clusters. Others expect everyone to converse across one surface, share dishes easily, or participate in the same celebration. A booking description should make the difference obvious before the guest confirms.
Use plain language such as: Your party will be seated at two separate tables next to each other. The tables will not be joined. If the tables are close but not directly next to each other, say so instead. Do not describe an arrangement as adjacent if a guest would reasonably expect something closer.
Decide how service will work before opening these bookings. For example:
- Assign one server or designate who coordinates the two tables.
- Agree how the kitchen should receive the order if the party wants food served together.
- Ask whether the group expects one check or separate checks, and follow your normal payment process.
- Tell the host what to do if the guest arrives expecting a single combined table.
These are operating choices, not reasons to assume a booking system coordinates the whole meal. Ask vendors what information staff can see on the reservation and how they would record a seating note. A note is useful only if the people seating and serving the party can find it when they need it.
Also decide when separate seating is unsuitable. A group with accessibility needs may require a particular route or layout. A party with young children may need adults distributed in a specific way. Ask about seating needs without collecting unnecessary detail, and let a host resolve requests the online flow cannot accommodate.
Consider the opportunity cost during busy periods. Holding two four-tops for six guests uses both physical tables, even though two seats remain unused. That may be worthwhile for a longer party booking or a quieter service; it may be less attractive when both tables are likely to be needed separately. Your policy can restrict eligible times without pretending every reservation has the same value.
Test edits, conflicts, and cancellations
The critical question is not just whether a system can display two table names. It is whether the booking and both table allocations remain consistent when a host changes something. Ask the vendor to demonstrate the workflow in a test environment, or use a clearly isolated training setup.
For the hypothetical six-person booking above, run these checks without sending a real guest message, taking a real payment, or dispatching a courier. Use test contact details and disable external actions. If the setup cannot safely isolate those actions, ask the vendor for a demonstration instead.
- Create: Enter one six-person party for A and B. Check that the booking shows both table identifiers and that neither table is offered to another party during the same reservation period.
- Change the time: Move the booking to a period when both tables are free. Check that both allocations move together and the original period is released. Then try a period when B is occupied. The change should not leave A moved while B remains behind or becomes double-booked.
- Change the party size: Reduce the party to four. Decide whether your policy keeps both tables until a host reviews the change or moves the group to one table. Check that the host can see which table remains reserved and which, if any, is released. Increase the party to nine and check that the A-and-B pair is not accepted under the stated eight-seat limit.
- Cancel: Cancel the test booking and check that both table allocations are released. Confirm that the reservation status is clear and the tables can be offered again.
- Inspect the handoff: Open the booking from the views used by the host and service team. Check that the party size, time, status, table identifiers, and separate-table note agree.
Write down the expected result before the demonstration. If a conflict produces an unclear result, ask how staff detect and correct it. In particular, find out whether a failed edit preserves the original reservation intact or requires a manual repair. Do not assume a warning on one screen appears everywhere staff work.
A simulation checks the setup without involving guests. A live service pilot is different: if you choose to run one, use an agreed operating procedure, brief the host, and monitor actual reservations during a limited service period. Use normal guest communications and payment procedures only for genuine bookings, not as practice actions. Keep a manual fallback for any allocation that staff cannot verify.
Decide who can approve and confirm the arrangement
Automatic offers make sense only when your approved pair, capacity rules, availability checks, and guest disclosure can all be applied reliably. Otherwise, have the online request go to a host for review, or ask guests to contact the restaurant for that party size. Confirm with the vendor whether the desired request and approval flow is supported; do not assume that an online form can hold both tables while staff decide.
Give the host a short decision rule: confirm only when both named tables are free for the required period, the party fits the individual and pair limits, the arrangement meets the guest's stated needs, and the guest accepts separate seating. If any condition fails, offer a different time or seating option rather than quietly substituting another layout.
Make responsibility for changes just as clear. Identify who can reassign either table, who checks for conflicts, and how the guest is informed if the arrangement changes. A shift handoff should flag upcoming split-table parties so the next host does not treat one of their tables as spare capacity.
Reservation policy also affects how you handle late arrivals and no-shows. Decide how long both tables remain held and what staff should do when part of the group arrives first. Apply your normal policy consistently and communicate it before confirmation. For more on weighing those decisions, read the guide to reservation no-show costs.
Finally, check how the seating information fits the rest of your restaurant management workflow. A useful booking record should help the host act; it should not require staff to reconstruct the table plan from memory.
Bring your approved table pairs, capacity limits, and the four test outcomes to a vendor conversation. Discuss your requirements with Fleksa and compare the proposed workflow with how your restaurant actually seats parties.
Frequently asked questions
Are adjacent tables the same as a combined table?
No. Adjacent tables remain separate physical tables, even when one party occupies both. A combined table usually means furniture is arranged as one shared seating area. Tell guests which arrangement they are accepting.
Should both tables be reserved under one booking?
One party should have a clear booking record that identifies every table it occupies. Ask how the system protects both tables from conflicting reservations and handles changes; use host review if that relationship cannot be maintained reliably.
What if the party size changes after confirmation?
Recheck each table's limit, the pair limit, availability, and the guest's seating needs. A smaller party may fit at one table; a larger one may exceed the approved pair. Release or add table allocations only after the revised arrangement is confirmed.
