Skip to article
← Back to Blog
Operations

Restaurant Reservation Capacity: Tables vs. Covers

By Fleksa7 min read•Reservations, Restaurant Operations, Software Buying

A cover limit can leave guests without a suitable table, while a table count can hide unused seats. Use this six-table example to compare both rules and test whether reservation software handles real seating constraints.

For most restaurants, the safest reservation rule uses both physical tables and covers: limit the number of guests in the room, and make sure each party can fit at an available table. A cover is one guest. A party is a booking for one or more guests. Neither is the same thing as a physical table.

Both limits still need a seating check. A room can have enough empty seats in total and still have no table that fits the next party. Before buying a restaurant reservation system, map your floor and ask the vendor to demonstrate what happens in that situation.

Map the actual tables before setting limits

Start with a floor plan from the person who manages seating. Record each physical table, its normal maximum seats, and whether it can be combined with another table. Then ask the host or floor manager to mark tables that are unavailable because of service stations, accessibility needs, or other operating constraints.

Use that map to decide which inventory to offer online. A room may have 30 seats on paper, but that does not mean all 30 should be bookable at the same time. You might hold some space for walk-ins or reduce capacity when staffing is tight. Record those choices separately from the physical seat count.

The following example is hypothetical. Assume the floor manager's seating map shows six usable tables: four tables with two seats each and two tables with six seats each. All six are available for reservations, and tables cannot be combined. The simultaneous maximum is six occupied tables and 20 covers. Assume every booking overlaps for the period being considered; this is a capacity comparison, not an arrival-pacing rule.

InventoryPhysical tablesSeats per tableTotal seats
Small tables428
Large tables2612
Total6—20

The table separates what the floor can hold from the rules you choose. In a real restaurant, verify the numbers against the actual layout; do not treat the hypothetical 20-cover ceiling as a recommendation. Also specify whether a table's stated capacity is a hard maximum or whether staff sometimes seat fewer guests there for comfort.

Compare table limits, cover limits, and both

A table limit counts occupied physical tables. If six tables are occupied, another party cannot be seated under the example's assumptions. But a count alone does not say which tables are free or whether the next party fits. It must be paired with a table assignment or a separate fit check.

A cover limit counts guests. At 20 covers, the example room has reached its seat maximum. Below 20, however, the remaining seats may be spread across tables that are already occupied. A cover count also cannot tell you whether an empty table is large enough for a party.

Compare two possible outcomes using the same six-table floor:

  • Six parties of two: Each party occupies one table, for six occupied tables and 12 covers. All six tables are full as inventory, even though eight seats are unused. A cover-only rule set at 20 could see room for another party of six: 12 plus six equals 18 covers. There is no free table for it.
  • Two parties of six and four parties of two: The large parties occupy the two six-seat tables; the smaller parties occupy the four two-seat tables. That is six occupied tables and 20 covers. Both the table and cover ceilings are reached, and every party fits.

The first outcome is the deciding one. If your booking rules only count covers, the guest total can look acceptable while the floor is already full. If the rules only count parties as though each party were a table, they can also be wrong: a party may need more than one table, or may not fit any available table at all.

For this example, use both a 20-cover ceiling and the six-table inventory, with a fit check against the available table sizes. The recommendation follows from the assumed layout and inability to combine tables. A different floor, a walk-in allocation, or a lower operating capacity calls for different limits.

Review timing as well. A table can be used again after a party leaves, so the relevant question is whether bookings overlap, not how many reservations exist across the whole evening. Arrival pacing is a separate control: it limits how many guests or parties arrive in an interval, rather than measuring simultaneous table inventory.

Test the spare-seat failure before service

Ask the vendor to run the first outcome in a demonstration or isolated practice environment. Set up the six-table map, place six overlapping parties of two, and then request an overlapping party of six. The expected result is that the last request is not offered as an available booking: the room has 12 covers, but no unoccupied table.

The host or floor manager should inspect the table assignments, not just the cover total. That person is responsible for spotting a misleading result and stopping the reservation from being accepted until the seating is corrected. If the system shows availability for the seventh party, ask the vendor to explain exactly how it expects staff to seat that party under the stated rules.

Keep the practice isolated. Use fictional guest details and a simulation that cannot take a real payment, send a guest message, or dispatch a courier. Do not use a real guest booking as a test. If the vendor cannot provide a safe simulation, walk through the expected screens and rules without submitting a live reservation, and record the unanswered behavior for a later demonstration.

Then change the setup: clear the simulated bookings and enter two parties of six plus four parties of two for overlapping times. Each must be assigned to a suitable table. A further overlapping party should not be offered a place. This second case checks that the rule does not simply reject large parties to avoid the first failure.

If you want to combine tables in practice, make that a separate test. Define which physical tables can join, the resulting capacity, and what happens to the individual tables while they are combined. Do not assume that setting a cover limit automatically prevents the same table from being allocated twice.

Set acceptance criteria and an override owner

Bring the actual floor map and a few difficult party mixes to each vendor demonstration. Ask the same questions each time so you can compare the workflow rather than a polished sales screen.

  1. Enter the inventory. Can staff represent each table's usable size and any permitted combinations? Ask how changes to the floor affect existing bookings.
  2. Set overlapping limits. Can the system apply your cover ceiling and prevent an unavailable or unsuitable table from being offered? Ask how it handles different booking durations.
  3. Run both party mixes. The six parties of two must leave no availability for an overlapping party of six. The two parties of six and four parties of two must fit on the stated floor. A demonstration passes only if both results are correct under the agreed assumptions.
  4. Check the staff view. Can the host see the assigned tables, party sizes, and overlap clearly enough to explain why a request is or is not available?
  5. Test the exception path. Ask who can override a rule, what staff see before confirming an exception, and how the change appears to the rest of the team. Do not assume an override is available or that it automatically creates a valid seating plan.

Assign the floor manager as the owner of capacity exceptions, or name another person who is present during service. That owner should approve a manual change only after checking the physical tables, the affected booking times, and any operational holdbacks. Agree on a backup when that person is off duty. If no suitable seating exists, the action is to offer another time or decline the request, not to rely on spare covers alone.

After a safe simulation, a live service pilot is a separate decision. Use the agreed rules for genuine bookings, brief the host team, and have the exception owner compare the seating plan with what actually happens. Set a review point to adjust durations or capacity holds; a simulation cannot reproduce every service condition.

Also ask how reservations from your website and, where available, Google bookings appear alongside other channels. Confirm how staff can identify the source, what permissions they have, and what booking information they can export. A discovery network and direct website bookings serve different purposes, so compare those channel needs as well as the seating controls.

Review the Fleksa reservation workflow and consider how it fits with your wider restaurant management software. For costs, request a written quote that identifies recurring charges, setup, and any channel-related fees. Consult Fleksa plans for current pricing; the plans reference was checked in November 2026. Ask a qualified adviser about contract or tax treatment when needed.

Next step: Take your floor map and the two party-mix tests to Fleksa. Compare your reservation requirements and confirm current support before choosing a workflow.

Frequently asked questions

Is a cover limit enough for online reservations?

Not by itself. A cover limit controls the guest total but does not show whether the remaining seats form a suitable, unoccupied table for the next party.

Should every party count as one occupied table?

Only when each party actually occupies one physical table. Large parties may need combined tables, and a small party may occupy a large table. Base the count on the seating arrangement.

Who should handle a capacity override?

Name the floor manager or another on-duty owner, with a backup. That person should check the physical seating and overlapping bookings before approving an exception, if the system permits one.

Ready to grow your restaurant?

Explore how Fleksa can support ordering and operations in your restaurant.