Cap arrivals by the work your team can handle in each interval, not just by the number of empty seats. For restaurant reservation pacing, that usually means setting both a guest limit for kitchen and service workload and a party limit for the host. If either limit is reached, offer another time even when a table is still open.
Start with a 15-minute interval if that matches how your reservations arrive. Count physical capacity separately, then compare it with the staff capacity you expect during that window. The lower workable limit controls how many bookings you accept. Review the rule against actual service and give the shift leader a clear override process.
Compare arrival limits with seats available
A table count tells you where guests might sit. An arrival cap tells you how much new work can enter the restaurant at once. Those are related decisions, but they are not interchangeable. A six-top and a two-top are two guest parties; they are not necessarily two identical units of work for the kitchen.
For the following hypothetical worksheet, assume a dining room has six physical tables configured for four guests each. All six are available at the start of a 15-minute interval, giving the room 24 open seats. Assume the operator can combine or arrange tables to accommodate a party of six without exceeding that seat count. Whether a particular combination leaves room for other parties still needs a table check.
For that same interval, the kitchen can comfortably absorb orders from 10 arriving guests, while the host can greet and seat two parties. These are operating assumptions, not universal standards. The resulting starting rule is no more than 10 guests and two parties arriving in the interval, provided suitable tables are available.
The limit leaves seats unused on purpose. Seating 12 guests at once could fit the room, but it would exceed the assumed kitchen workload. Accepting three parties totaling eight guests would stay under the guest limit but exceed host coverage. A booking should pass both checks as well as the physical table check.
Use this worksheet at the start of a shift. The examples show what changes when one constraint tightens; the seat count alone does not set the cap.
| 15-minute condition | Physical capacity | Workload limits | Starting rule |
|---|---|---|---|
| Normal coverage | 24 open seats across six tables | 10 guests; two parties | Accept up to 10 guests and two parties, if tables fit |
| Reduced kitchen capacity | 24 open seats across six tables | Eight guests; two parties | Accept up to eight guests and two parties, if tables fit |
| Reduced host coverage | 24 open seats across six tables | 10 guests; one party | Accept one party of up to 10 guests, if tables fit |
The last row is a workload ceiling, not a promise that a party of 10 can be seated. The actual table configuration may rule it out. Likewise, open seats later in the evening depend on when current guests leave. Do not count a table as available for a new booking solely because its original reservation time has passed.
Model party sizes across intervals
Now use the normal-coverage rule: 10 guests and two parties per 15 minutes. Suppose requests arrive for a party of two, a party of four and a party of six at 6:00 p.m. Together, they represent three parties and 12 guests. The room has enough seats in total under the worksheet assumptions, but accepting all three for 6:00 would exceed both workload limits.
One workable offer is to book the parties of two and four at 6:00. That uses six of the 10 guest places and both party places for the interval. Offer the party of six a 6:15 arrival instead, after checking that a suitable table arrangement will remain available. The 6:15 interval then starts with six guests and one party booked, leaving room under the pacing rule for one more party of up to four guests, if a suitable table is available.
A different order produces a different result. A party of six and a party of four would use all 10 guest places and both party places at 6:00. The party of two would need another interval even though it is small. If the party of six is accepted first, a second six-person party cannot fit within the same guest cap, even though the party count would still be within two.
These choices affect the mix of bookings. A strict party cap can leave guest capacity unused when several small parties want the same time. A guest cap alone can send too many small parties through the door. Track both so the host can explain an alternate time without guessing.
Also decide which demand counts against each interval. Include reservations from every channel the team accepts, and account for walk-ins you expect to seat during the rush. A restaurant reservation system can be part of that workflow; ask how its availability settings handle guest limits, party limits, booking channels and manual changes before relying on a rule.
Set the rule around kitchen and host coverage
For the kitchen, estimate how many new guests can enter the ordering flow in each interval without creating a backlog that spills into the next one. Look at the busiest part of the shift, the menu guests tend to order and other work arriving at the same time. A dining room with plenty of seats can still overwhelm a kitchen that is also preparing pickup orders.
For the host, count the work around each party: greeting, checking the booking, answering a question, walking guests to a table and returning to the door. A large party may take longer, but several small parties can create a queue too. If one host also answers the phone, use a lower party limit during the busiest call periods rather than assuming uninterrupted door coverage.
Servers matter as well. Check whether the floor can take orders and deliver drinks for the proposed arrivals. If service coverage is the tightest constraint, lower the guest or party limit accordingly. The starting cap should reflect the weakest part of the arrival-to-order process, not the strongest.
Change the cap by shift or interval when conditions change. In the worksheet, reducing kitchen capacity from 10 to eight guests changes a six-person booking's remaining guest allowance from four to two. Reducing host coverage to one party instead means that the same six-person booking uses the whole party allowance, even though four guest places remain. Either change can affect which requests you accept.
Review the result with the people working the shift. Note when a door queue forms, when newly seated guests wait too long to order, and whether one interval's workload carries into the next. A restaurant POS system may be useful when reviewing the timing of orders; ask what timestamps and reports are available and whether they match the decision you need to make.
Handle late arrivals and overrides
Keep the booking's original time visible, but count a late party against the workload it actually creates when it arrives. Otherwise, the host may see an apparently full earlier interval and an apparently open current interval while the team is handling both at once.
In the same hypothetical service, suppose a party of four booked for 5:45 arrives at 6:00, before any other 6:00 arrivals. Under the normal rule, that late party uses four guest places and one party place in the current interval. The remaining workload allowance is six guests and one party. A party of six could fit the pacing allowance, but only if its table arrangement is available. If two parties are already due at 6:00, the late arrival would put the interval over the party limit; the host should contact the shift leader before seating it.
Choose the override authority before service. For example, the host can recommend an exception, but the shift leader decides after checking the table, kitchen and floor. Record the party size, original and actual arrival times, reason for the exception and person who approved it. Tell the team about the change so the kitchen is not surprised by another large arrival.
An override is a deliberate exception, not a new default. The leader might seat a late party immediately if the room is quiet or ask it to wait if the next wave is already at the limit. Have a consistent way to communicate the revised expectation to the guest without promising an exact seating time the team cannot meet.
Late arrivals are different from no-shows. Set a separate policy for how long to hold a table and who releases it. For a closer look at the operating impact, see the guide to measuring reservation no-show costs.
Practice the workflow, then review a live shift
Before changing public availability, walk the host and shift leader through a simulation. Use fictional bookings for a two, a four and a six; apply the guest and party caps; then introduce a late party. Check that everyone reaches the same decision and knows who can approve an override. Run the exercise without sending a real guest message, taking a real card payment or dispatching a courier.
Then use the chosen rule during a live service pilot with the team aware of the limits. Real guests should receive the restaurant's normal service communications; the simulation should remain separate. After the shift, compare the planned caps with actual arrivals and note any queues, exceptions and unused capacity. Adjust one constraint at a time when possible, so the team can see what changed.
Compare the reservations workflow against your operating requirements with Fleksa. Bring your interval length, guest and party limits, channel needs and override procedure to the conversation, and ask how each would be configured and maintained.
Frequently asked questions
Should a reservation interval close when tables are still empty?
Yes, if accepting another arrival would exceed a workload limit. Offer a nearby interval after checking both its remaining capacity and the table arrangement.
Should a late party count in its original slot or its arrival slot?
Keep the original booking time for the record, but account for the party's actual arrival in the current workload. Ask the shift leader to decide if seating it would exceed the cap.
How often should an operator change pacing limits?
Review them after busy shifts and when staffing, menu or channel demand changes. Keep a short record of queues and overrides so adjustments respond to observed service conditions.
