Direct a large party to staff when accepting it automatically could tie up table combinations you need for other guests, require a room or staffing decision, or create a commitment your team cannot confidently fulfill. The right cutoff depends on your layout and service, not on a standard number.
Start with the largest party you can seat reliably during a busy service without an individual host decision. That becomes a candidate online limit. Larger groups should get a clear way to contact your team, rather than a dead end or a booking the restaurant may have to undo.
Map party sizes to real table combinations
Count physical tables first, then work out which ones can be joined. A restaurant with 24 seats does not necessarily have a suitable table for a party of eight. Tables may be fixed, separated by a walkway, or needed for smaller reservations already on the books.
Draw a simple floor plan and note each table's comfortable capacity. Mark combinations that staff can actually use, including the space needed for chairs and service. A combination that fits on paper but blocks the route to the kitchen should not count as available capacity.
Next, compare the combinations with the parties you expect to serve at the same time. One six-person party is one guest party, but it may occupy three physical two-top tables. Those tables cannot also seat three separate two-person parties during the same seating period.
Use the worksheet below as a hypothetical example. Each layout has 12 seats and is otherwise empty at the start of a busy seating period. Assume all listed tables can be combined as described and that the expected smaller parties need seating at the same time as the large party.
| Layout and expected demand | Large-party combination | Space left for expected smaller parties | Candidate online limit |
|---|---|---|---|
| Six two-tops; expect one party of four and two parties of two | Six guests use three two-tops | Three two-tops remain. The four-top needs two; the two pairs need one each. Four tables are needed, so one expected party cannot be seated. | Four; ask larger parties to contact staff |
| Two four-tops and two two-tops; expect one party of four and two parties of two | Six guests use one four-top and one two-top | One four-top and one two-top remain. The four-top seats the party of four; only one of the two expected pairs can be seated. | Four for this demand; route six to staff |
| Two four-tops and two two-tops; expect one party of four and one party of two | Six guests use one four-top and one two-top | One four-top and one two-top remain, enough for both expected parties. | Six may be suitable if service capacity also allows it |
The table shows why seat count alone is a poor cutoff. In the first two rows, automatically taking six would leave too few usable tables for the expected smaller parties. In the third, both the layout and expected demand support six. These are planning assumptions, not a prediction that every expected party will arrive.
Check other arrangements before settling on a number. Can a party of five use the same combination as six? Does joining tables remove a chair? If a table is occupied longer than expected, what other combination could the host use? Keep the answers beside your floor plan so a manager can review them when the room changes.
Identify the service constraints behind the limit
Physical capacity is only the first check. A large party can arrive together, order together, and put a concentrated load on a server, bar, and kitchen. Ask your team which party sizes they can absorb during a busy seating without delaying the rest of the room.
Look at the full visit. A group may need extra time to gather, discuss the menu, or settle its bill. If the next reservation depends on that table being ready, a short turnover assumption can create a problem for both parties. Use realistic seating durations for your operation rather than assuming a group will behave like a table for two.
Staff may also need to discuss details before accepting a request: accessibility needs, high chairs, a celebration, separate checks, or whether the group needs a particular area. Do not assume every large party has special requirements. The point is to give staff a chance to check when those details affect the booking.
Compare busy and quiet services separately. A party of six might be easy to seat at an early weekday dinner and awkward at the busiest Saturday seating. If your booking tool supports different rules by service or time, ask how those rules interact. If it does not, choose a limit your team can honor consistently, or manage exceptions through staff.
Your restaurant management software may be part of the wider service workflow, but the floor plan and the team's actual capacity should drive the decision. Ask staff which combinations they avoid and why; a rule based only on total seats misses that knowledge.
Set the online limit and a useful staff handoff
Choose the largest party size you can accept without a case-by-case decision under the conditions your rule covers. Then decide what happens above it. A limit of four does not mean a party of six is unwelcome. It means someone should check the room and service before confirming it.
Make the guest's next step specific. For example: For parties of five or more, please call the restaurant to check availability. Use a contact method your staff actually monitors, and set an internal expectation for who responds and when. If you offer a request form or email, tell guests that sending a request is not the same as receiving a confirmed reservation.
Give the host enough information to make a decision: requested date and local time, party size, a contact method, and any seating needs the guest chooses to share. The host can check the floor plan, other reservations, staffing, and any timing constraints before confirming or suggesting another time.
Write down who can approve an exception. A manager may accept a six-person party during a quiet service even when the standard online limit is four. Record the decision in the reservation workflow so another host does not unknowingly assign the same tables. Ask the software provider how staff-entered reservations affect online availability and whether permissions can restrict who changes limits or overrides them.
Also check every booking path you use. A guest arriving through your website should encounter a consistent rule and contact path. If you use Google bookings, ask which reservation paths are available for your restaurant and how party-size limits and handoffs are applied there. For a discovery-led service such as OpenTable, which offers reservations, restaurant operations, and a diner network, ask separately how its settings, channel attribution, permissions, exports, and fees work. Direct website bookings and marketplace discovery are different channels; evaluate both against your needs.
When comparing a restaurant reservation system, ask to see the guest experience for an unsupported party size and the staff workflow for a larger request. Also ask whether limits can vary by service, how table combinations are configured, and what happens when staff enter an exception. Do not rely on a setting's name alone.
Check failed requests and host overrides
Before changing a live rule, walk through a simulation with your team. Use a practice environment or a provider-guided demonstration that cannot send a guest message, take a payment, or trigger a courier dispatch. If those protections are not available, review the screens and decision steps without submitting a booking.
Try a party at the limit, one just above it, and a larger group that would require several tables. Check whether the guest sees an understandable next step, whether the restaurant's contact details are correct, and whether staff can distinguish a request from a confirmed booking. Then walk through an exception: a host checks the floor plan, obtains approval if required, and records the booking through the available staff process.
A simulation checks the workflow without involving guests. A live service pilot is different: it uses actual reservations and needs a named owner watching the floor and the booking channels. Start with a clearly defined service, brief the hosts, and have a fallback contact path ready. Do not promise guests availability until staff can confirm it.
After the pilot, review the requests that did not become reservations and the exceptions staff accepted. Look for patterns: Are guests reaching the cutoff when the room could usually accommodate them? Are hosts repeatedly moving tables to honor automatic bookings? Are guests leaving because the contact path is unclear or slow?
Use those observations to adjust one rule at a time. Raising the limit may make sense if the needed combinations and service capacity are consistently available. Lowering it may be better if hosts frequently need to rearrange the room. Consider the cost of missed reservations alongside the disruption of accepting a group the team cannot comfortably serve; neither number alone tells the full story. For another part of that decision, see the guide to measuring reservation no-show costs.
Next step: Take your floor plan and busiest expected party mix to a Fleksa conversation. Compare the reservations workflow with your required limits, staff handoff, and exception process before choosing a setup.
Frequently asked questions
What party size should a restaurant allow online?
There is no universal number. Choose the largest party you can seat and serve reliably under the rule's busiest applicable conditions, then review it against actual requests and host overrides.
Can staff accept a party above the online limit?
Yes, if the restaurant's process allows an exception and staff confirm that the room and service can accommodate it. Ask your provider how a staff-entered booking affects availability across your booking channels.
Should the same limit apply all week?
Not necessarily. Demand, table combinations, and staffing can differ by service. If your tool supports time-specific rules, check how to configure them; otherwise, use a consistent limit and let staff assess larger requests.
