A practical guide / Fonix.AI
Restaurant reservations: a practical implementation guide
A worked scenario, illustrated decision review and a practical pilot worksheet.
A restaurant AI receptionist needs a seating plan
A restaurant AI receptionist should turn a party's request into a table allocation the floor team can honour. Opening hours and a calendar are not enough: party size, seating duration, table combinations, accessibility and the kitchen's last-order policy can all change whether a reservation works.
Start a Fonix.AI evaluation with one branch and its actual reservation rules. Establish which reservation system can supply availability and accept a booking. Until that write is available, the useful outcome is an owned reservation request, with wording that clearly distinguishes it from confirmation.
Capacity is a time interval, not a free-table count
A table vacant at 8 pm may already be reserved at 8:30. Availability needs the whole approved seating interval, including any turnaround buffer. Combined tables also need explicit identifiers: allocating tables A and B together must prevent either from being sold independently during that interval.
Ask about the party before promising an arrangement. A wheelchair space, high chair or outdoor preference can change the fit. Dietary questions should use the restaurant's approved information, with staff handling uncertain allergen questions. Do not turn a preference into an assurance the kitchen has not made.
Worked example: a six-person party at a busy branch
In this fictional floor plan, table A seats four and table B seats two. They can be combined, but B already has an 8:15 booking. A six-person request for 8 pm therefore cannot use A+B for the restaurant's full seating duration. The agent should offer a later interval that fits both tables, an approved alternative configuration, or staff review.
If the caller chooses 9 pm, read back the branch, date, party size and any deposit requirement before committing. “Near the window” should remain a request unless a particular table is actually assigned. A caller changing from six to eight guests needs a new capacity check even if the original reservation already exists.
| Change | Check again | Floor-team record |
|---|---|---|
| Party grows | Seat count and combination rules | Revised count and allocation |
| Arrival shifts | Entire seating interval | New time and released old slot |
| Guest is late | Approved grace period | Expected arrival and staff decision |
| Caller cancels | Booking identity and cancellation state | Released capacity and reference |
Keep cancellations and late arrivals actionable
Retrieve an existing booking before creating a replacement. Use the booking reference plus the restaurant's verification procedure; a shared family number may match several reservations. Preserve the old reservation until the replacement succeeds, or apply the reservation system's supported change operation.
For a late-arrival request, convey the actual policy and record the caller's estimate. If staff must decide whether to hold a table, the agent should request that decision rather than invent an extension. The floor team needs an ordered queue of exceptions with an owner, not an unstructured transcript dump.
A service-period rehearsal for the floor team
Give the pilot one branch's floor plan, seating durations and deposit rules. Include table combinations and the operator who approves exceptions. Use test reservations rather than blocking real dinner-service capacity during initial checks.
| Pilot case | Required behaviour |
|---|---|
| A combined table overlaps a later booking | Reject that interval or offer a valid alternative without consuming either table twice. |
| The party grows after confirmation | Recheck all required seats and resources; retain the original booking until the change succeeds. |
| A caller requests an allergen assurance | Use approved kitchen information and staff escalation rather than inventing a guarantee. |
Measure seatable confirmed parties divided by all parties told their booking was confirmed. Record unnecessary refusals as well as clashes. Compare similar service periods and include staff time spent correcting table allocations.
Does a preference guarantee a particular table?
Only if the reservation system actually assigns that table under the restaurant's rules. Window seating, outdoor space and adjoining tables should remain requests when staff still need to decide. Make the distinction in both confirmation wording and floor notes.
Run the Friday-night test before opening the line
Replay overlapping bookings, a table combination conflict, a branch correction and a cancellation arriving twice. Count allocations that the floor system accepts and staff can seat, not merely conversations ending with “booked”. Review refusals too: unnecessary rejection of a valid combination loses customers.
Bring your seating map and reservation rules to test a table reservation flow. Use overflow handling to define what happens when the phone queue exceeds capacity, and after-hours routing for closed-service periods.