Start with a booking horizon that matches how confidently you can schedule the service, then set a separate cutoff that gives your team enough time to prepare. For many restaurants, the right answer will differ for a regular dinner, a holiday, and a large party. Review actual requests before settling on one rule for every service.
The horizon answers how far into the future a guest can book. The cutoff answers how close to the reservation time online booking remains open. Neither rule determines how many parties arrive at once; that is a separate pacing decision. You still need capacity controls for physical tables, seating times, and party sizes.
Compare lead times by service and party size
Look at recent reservation records and phone inquiries for each service. Note when the guest asked, the requested dining time, the party size, and whether you accepted the request. Include requests you could not accommodate, where staff can record them consistently. A booked table alone does not show how much demand you turned away.
Group requests into useful bands: same day, one to seven days ahead, and more than a week ahead. Then separate ordinary parties from larger groups. Lunch guests may decide on the day, while a birthday group may want a date weeks in advance. If your dining room changes layout for large parties, their lead time matters for preparation as well as demand.
Use the following hypothetical worksheet as a starting decision, not as a forecast. The restaurant has six physical tables at dinner, each seating up to four guests. It can join two tables for one party of five to eight, leaving four tables for parties of up to four. The sample covers one week of inquiries; a longer record would give the owner a better basis for a permanent rule.
| Service and request | Observed inquiries | Starting rule | Reason to revisit |
|---|---|---|---|
| Regular dinner, one to four guests | 18 inquiries; 12 made within seven days, including 5 on the same day | Open 30 days ahead; close online two hours before dining | Track same-day requests after the cutoff |
| Regular dinner, five to eight guests | 6 inquiries; 4 made more than seven days ahead | Open 60 days ahead; close online 24 hours before dining | Check whether staff can confirm the joined-table setup |
| Holiday dinner, all party sizes | 8 inquiries for the next holiday; 6 arrived more than 30 days ahead | Open 60 days ahead after the holiday schedule is confirmed | Check the planned hours and table layout before opening |
The rows describe separate inquiry groups. The first row's five same-day inquiries are included in its 12 inquiries within seven days, not added to them. The numbers support a longer horizon for groups and the holiday, but they do not prove that every request became a booking. They also do not establish a revenue benefit.
In this example, opening regular small-party bookings 60 rather than 30 days ahead may add little value if few guests ask that early. For the holiday, a 30-day horizon would leave six of eight observed inquiries outside the online window when they first arrived. A 60-day horizon could let those guests request a table earlier, provided the holiday schedule is ready. It would not guarantee that suitable tables remain available.
Balance early bookings against schedule changes
A long window gives guests certainty and gives you an earlier view of demand. It also commits you to future hours, seating arrangements, and staffing assumptions. Before opening a distant date, ask who can approve the schedule and how the team will handle a change after guests have booked.
Use a shorter horizon when opening hours or room availability are unsettled. Use a longer one when guests routinely plan ahead and you can honor the dates. A holiday can justify its own rule: confirm the service hours, available tables, and any special arrangement before making that date bookable. If those details are not ready, tell staff when to expect a decision and how to respond to inquiries in the meantime.
Ask vendors whether horizons can vary by service, date, and party size. Also ask how changes affect existing reservations. For example, if you shorten the window or close a future service, do existing bookings remain visible for staff to review? Establish who contacts affected guests and records the outcome. Do not assume that changing availability resolves a reservation already accepted.
A restaurant management software evaluation should include the people maintaining the schedule, not just the person buying the tool. A host needs to see accurate availability; a manager needs a clear process for approving exceptions. If the software cannot apply different rules automatically, decide whether staff can reliably manage them without creating conflicting availability.
Set the cutoff and a route for exceptions
Work backward from the reservation time. A two-hour cutoff means a 7:00 p.m. reservation stops being available online at 5:00 p.m. The interval should cover the work your team actually needs to do: review the booking, prepare the table, and adjust the floor plan if necessary. It should not be so early that the restaurant routinely turns away parties it could seat.
In the worksheet, a small party closes online two hours ahead. A five-to-eight-person party closes 24 hours ahead because the team must consider joining two physical tables. If that group books, those two tables cannot also be sold separately for an overlapping seating. The remaining four tables each hold up to four guests; they do not automatically represent four available parties at every time, because existing bookings and seating duration also matter.
Give staff an exception path for requests after the cutoff. A guest might call at 5:30 p.m. for a 7:00 p.m. table. The host checks the live floor plan and existing reservations before accepting. For a large party, the manager checks both the joined-table space and the effect on other reservations. If there is no safe fit, offer another time rather than placing the request in an already committed table.
Write down who can approve an exception and where the final reservation must appear. A phone acceptance that never reaches the shared booking record can make online availability misleading. Ask the vendor how staff add a manual booking, whether it immediately changes availability, and what happens if two staff members try to reserve the same space.
Deposits and no-shows are separate decisions from the booking window. If you are considering a deposit for larger parties, ask how it would be handled and what costs or terms apply; do not assume a reservation product supports it. For the broader operating question, see the guide to measuring reservation no-show costs.
Check denied demand and stale availability
Review the decision after a defined period, such as four weeks. Count inquiries that arrived before the horizon opened and after the cutoff closed. Record whether staff accepted them manually, offered another time, or declined them. Keep the reason simple: no physical table, insufficient preparation time, service not scheduled, or another documented reason. A declined inquiry is useful evidence; it is not necessarily a lost sale.
Also check for stale availability: dates or tables that appear open after the operating plan has changed, or dates that remain closed after the manager approves service. Compare the public booking view with the schedule staff are using. Check ordinary days, a holiday, and a date near the edge of the horizon. Confirm that displayed times match the restaurant's local time, particularly around a time-zone change.
Before using new settings, run a simulated check with the vendor or in a safe practice environment. Try changing hours, closing a holiday, adjusting a party-size limit, and making a manual reservation. Confirm what a guest would see and what staff would see. The simulation must not send a real guest message, take a real payment, or dispatch a courier. Ask how to prevent those actions before beginning.
A live service pilot is different: it uses actual availability and can affect real guests. If you run one, choose an owner, a limited service period, and a way to reconcile accepted bookings with the floor plan. Tell staff which system is authoritative and how to report discrepancies. Resolve problems promptly rather than assuming a rehearsal guarantees an uninterrupted service.
Consider where bookings originate as well. OpenTable offers restaurant reservations, operations tools, and a diner discovery network. A direct booking path on your website serves a different purpose; neither approach guarantees bookings. Ask each vendor about channel attribution, staff permissions, exports, and fees. Ask Fleksa whether a Google booking path is available for your location and setup. Compare written quotes and contract terms, including any setup and ongoing charges, rather than assuming a channel is free.
If changing systems, assign a cutover owner. With authorized access and a supported transfer method, reconcile booking counts and check each reservation's identity, local date and time, party size, status, and appropriate special requests. Ask both vendors what export and import methods they support before choosing a cutover date.
Next step: Choose one service, fill in the worksheet with your own inquiries and table limits, and review the exception process with your host. Then compare Fleksa's restaurant reservation system with those operating requirements.
Frequently asked questions
How far ahead should a restaurant take reservations?
Choose a horizon supported by both guest demand and a schedule you can honor. A regular service may need a shorter window than a holiday or large-party service. Review early inquiries before extending it.
When should online reservations close?
Close them early enough for staff to prepare, but late enough to serve feasible last-minute demand. Work backward from the reservation time and consider a longer cutoff for parties that require a table-layout change.
Can staff accept a booking after the online cutoff?
They can use an agreed exception process if there is capacity and enough preparation time. Have an authorized staff member check the floor plan and enter the accepted booking in the shared record.
