When a group books several tables separately and asks to sit together, keep each reservation intact while you check whether the request works. Confirm which bookings belong to the group, map the people to physical tables, and agree on an alternative before changing any existing commitment.
A note saying “together” is not enough. The host needs to know which parties are connected, who can approve a change, when each party expects to arrive, and whether the proposed tables will still be available. The workflow also needs to work when the answer is no.
Identify the related bookings
Start with the guest making the request. Ask for the reservation names, times, and party sizes they expect to be connected. Confirm each booking against your reservation list rather than searching by a shared surname alone. Two parties with similar names may have nothing to do with each other.
Agree on one contact for coordinating the request, but do not assume that person can change or cancel everyone else's booking. Decide who may approve a different time, table arrangement, or cancellation for each party. If a change affects another booking, confirm it with the person authorized under your restaurant's process.
Keep the shared note short and useful to the host team: the related reservation references, the request to sit together, the coordinating contact, and the current decision. Record access needs or other relevant requests only where staff need them to seat and serve the guests. Do not disclose unrelated guests' names, contact details, or plans to the group contact.
A link between reservations can be a software feature or a controlled manual note. When evaluating a restaurant reservation system, ask how staff can find every related booking from any one of them. Also ask who can see or edit the notes, whether changes leave a history, and what happens to the link if one party cancels. Have the vendor demonstrate the workflow rather than assuming a tag creates a true group record.
Pass: A host can identify the intended parties and their current statuses without opening unrelated guest records. Fail: Staff have only a vague name or a note on one booking that others cannot find.
Map the parties to physical tables
Use the following fictional example as a worksheet. Three parties have separate reservations for the same evening. They want to sit near one another. The restaurant has identified three adjacent physical tables with capacities of four, four, and two. Each table is available from 6:00 p.m. through the planned meal period, and no existing commitment requires it during that period.
The table shows three guest parties and three physical tables, not one reservation for ten people. The proposed tables can accommodate the individual parties without splitting them. Their arrival times differ, so the host still needs to decide how long to hold each table and explain that decision.
| Booking | Party and arrival | Original commitment | Proposed nearby table |
|---|---|---|---|
| Adams | 4 guests, 6:00 p.m. | Table for 4 at 6:00 | A: capacity 4 |
| Brown | 4 guests, 6:15 p.m. | Table for 4 at 6:15 | B: capacity 4 |
| Chen | 2 guests, 6:30 p.m. | Table for 2 at 6:30 | C: capacity 2 |
Under these assumptions, the host can propose the three nearby tables while retaining each party's booked time. The first party may be seated at 6:00 rather than waiting until 6:30. If the guests want to begin together, ask whether they prefer to wait; do not silently move the earlier reservations. Confirm how long each table can be held under the restaurant's policy.
Check more than the seat count. Can guests converse across the proposed tables? Is the route accessible for anyone who needs it? Would joining the furniture obstruct service or reduce capacity? If the parties expect one combined table rather than adjacent tables, say which arrangement is actually available.
Finally, check the full service window, not just the arrival times. A table shown as open at 6:00 may already be promised to another party later in the evening. If you cannot hold it for the expected meal, find another arrangement or decline the joint request. Do not solve one group's request by quietly displacing another reservation.
Pass: Each party fits at its proposed table, the tables are genuinely nearby, and their availability covers the planned seating period. Fail: The plan relies on an extra chair at a full table, an unapproved time change, or a table already committed to another party.
Approve the request or offer a clear alternative
Set an approval rule before the host makes promises. For example, a host may check the layout and propose available tables, while a manager approves changes that affect another reservation or require a longer hold than usual. The right division depends on your operation; the important part is that staff know who can make the decision during service.
If the adjacent tables are unavailable, offer only options you can actually honor. Depending on the floor plan, those might be separate tables at the original times, nearby tables at a different time, or a smaller number of guests seated together. Explain any trade-off and ask the affected parties to agree before changing their bookings.
Use precise language: “We can seat your parties at three adjacent tables at their existing reservation times” is different from “We can put everyone at one table.” Include the decision, times, seating arrangement, and any hold policy in the confirmation. If the request remains pending, tell the contact when to expect an answer and who will follow up.
Until an authorized change is accepted and recorded, retain the original reservations. A denied group request is not a cancellation. If the restaurant cannot fulfill an original commitment, contact the affected guest promptly and resolve that separately; do not treat silence as consent to a new arrangement.
Pass: Staff can see who approved the arrangement and what each party was told. Fail: A guest has been promised a combined table that the floor plan cannot provide, or an original reservation was changed merely because the request was made.
Practice late changes without affecting guests
Before a busy shift, walk through the worksheet with a manager and host. Use a sandbox or another clearly isolated practice method with fictional bookings. Confirm that the exercise cannot send guest messages, take a payment, or trigger a courier dispatch. Do not use real guest details merely to make the scenario feel realistic.
In the simulation, have the two-person party arrive late or change its party size. Check whether the host can find the other related reservations, see the original booking and the approved seating plan, and decide what needs another approval. Then simulate a cancellation of one party. The other two bookings should remain identifiable and retain their recorded commitments unless their authorized contacts agree to changes.
Also rehearse a handoff: one host records the request, and another takes over without a verbal explanation. Can the second host tell whether the request is pending, approved, or declined? Can they see which tables are held and when the guests were last contacted? If not, simplify the note or assign one place for the decision to live.
A simulated check verifies the workflow without involving guests. A live service pilot is different: use it only with actual requests, trained staff, and a manager ready to handle exceptions. Review what happened after service and correct the process; do not assume a successful practice guarantees the same result on a full floor.
Pass: A second host can follow the change, identify the decision owner, and preserve unaffected bookings. Fail: A cancellation removes the only useful group note, the host cannot tell which version is current, or the practice produces a real guest communication.
Choose a workflow your team can maintain
Whether you use software links, tags, or a manual reference, ask vendors to show the complete path: find the related bookings, record approval, update one party, and keep the others visible. Ask about staff permissions, history, exports, and how bookings are attributed to their channels. If Google bookings matter to your restaurant, ask which booking paths are available for your location and how those reservations appear to hosts.
Consider the rest of the shift as well. A link is useful only if the floor plan and reservation status are current when the host needs them. Your broader restaurant management software may be part of that handoff, so ask what staff must enter twice and who resolves conflicting information.
For costs, request a written quote covering the reservation workflow, setup, support, and any relevant channel fees. Compare the quoted total and its scope rather than assuming a reservation charge is the entire operating cost. Fleksa's plans page has its current pricing; pricing details were checked in November 2026. Confirm availability and the terms for your setup before deciding.
Late arrivals and partial cancellations also affect table use. For a separate way to assess that exposure, see the guide to measuring the cost of reservation no-shows.
Next step: Take the worksheet to your next vendor conversation. Compare your requirements with Fleksa and confirm current availability before choosing a workflow.
Frequently asked questions
Should separate bookings become one reservation?
Not necessarily. Keeping the individual bookings can preserve their times, party sizes, and contacts. If you want to combine them, confirm the effects on each commitment and obtain the appropriate approvals first.
What if only some of the group can sit together?
Offer the arrangement you can honor and explain which parties would be apart. Keep the original reservations unless the affected guests agree to a change.
Who should be told when one party cancels?
Follow your restaurant's communication process. Update the staff handling the group and contact the coordinator when the cancellation affects the agreed seating plan, without sharing unnecessary guest information.
