Seat an incomplete party when you can protect the needed seats, tell service who is still expected, and accommodate the remaining guests without disrupting another booking. Hold the party when the missing guests' arrival is uncertain, the table may be needed for someone else, or your service plan depends on everyone arriving together.
Whichever choice the host makes, the reservation record should distinguish the guests physically present from the total still expected. A simple “seated” status alone may leave a server thinking the whole party has arrived. Before buying restaurant reservation partial party arrival software, ask how staff can see and update both counts during a busy shift.
Compare seating now with holding the table
Start with the table, not just the reservation status. Can the available physical table fit the full party? If it cannot, seating the first arrivals there may create a second move when their companions arrive. A table that fits the guests present but not the expected party is not a complete seating plan.
Next, consider the rest of the floor. A four-seat table occupied by two early arrivals is still committed to the full party if two more people are expected. Those unused chairs are not available to another party just because they are empty. Check the next reservation for that table and whether the kitchen and server can handle staggered ordering.
Seating now can make sense when the table is ready, the remaining guests have a reasonable arrival estimate, and the server understands that more covers may join. It also gives the first arrivals a place to wait. Ask whether they would like to be seated and explain any practical limits on holding the table.
Holding the party near the host stand may be better when the table is not ready, a larger table is needed, or the remaining guests cannot say when they will arrive. The tradeoff is a more crowded waiting area and a possible delay for the guests already present. Give them a clear update rather than leaving them to guess.
Set a house policy that gives hosts room to make a judgment. For example, a manager might allow partial seating when the full party fits and the next booking is protected, but require a check-in before holding a table past a busy-service cutoff. Make sure the policy tells staff who can make exceptions and how to record them.
Track arrivals without losing the expected count
At a minimum, staff need to see the reservation name, local date and time, booked party size, number physically present, table assignment, and a clear indication that more guests are expected. A note can explain the decision, but it should not be the only place a busy host must search for the count.
Separate these three numbers:
- Booked covers: the party size on the reservation before any agreed change.
- Present covers: the people who have physically arrived, whether waiting or seated.
- Remaining expected covers: people still expected after any confirmed change to the party size.
For example, a booking for six with four present and no confirmed change has two remaining expected covers. The physical table must have six usable seats if the entire party is to sit together. That is one table assignment for one guest party, not six tables or six separate reservations.
Ask a vendor to show what happens when a host marks a reservation seated while only some guests are present. Can the team retain the original booking size and also see how many are at the table? If there is no dedicated partial-arrival status, can an agreed note and a reliable staff handoff provide the same clarity? Ask how easily that information can be found from the floor view and reservation list.
A restaurant reservation system should fit the way the host stand works, not force staff to treat every arrival as all-or-nothing. Also ask whether staff can see the booking channel, including the restaurant website and Google bookings where available, when resolving a change.
Worksheet: a four-person booking with two arrivals
Hypothetical example: A party booked for four arrives in two groups. Two guests are at the host stand, and they say the other two are on their way. One physical table with four usable seats is ready. Another party is booked for that table later, so the host must consider the available service window before committing it.
The worksheet compares the choices using the same starting facts. “Expected” means people the restaurant still plans to accommodate, not people who are already in the building.
| Choice | Present / still expected | Table decision | Record and handoff |
|---|---|---|---|
| Seat the two now | 2 present / 2 expected | Assign the four-seat table to the whole party. | Record partial arrival and tell the server two more guests are expected. |
| Hold the party | 2 present / 2 expected | Keep the table available for the party according to house policy; do not mark it occupied. | Record that two are waiting and when staff should check again. |
| Revise after confirmation | 2 present / 0 expected if the other two will not come | Keep or change the table according to the floor plan. | Record the agreed party-size change and notify the server. |
If the host seats the first two, the decision follows from the table fitting all four and the later booking still being workable. The server should know that two chairs remain reserved for the same party. The host can then direct the remaining guests to the table when they arrive.
If the timing of the later booking makes that commitment impractical, holding the party while checking alternatives may be the safer choice. The host should give the waiting guests an update and involve a manager if the policy does not resolve the conflict. Do not silently reduce the booking to two just to make the floor plan look available.
These alternatives are operational choices, not a claim that any particular product has the statuses shown. In a product demonstration, ask the vendor to walk through each one using the labels and screens staff would actually use.
Revise the count and notify service
Change the expected party size when the guest or an authorized staff member confirms a change, not simply because someone is late. If two guests from a four-person booking will no longer attend, record the revised expected total as two and, where the system permits, retain the original booking size or a note explaining the change. The server can then stop expecting the other two.
If more guests arrive than booked, check physical capacity before changing the count. A four-seat table cannot safely be treated as a six-seat table merely by editing a reservation. The host may need a different table or a manager's decision. Keep the party informed while staff check the floor.
Agree on a short handoff: reservation name, table, guests seated, guests still expected, and any relevant timing decision. Use the team's normal communication method as well as the reservation record. A note that nobody sees during service is not a complete handoff.
Check who can edit or cancel a booking and whether the system records who made a change. Ask how the team retrieves an earlier value if a count is changed by mistake. If reservations and the restaurant POS system share information, ask the vendor to demonstrate exactly which counts and updates appear in each place. Do not assume an update in one screen reaches every other screen.
Run a practical acceptance check
Before selecting software, have a host and a server walk through the four-person example in a demo or practice environment. Use fictional guest details. This is a simulation: it must not send a real guest message, charge a card, or dispatch a courier.
- Create a fictional booking for four and record that two guests have arrived.
- Assign one four-seat table to the party and show the server where to find the two remaining expected covers.
- Record the arrival of the other two. Confirm that the team can now see four present and none remaining expected.
- Reset the scenario. Instead, confirm that the other two will not attend, revise the expected count, and show the server the change.
- Try an erroneous edit and ask how staff would correct it and understand what changed.
Accept the workflow only if staff can keep the table commitment clear, find the arrival count without hunting through unrelated screens, and communicate a confirmed change to service. If a step relies on a manual note or verbal update, decide whether the team can use it consistently. Ask the vendor to demonstrate the actual process rather than assuming a feature from its name.
After the simulation, a separate live service pilot can check whether the workflow holds up during a real shift. Use your normal guest communication and approval procedures, assign a manager to monitor the handoff, and review any missed updates afterward. Do not use fictional practice bookings as live guest reservations.
Compare your reservation requirements with the workflows available from Fleksa. Start with the restaurant management software and ask for a walkthrough of partial arrivals, count changes, and the host-to-server handoff.
Frequently asked questions
Should a restaurant always seat an incomplete party?
No. Seat the guests when the full party fits, the table commitment works for the floor, and service knows who is still expected. Hold them when those conditions are uncertain or house policy calls for a manager's decision.
Does marking a reservation seated mean every guest has arrived?
Not necessarily. Ask how the software represents partial arrivals and make sure staff can distinguish the seated guests from those still expected. If it cannot show both clearly, establish and test a reliable handoff.
When should the host reduce the reservation count?
Reduce the expected count after a guest or authorized staff member confirms that fewer people will attend. Record the change, retain the original count or an explanation where possible, and tell the server.
