A party size creates an unusable gap when the table assigned to it has more seats than the party needs, while another party cannot use those spare seats. A two-person party at a four-top, for example, leaves two empty seats, but those seats are not available to a separate party under an exclusive-table seating policy.
Before changing a booking rule, compare the whole floor plan for the same reservation window. Count blocked seats, seats held by booked parties, spare seats at their assigned tables, and seats at entirely free tables. Then check whether the free tables actually fit the party sizes guests are requesting. Empty chairs alone do not tell you whether a rule is costing you bookings.
Separate blocked, booked and available seats
Start with one reservation window and the physical tables that can be used during it. A physical table is not the same thing as a guest party: one table may seat a party of two even though it has four chairs. For this worksheet, assume each party gets one table and tables are not combined or shared.
Use these four categories:
- Blocked seats: capacity at a physical table taken out of service for that window. Record the reason, such as a private event or a maintenance issue.
- Booked seats: the number of guests in confirmed parties assigned to usable tables.
- Stranded seats: unused chairs at those assigned tables that cannot be sold to another party under the seating policy.
- Available seats: capacity at completely free, usable tables. Keep their table sizes visible; six available seats spread across three two-tops do not fit a party of four.
These categories should add up to the total physical seats in the floor plan. If they do not, check for an unassigned reservation, a table counted twice, or a block that covers only part of the window. Also record the reservation time window and the assumed dining duration. A table that is free at 7 p.m. but needed for another confirmed party shortly afterward may not be available for a new reservation that overlaps it.
The following example is hypothetical. It compares allocations for one window, assumes all bookings overlap, and excludes walk-ins and table combinations. No guest is being contacted and no live booking is being changed.
Map two-top and four-top demand to gaps
The fictional floor has four two-tops and three four-tops: seven physical tables with 20 seats. One four-top is blocked, leaving 16 usable seats. Three confirmed parties of two need tables. In the current allocation, one party sits at a two-top and two parties sit at four-tops.
The worksheet compares that allocation with an alternative that places all three parties at two-tops. Both arrangements keep every confirmed party. The last row then applies the same hypothetical demand to each arrangement.
| Measure | Current allocation | Alternative allocation |
|---|---|---|
| Physical capacity | 20 seats | 20 seats |
| Blocked capacity | 4 seats at one four-top | 4 seats at one four-top |
| Booked guests | 6 guests at one two-top and two four-tops | 6 guests at three two-tops |
| Stranded seats | 4 seats at the occupied four-tops | 0 seats |
| Available tables | Three two-tops: 6 seats | One two-top and two four-tops: 10 seats |
| New requests: one party of two and one of four | Party of two fits; party of four does not | Both parties fit; one four-top remains free |
The current allocation leaves four stranded seats, not four sellable seats. It can accept the new party of two at a free two-top, but none of its three free tables can hold the party of four. The alternative accepts both new parties, using the remaining two-top and one four-top. Its other four-top stays free.
That does not prove every two-person party should always be put at a two-top. The alternative is better for this particular window and these particular requests. If no party of four wants that window, reserving a four-top for one may have no benefit. If a guest needs an accessible location or a specific table, the smallest-table assignment may not be practical. Record those constraints before treating spare chairs as a preventable loss.
To build the same view for your own floor, list each table's capacity, its block status, its assigned party size, and the overlapping time window. Group free tables by capacity. Then tally actual requests by party size, including requests you could not accept. A restaurant management software workflow may help organize the operating information, but ask how you would obtain table-level assignments and declined-request counts for this calculation.
Compare rules without displacing confirmed parties
Write down the current rule and one alternative in plain language. For the example above, the candidate rule is: assign a party of two to an available two-top before assigning it to a four-top, unless a host records an operational reason to do otherwise. It preserves larger tables when the smaller table is suitable; it does not automatically reject a party of two when only a four-top remains.
Apply both rules to the same set of requests, in the same order, with the same blocked tables and dining windows. Keep confirmed parties in both versions. If a comparison requires a table reassignment, first check whether the reassignment respects the guest's needs and the restaurant's commitments. Do not cancel a confirmed party just to improve the worksheet.
Compare these outcomes, rather than judging by unused chairs alone:
- Accepted parties and guests: Did either allocation fit more of the requests that actually arrived?
- Requests that did not fit: Which party sizes were affected, and was a suitable table genuinely unavailable for the full window?
- Free capacity by table size: What remained after the requests were allocated?
- Operational exceptions: Did the alternative conflict with an accessibility need, guest request, block, or other service requirement?
Do not count a hypothetical request as lost revenue or assume an unavailable guest would have booked another time. For a real service, separately note whether the guest accepted a different time, declined it, or left without an answer. This makes the decision about booking rules more useful than a raw count of rejected time slots.
Set a decision threshold before trying a change. For example, an owner might consider the rule worth continuing if it fits more genuine requests across the observed windows without displacing confirmed parties or repeatedly forcing unsuitable assignments. If the results are tied, or the host must override the rule often for legitimate reasons, the simpler existing rule may be the better choice.
Table availability is only one part of reservation performance. Cancellations and no-shows can also change what happens to a reserved table; use the related guide to reservation no-shows to examine that separate issue rather than mixing it into the stranded-seat calculation.
Test overrides and watch missed opportunities
First run a simulation using fictional reservations or a safe practice environment. Confirm that the exercise cannot create a real booking, charge a card, send a guest message, or dispatch a courier. If the software has no suitable practice environment, use the table worksheet on paper or in a separate file.
Give a host the example floor and the three confirmed parties. Ask the host to allocate them under each rule, then add the fictional requests for two and four. The expected result is the table shown above: the current allocation fits only the party of two; the alternative fits both. Next, add a fictional reason a particular two-top cannot be used. The host should be able to record that reason and adjust the assignment rather than forcing the smallest table.
Use observable pass or fail checks:
- Pass: blocked tables stay unavailable, all three confirmed parties remain assigned, and each party fits at its assigned table for the full window. Fail: a block is ignored, a party is displaced, or overlapping parties are assigned to the same table.
- Pass: the worksheet shows four stranded seats under the current allocation and none under the alternative. Fail: spare chairs at occupied four-tops are counted as free tables.
- Pass: a host can document an exception and its effect on remaining capacity. Fail: the workflow hides the override or leaves staff unsure which rule applies.
- Pass: the result identifies the party of four as unable to fit under the current allocation. Fail: the report shows six available seats without identifying that they are at three separate two-tops.
After the simulation, a live service pilot is a separate decision. Choose a limited set of comparable reservation windows, brief the hosts, and keep normal confirmation and guest-service procedures in place. Record requests by party size, accepted alternatives, suitable tables left free, overrides, and their reasons. Review the notes after each service and stop or adjust the pilot if confirmed commitments or guest needs cannot be handled reliably.
Before selecting software, ask how staff can view table-level availability, record blocks and overrides, and review requests that did not turn into bookings. Also ask whether reports distinguish direct website reservations from other channels, including Google bookings where available. For a concrete next step, compare that checklist with Fleksa's restaurant reservation system and confirm current availability and setup before choosing a workflow.
Frequently asked questions
Are empty seats at an occupied table available capacity?
Not under an exclusive-table policy. Count those chairs as stranded for the overlapping reservation window; another party cannot book them separately.
Should a restaurant always seat parties of two at two-tops?
No. Prioritizing a suitable two-top can preserve larger tables, but guest needs, table blocks, request patterns, and service commitments may justify another assignment.
What if the system shows seats but not table sizes?
Ask whether it can show or export table-level assignments and blocks. Until you can distinguish free two-tops from free four-tops, a seat total alone cannot tell you which parties will fit.
