When an employee takes a reservation by phone, the buyer should require checks for usable contact information, policy disclosure, available capacity and a record of who entered the booking. The system should also make an ordinary booking distinct from a request that exceeds the restaurant’s limits.
Ask vendors to show these checks in a staff-facing workflow, not just on the guest-facing booking page. A short, simulated phone call can reveal whether an employee can save an incomplete booking, whether a manager must approve an exception and what the next person on shift can actually see.
Decide what staff must capture
The general manager or reservations lead should own the requirements, with input from hosts and shift managers. Hosts know what they can reasonably ask during a busy call. Managers know which exceptions they are willing to approve and how much capacity the dining room can support.
Start with the information needed to find and honor a booking: guest name, party size, local date and time, and a contact method the restaurant can use if plans change. Decide whether a phone number is required for every phone booking or whether another contact method is acceptable. Ask what happens when a guest declines to provide one.
Do not treat every missing detail the same way. A missing party size prevents staff from checking capacity. A missing contact method may require a manager’s decision or a clearly marked follow-up. A special request can be useful without being a promise that the restaurant can meet it.
Next, define policy disclosure. If the restaurant has a cancellation policy, seating time limit or deposit requirement, decide what the employee must explain before confirming. The record should distinguish a policy that was discussed from a guest request that still needs a response. Ask how the system records that distinction and how staff correct an inaccurate entry.
Finally, decide what the next shift needs to see. A booking record should be understandable without finding the employee who took the call. At a minimum, ask whether it shows the creator, the relevant changes, their times and the booking’s current status. If a manager approves an exception, ask whether that approval is visible alongside the reservation.
Compare entry controls before choosing a workflow
There are several workable approaches. The right one depends on call volume, staff training and the consequences of an incomplete booking. Use the worksheet below to compare the actual staff workflow a vendor demonstrates with the process your team is prepared to run.
| Control | Strict entry check | Follow-up workflow | Question to settle |
|---|---|---|---|
| Contact information | Require an accepted contact method before confirmation. | Allow a clearly marked pending entry for a missing contact. | Who follows up, and when does pending expire? |
| Policy disclosure | Require staff to record disclosure before confirmation. | Flag the booking for a manager to discuss before confirmation. | Can staff see which policy applies and record what happened? |
| Capacity | Block confirmation outside the configured limit. | Send an exception request to an authorized manager. | Is a request separate from a confirmed reservation? |
| Audit trail | Record the creator and relevant changes automatically. | Use a documented manual log if the system cannot record a needed detail. | Can the next shift find the history and responsible person? |
A strict required field can prevent omissions, but it can also slow a call or encourage staff to enter placeholder information. Ask whether the system can distinguish a valid contact method from a generic value, and set a rule against using a fake number just to complete the form. If a guest cannot provide the required information, staff need a defined next step rather than a workaround.
A pending workflow gives staff room to handle exceptions, but only if someone owns the follow-up. Ask whether pending entries appear on the shift’s task list, whether they hold capacity and how they are resolved. If the software cannot support that process, decide whether a small, controlled manual log is practical. A note that nobody reviews is not a control.
The audit trail should help resolve ordinary questions as well as disputes. If a party size changes, can the manager tell who changed it and when? If a policy was discussed by phone, can the team record that fact without suggesting the guest accepted terms they did not accept? Review restaurant management software in the context of the actual shift handoff, not just the number of fields on a screen.
Work through an ordinary booking and an exception
Hypothetical example: A restaurant has six physical tables available at 7:00 p.m. Its seating plan allows one guest party per table for that time slot, and each table can seat up to four guests. Five tables already have confirmed parties. For this example, assume no tables can be combined and no pending requests are holding space.
A caller asks for a table for three at 7:00. The host enters the guest’s name, phone number, local date and time, and party size. The host explains the restaurant’s cancellation policy and records that it was discussed. Because one suitable physical table remains, the expected result is an ordinary confirmed booking for the sixth table. The host owns completion of the entry; the shift manager checks the reservation list during handoff.
Later, another caller asks for a table for two at the same time. There are now six confirmed guest parties using six physical tables. Even though two guests would fit at an individual table, there is no unassigned table under this seating plan. The expected result is no ordinary confirmation for 7:00.
The host can offer a different time or, if restaurant policy permits, ask a manager to consider an exception. An exception might require the manager to change the seating plan or capacity setting; it is not simply another routine entry. The host should tell the caller that the requested time is not confirmed while approval is pending. The manager owns the decision and any approved plan for seating the party. The record should show the decision and who made it, or the team should use its documented manual log.
Check that the system distinguishes a request from a confirmed booking and that the display gives staff enough context to avoid promising a table prematurely. If it does not, ask what process the vendor recommends. Also consider whether a capacity change affects other channels: a host needs to know which availability view is authoritative before offering a time.
These controls also matter when plans change. A clear record can help staff contact guests and understand cancellations. For a broader look at the operational impact, see the guide to measuring reservation no-shows.
Run a pass-or-fail vendor demonstration
Give each vendor the same short script and ask a staff member who takes calls to walk through it. Use fictitious guest details in a safe demonstration environment. Disable real guest messages, payments and other external actions; a practice booking must not contact a person or trigger a real transaction. This is a simulation, not a live service pilot.
- Required details: Start a phone booking and omit the contact method. Pass if the demonstrated result matches your rule: the booking is blocked from confirmation or becomes a clearly identified follow-up with an owner. Fail if staff can confirm it as complete without the required information or an approved exception.
- Policy disclosure: Ask where the host sees the relevant policy and records the conversation. Pass if the next shift can see the disclosure record and its status. Fail if the team cannot tell whether the policy was discussed.
- Capacity: Fill the simulated time slot to its stated physical-table limit. Pass if another ordinary booking cannot be confirmed and the exception route matches your approval rule. Fail if an unauthorized employee can confirm the extra party as a normal booking.
- History: Change the simulated party size and review the record as a different staff member. Pass if the creator and relevant change history are visible to the people who need them. Fail if the team cannot establish who made the change or find an agreed manual record.
- Recovery: Ask the vendor to demonstrate what staff should do if the booking screen is unavailable. Pass if the team can use a documented manual intake and assign someone to enter and reconcile it later. Fail if there is no owner or the team has no way to check for duplicate entries.
For recovery, agree on a paper or other controlled intake method that captures the same essential details and disclosure status. Once the system is available, the assigned person should check existing reservations before entering each manual booking, then compare the manual list with the system and resolve differences. Do not assume a vendor supports offline booking or an automatic import.
Ask support: “If an employee reports that a reservation changed unexpectedly, what history can our manager see, what can support investigate, and what information should we provide?” Also ask about permission settings, exports, booking-channel attribution and fees. If your restaurant uses Google bookings, ask whether that path is available for your location and how it relates to staff-entered availability.
Before any live service pilot, agree on its scope, staff owners and recovery procedure with the vendor. A live pilot involves actual operations, so keep its guest communication and payment decisions separate from the simulated checks above.
Bring your completed requirements and demonstration script to Fleksa. Compare your restaurant reservation requirements with Fleksa and confirm which controls are available for your setup.
Frequently asked questions
Should a phone booking require a phone number?
Choose a contact rule that lets staff reach the guest when needed. If another contact method is acceptable, define it. If no contact is provided, decide who can approve or follow up on the exception.
Is a staff-created booking automatically a capacity override?
No. An ordinary staff entry fits the restaurant’s configured capacity. An override or exception is a separate decision to handle a request outside the normal limit and should have an authorized owner.
What should an audit trail show?
Ask to see the booking creator, relevant changes and their times, current status, and any exception decision. Confirm that the staff responsible for handoff can access the history or its agreed manual equivalent.
