When a guest can accept any suitable time but the requested slot is unavailable, record one request with the guest’s acceptable time range and party size. Have a named staff member choose and offer one available time. If the system supports several independent holds instead, use them only with a clear expiry and a way to release every unused option.
The buying decision is about control as much as convenience. A flexible request should not quietly become several confirmed bookings, block more tables than intended, or leave staff unsure whether the guest is coming. Ask the vendor to demonstrate the full path from request to confirmation, expiry, and release.
Decide who owns a flexible request
Start with the guest’s actual boundaries: party size, earliest and latest acceptable arrival, date, and any seating needs that affect the choice. A request for a table between 6:00 and 7:30 p.m. is different from permission to seat the party at any time that evening.
Assign a shift lead or another named employee to review the request. That person needs to know whether the guest expects a proposed time or believes a reservation is already confirmed. Record the status in a place the next shift can find: pending review, offered, confirmed, expired, or canceled. Agree on a response deadline with the guest where practical.
Also set a capacity rule. A guest party is a group of diners; a physical table is a piece of the dining room that may be combined with another table. The manager should decide which tables can seat the party and how long each booking occupies them. A time that looks open on an arrival list may still conflict with an earlier party’s expected stay.
Before choosing software, map this workflow against your existing restaurant management software. Ask who can see requests, who can change their status, and what happens when responsibility passes between shifts.
Compare a time-range request with independent holds
One time-range request: The guest gives an acceptable window, and staff select one available time. Until a specific time is confirmed, treat the request as pending rather than a guaranteed seat. This approach is useful when a manager wants to protect availability while deciding where the party fits. It depends on staff responding promptly and on the system making pending requests visible.
A range is a poor fit if the guest needs an immediate confirmed time and nobody is available to review it. It can also create confusion if the software records only a single arrival time and staff have to keep the guest’s actual range somewhere else. Ask how that information stays attached to the request.
Several independent holds: Staff temporarily reserve individual options, then confirm one and release the rest. This can help when the guest must choose between specific times and the restaurant is willing to protect those options briefly. But each hold may occupy capacity. Three holds for one party can prevent three other parties from booking if they cover separate tables or periods.
Use holds only if staff can identify them as alternatives for the same party, see their deadlines, and release them reliably. Ask whether confirming one option releases the others automatically. If not, identify who must do it. If the system cannot link alternatives or make their status clear, a single range request with a manual follow-up may be safer.
Neither approach should depend on a guest message being sent successfully without a way for staff to check its status. Ask what the team sees if a message fails, a guest changes the range, or a shift ends before the guest responds.
Worksheet: follow one party through confirmation and expiry
The following example is hypothetical. A party of four can arrive between 6:00 and 7:30 p.m. The restaurant has one suitable physical table available for each of three possible starts: 6:00, 6:45, and 7:30. For this example, the manager has checked that these are genuinely available options. The party needs only one table at one start time.
The table compares the actions staff would record under the two approaches. It does not assume that any particular system offers either workflow.
| Stage | One range request | Three independent holds | Owner and expected result |
|---|---|---|---|
| Record | Enter one pending request for four, 6:00–7:30. | Create three alternative holds for the same party, one at each start. | Host records the party and its boundaries. A pending request is not a confirmed table. |
| Offer | Offer 6:45 after checking the table. | Offer the three choices with a stated response deadline. | Host tells the guest what is offered and when a response is needed. |
| Confirm | Guest accepts 6:45; confirm that one reservation. | Guest chooses 6:45; confirm that hold. | Host checks that one confirmed booking remains for four at 6:45. |
| Release | No unused holds need release in this example. | Release the 6:00 and 7:30 holds. | Host verifies both options are available again, unless another valid booking has taken them. |
| Expiry | If there is no response by the deadline, close the pending offer according to house policy. | If there is no response, expire all three holds at the deadline. | Shift lead checks status and resolves any hold that remains active. |
The important distinction is capacity. In the range approach, the example does not reserve a table while staff review the request; availability can change before an offer is accepted. In the holds approach, all three options are protected until confirmation or expiry, subject to the system’s actual rules. The manager must be comfortable temporarily restricting those options to one party.
For a busy Saturday, the manager might allow only one short-lived hold rather than three. For a quieter service, protecting several options may be acceptable. Write that limit into the host procedure rather than leaving each employee to decide during a rush.
If the guest accepts 6:45 after the deadline, do not assume it is still available. Check current capacity and make a new offer if necessary. If a hold remains active after it should have expired, the shift lead should verify its status, release it through the authorized process, and record what happened. A guest should receive a clear confirmation only for the time the restaurant can actually honor.
Run a vendor acceptance test before purchase
Ask the vendor to demonstrate the workflow in a sandbox, training account, or another isolated setup. Use fictional guest details. A simulation must not charge a real card, send a guest message, or dispatch a courier. Have the person who will own reservations observe the demonstration and record the results.
- Capture the request: Enter a party size, date, acceptable range, and response deadline. Pass if staff can find all four details and identify the request as pending. Fail if the range or status disappears from the working view.
- Make one offer: Select an available time and record the offer. Pass if staff can distinguish an offer from a confirmed reservation and identify who follows up. Fail if an unaccepted offer appears as a confirmed guest booking without an understandable status.
- Check alternatives: If independent holds are part of your intended workflow, create the permitted number and confirm one. Pass if the remaining holds are released automatically or the responsible employee can find and release each one. Fail if unused holds cannot be identified or cleared.
- Check expiry: Let the simulated deadline pass. Pass if the team can see which request or holds expired and can verify the affected capacity. Fail if an expired option remains blocked without a visible recovery action.
- Handle an exception: Simulate a guest accepting after expiry or a failed message. Pass if staff can check current availability, update the status, and arrange a manual follow-up. Fail if the team cannot tell whether a booking exists or who should act.
For a range-only workflow, mark the independent-holds test as not applicable rather than assuming the feature exists. Ask the vendor to show the exact screens your staff would use, including any manual steps. Then ask support: “If an unused hold does not release, what can our shift lead do immediately, and how do we reach you during service?” Record the answer with the quote and your internal procedure.
If the simulation passes, a separate, limited live-service pilot can check whether staff can maintain the process during an actual shift. Use real bookings only with your normal guest communication and authorization procedures. Name a pilot owner, set a review time, and keep a manual recovery plan ready. A practice scenario should never be treated as a live booking.
Channel choice matters too. OpenTable offers reservations and a diner discovery network; a direct booking tool serves a different route through the restaurant’s own website. Ask vendors about booking-channel attribution, permissions, exports, and fees. Also ask whether Google bookings are available for your setup. Neither channel removes the need to confirm who owns each pending request.
As a next step, take the worksheet and your capacity rules to a restaurant reservation system demonstration. Compare your requirements with Fleksa and confirm which features are available for your setup. For a related operational decision, review how to measure the cost of reservation no-shows.
Frequently asked questions
Should a flexible time request reserve a table immediately?
Not necessarily. A pending range can give staff time to select one suitable slot without blocking capacity. Tell the guest that the request is not confirmed, and respond by the agreed deadline.
How many alternative holds should one party receive?
Set a limit based on your available physical tables and service demand. Each independent hold can restrict capacity, so use only as many as you are willing to protect and can reliably release.
What if the guest replies after a hold expires?
Check current availability before confirming. If the selected time is no longer open, offer another suitable time or ask for a revised range. Record the outcome so the next shift can see it.
