Restaurant AI Reservations: Party, Time and Table Errors

Your agent answers the phone for restaurants. A caller says "table for four, Friday at seven." The agent checks availability, writes a booking and sends a text. The call sounded fine. The only proof is a row nobody reads until Friday at 7:05 p.m.

That is the problem with a restaurant AI reservation phone line, and with AI restaurant reservations in general. A wrong order is caught at the pass. A wrong reservation is caught at the host stand, with a line of guests watching. This post covers the failures that reach that moment. They are party size, dates and times, table rules, deposits and the write-back to the booking platform. It ends with an audit for live calls and a test set you can copy.

This post is for the team that built the agent inside a larger product, such as a host-stand app or a restaurant reservation system. Voice AI for restaurants is one feature among many there. The AI reservation agent is live across many restaurants. Every prompt change reaches all of them. For the ordering side of the phone, see our food ordering QA playbook and the allergy and add-on errors post. This post stays on restaurant phone reservations and their reservation errors.

What one phone booking actually writes

A reservation is a small record. Every field in it comes from one spoken sentence, and every field can be wrong without any error being raised.

Google's Actions Center docs show the shape well. A booking slot carries `start_sec`, the start time in UTC seconds. It carries `duration_sec`. It carries `party_size`, which sits inside a `resources` message for dining. It carries an optional `room_id` for seating areas. It also carries a `confirmation_mode` that says whether the booking is confirmed now or later (Google slot definition). Your booking platform uses other names. The fields are the same.

That gives six places for speech to corrupt the record: party size, date, time, seating area, policy and contact. The grid below shows which failure class can hit which field. It shows where failures can occur, not how often. Your audit will measure frequency.

No public data says how often these fail. The vendor pages, trade articles and software guides reviewed for this post publish no accuracy figure for phone reservation agents. OpenTable's partner page lists capabilities and customer quotes. It says nothing on party size limits or hand-off. You have to measure your own agent.

Party size: the short-answer problem

Party size is the field most often captured in one or two syllables. The agent asks "how many guests?" and the caller says "four." Short utterances are where speech recognition is weakest.

A 2024 paper on phone-based digit recognition makes this concrete. The authors built a digits-only model and compared it with general engines on 1,149 utterances at 8 kHz. Google's recognizer sometimes returned blank output for single digits. Whisper made more errors on short utterances. The word error rates were 1.8% for the micro-model, 2.9% for Google configured for numeric content, and 4.6% for Whisper-Large (Chhablani et al., arXiv 2402.01931). The test used digits, not restaurant calls. The lesson carries over. One-word numbers are a weak spot, and phone audio makes it worse.

Three mechanisms matter for party size.

1. Near-homophones. "For" and "four." "To" and "two." A language model repairs these from context. A bare answer has no context.

2. Confusable numbers. "Two" and "ten." "Six" and "sixteen." "Fifteen" and "fifty." The sound gap is small. The table-plan gap is large.

3. Formatting. Numeral conversion is an option, not a given. Deepgram's `numerals` setting is off by default and converts spoken digits one at a time (Deepgram numerals docs). Check it for your language.

Then there are the counting errors that no transcript shows.

The fix has three parts. Read the number back with context: "Four guests, including two children, Friday at 7. Is that right?" Add a code rule: above the restaurant's large-party threshold, force a confirmation or hand-off. And save the audio clip of the party-size turn for review. Our posts on entity accuracy and tool argument accuracy cover the method.

Large parties need extra care. Online channels cap party size and push big groups to the phone. Google's docs describe an "above max party size" option that tells the guest to call the restaurant (Google Actions Center). Your phone agent gets the hardest bookings. OpenTable lets a restaurant define a large party with a threshold such as 6 or 16, and decide whether to accept them (OpenTable availability controls). Use that threshold per restaurant, not a global default.

Dates and times: relative phrases and the server clock

Callers rarely say "October 23." They say "this Friday," "the 5th," "tonight" and "around seven." Each needs a policy, and it must run on the restaurant's clock.

The server clock bug. Say your agent runs on a server in UTC. A caller in Los Angeles phones at 8:30 p.m. on Wednesday, October 21. That is 03:30 UTC on October 22. If the code computes "tomorrow" from the server date, it books October 23. The guest meant October 22. This is a worked example, not a measured rate. It hits evening calls in the Americas, from early evening until local midnight.

The same trap sits in storage. Google's slot uses `start_sec` in UTC. Converting local time to UTC needs the restaurant's zone, not the server's. A multi-location group can span zones. Store the zone with the restaurant, and pass it explicitly. Libraries do not save you here. The `dateparser` library defaults its `TIMEZONE` to the local zone, and its `PREFER_DATES_FROM` to `current_period` (dateparser settings). Set `RELATIVE_BASE` and `TIMEZONE` yourself, and test the result.

Daylight saving. Python's docs note that a repeated hour occurs when clocks roll back, and `fold` tells the two apart (Python datetime docs). It matters only for late-night venues. Test one DST weekend a year.

Ambiguous phrases need a policy. Here is a simplified resolver. It returns every date the caller could mean. If there is more than one, the agent asks.

from datetime import date, timedelta
import calendar

DAYS = ["monday", "tuesday", "wednesday", "thursday",
        "friday", "saturday", "sunday"]

def weekday_candidates(word, qualifier, today: date) -> list[date]:
    """Every date the caller could mean. More than one = ask."""
    ahead = (DAYS.index(word) - today.weekday()) % 7
    first = today + timedelta(days=ahead)
    if qualifier == "next":
        return [first + timedelta(days=7)] if ahead == 0 \
            else [first, first + timedelta(days=7)]
    return [first]  # "this Friday" or bare "Friday"

def day_of_month_candidate(day: int, today: date):
    """'The 5th': this month if still ahead, else next month."""
    y, m = today.year, today.month
    for _ in range(2):
        if day <= calendar.monthrange(y, m)[1] and date(y, m, day) >= today:
            return date(y, m, day)
        y, m = (y + 1, 1) if m == 12 else (y, m + 1)
    return None  # e.g. no 31st; ask the caller

On Wednesday, October 21, `weekday_candidates("friday", "next", today)` returns October 23 and October 30. The agent must say both and ask. "The 5th" returns November 5, a different month from today, so the read-back must include the month. A day-of-month answer that lands in another month is the one callers miss.

Time of day has its own traps.

• AM or PM. "Seven" at a dinner-only restaurant is 7 p.m. That rule belongs in the restaurant's config.
• "Around seven." Offer the nearest open slots. Never round silently.
• Service windows. A 9:45 p.m. slot may be inside business hours and past the kitchen's last seating.

Tables, areas and turn times

"Table for four" is not a request for four seats. It is a request for a table of the right type, in the right area, free for the right length of time.

OpenTable's docs show how many knobs that is. Bar, counter, high-top and patio seating can be made reservable online. Turn times can be set by table or area. The example is a bar that turns faster than the dining room (OpenTable table management). Google's model treats a seating area as a `room_name`, and says a room name should be used only for seating areas or prepaid experiences. It also recommends that the default seating area carry no room (Google seating sections).

Three agent errors follow.

1. Wrong area. The guest asks for "outside." The agent books "any," because the area slot was never filled. Or it books the bar, which has the earliest opening.

2. Wrong duration. A party of six gets the same 60-minute block as a party of two. Eat App describes 60-minute windows against a 90-minute dinner service causing overlaps (Eat App).

3. Combined tables. The same guide describes two four-tops booked separately while also assigned as a combined eight-top. An agent working from a cached view can offer both.

Accessibility and child seating. Callers ask for a high chair, a wheelchair-accessible table or a quiet corner. They mention a service dog. These are not party-size items, and not free text nobody reads. Model them as flags the host stand shows on the ticket. A high chair is not a seat.

Service animals have a specific rule. Under the ADA regulation, 28 CFR 36.302(c)(6), staff may ask only whether the animal is required because of a disability and what work or task it is trained to perform. They may not ask about the person's disability. They may not require documentation such as a certificate (eCFR, 28 CFR part 36 subpart C). So a reservation agent must not ask for proof. It should note the animal and not lower the party's priority. This is not legal advice. Have counsel review the wording for your restaurants.

The gate order matters too. Put the cheap, deterministic checks first, then the booking write.

Deposits, holds, waitlists and changes

Money and state errors are quiet. The call ends warmly, and the guest later meets a fee nobody mentioned.

Fees are real and vary. The Star Tribune reported in February 2025 that Twin Cities restaurants charge $10 to $40 per person for no-shows, and some charge the full meal cost. One co-owner said most charged no-shows disputed the fee with their bank (Star Tribune). OpenTable told the paper that deposits cut no-shows by 50%, a vendor claim. If your agent quotes or omits a policy wrongly, the dispute lands on the restaurant.

Policy errors to test:

• Wrong amount. The agent reads a fee from its prompt, not the restaurant's current setting.
• Policy skipped. A party that needs a deposit is booked without one being mentioned.
• Waitlist said as booked. The guest is waitlisted and told "you're confirmed." Google's waitlist docs treat waitlists as separate rules with their own party size limits, so the states differ.
• Pending said as confirmed. Google's slot has a `confirmation_mode`, and an asynchronous booking is not final when the call ends. The agent's closing line must match the state returned by the tool.

Changes and duplicates. "Can you move my seven o'clock to eight?" is the riskiest sentence in the call. A weak flow creates a new booking at 8 and leaves the 7 o'clock one. Now the restaurant holds two tables. Eat App lists double booking among the common failures (Eat App). Fix it in the tool design: modify in place using the booking ID, or cancel first and create second inside one transaction, with an idempotency key so a retried call cannot create a copy. Then test it: call twice for the same name and time, and check the book.

Check the book, not the call

The call is the front door. The record is the truth. OpenTable says each partner assistant writes bookings into the OpenTable reservation book, and that capabilities vary by partner (OpenTable voice AI page). If you run your own agent on a platform like that, the write is your risk.

Compare three things after each test call and each sampled live call:

1. What the caller said, from the audio.

2. What the agent sent in its tool call.

3. What the booking system shows five minutes later.

A gap between 1 and 2 is a hearing or reasoning error. A gap between 2 and 3 is a write-back error, such as a dropped field or an applied default. Our post on silent tool failures covers the second class. The post on transcript versus audio evaluation explains why the first class needs the recording. The transcript is the recognizer's own guess. It will say "four" even when the guest said "for." That is why a restaurant AI reservation phone audit needs the audio.

Sync lag adds a third. Eat App notes platforms that batch updates every 15 minutes, which lets two guests claim one table. If your agent caches availability, test a slot taken mid-call.

How to audit a restaurant AI reservation phone agent

This audit needs recordings and read access to the booking record. It changes nothing in the agent.

1. Pull a sample. Take 150 completed booking, change and cancel calls from the last 30 days. Spread them across restaurants and busy and quiet hours.

2. Write the spoken truth. A reviewer listens to each call and records what the guest asked for, field by field: party size, date, time, area, notes, contact. Use the audio, not the transcript.

3. Diff against the record. Compare the spoken truth with the booking record. Mark each field as match, mismatch or unrecorded.

4. Classify each miss. Use the grid above: mishearing, relative reference, silent default, stale availability, wrong write-back. Add a severity: guest turned away, wrong table, or cosmetic.

5. Compute rates with an interval. Report the field error rate and its 95% Wilson interval, not a bare percentage.

6. Turn misses into tests. Each miss becomes a scripted scenario with the expected record. Run the set before every prompt or model change.

Step 5 needs worked math. Suppose the audit finds 6 call-level errors in 150 calls. That is 4.0%, with a Wilson 95% interval of 1.8% to 8.5%. The sample cannot tell 2% from 8%. Zero errors in 150 calls puts the upper bound near 3/150, or 2%, by the rule of three. These numbers are a worked example, not a benchmark.

Small rates multiply by tenants. Assume, for illustration only, 40 phone bookings a night and 3% wrong: 240 bad bookings a night across 200 restaurants. Our multi-tenant testing post covers sampling across customers, and scoring every call covers when sampling stops being enough.

A test set you can copy

Start with about 40 scenarios. Twelve are below. Each row gives the caller line, the expected record and the trap. Run each under three conditions: quiet, restaurant noise and speakerphone at 8 kHz. Add accents and pace from your caller base. Our accent robustness post covers the matrix.

Grade each run on the record, not the sound of the call. A run passes only if every field matches and the closing line matches the state.

Evalgent fits at two points here. It generates test scenarios from the agent's prompt and flows, such as large-party branches and policy gates. It then calls the agent over phone, SIP or WebRTC with caller profiles that vary accent, pace, interruption and background noise. It judges from the audio, so a "for" that became a "four" is visible. For live traffic, teams push call recordings. Evalgent transcribes them, maps them to scenarios and flags tool-call failures and policy failures with fix recommendations. Evalgent works with teams to set up evals for their first agent. It is not self-serve.

Run the fixed set before any prompt, model or speech-to-text change ships, and compare it with the last passing run. Our go-live checklist lists the gates. If you are choosing a vendor instead of auditing your own agent, see the vendor evaluation guide. For adjacent logic, see appointment scheduling testing and hotel reservation errors.

Frequently asked questions

Can AI take restaurant reservations over the phone?

Yes. OpenTable lists 17 third-party voice AI partners whose assistants answer calls and write bookings into its reservation book. Taking the call is the easy part. The risk is in party size, relative dates, seating area and policy. Audit those fields against the booking record, not against how the call sounded.

How accurate is a restaurant AI reservation phone system?

The sources reviewed for this post publish no independent accuracy figure. Vendor pages cite customer quotes, not field-level error rates. Measure your own. Audit about 150 recent calls against the booking record and report the rate with a confidence interval. At 150 calls, a 4% rate has a 95% interval of roughly 1.8% to 8.5%.

What happens when AI mishears the party size on a reservation?

The booking is stored with the wrong size and nothing flags it. The host finds out at the door, or the table plan breaks earlier. Reduce the risk with a read-back that includes context, a plausibility check against the large-party threshold, and an audio clip of the party-size turn saved for review.

Can an AI phone agent handle large party bookings and deposits?

It can, if the rules are per restaurant. Large-party thresholds, such as 6 or 16 in OpenTable's example, are set by each restaurant. Deposit amounts vary as well. The agent should read both from configuration, state the policy aloud, and hand off when a rule is unclear. Test a party just above and just below each threshold.

How do you test an AI reservation agent before it goes live?

Script about 40 caller scenarios with expected records. Cover mishearings, relative dates, seating areas, policies, changes and cancellations. Run each in quiet, noisy and 8 kHz speakerphone conditions. Grade the booking record, not the transcript. Re-run the set before every change, and add each live miss as a new test.

Does AI write reservations into OpenTable correctly?

OpenTable says partner assistants write bookings into its reservation book, and that capabilities vary by partner. It does not publish write-back accuracy. Check yourself. Compare what the caller said, the agent's tool arguments and the booking record five minutes later. Any gap between the last two is a write-back error.

How does AI handle reservation changes and cancellations by phone?

Well-built agents modify the existing booking by ID, or cancel and recreate it in one transaction with an idempotency key. Weak ones create a second booking and leave the first. Test the duplicate case, and test a caller with two bookings who says "cancel Saturday." The agent must ask which one.

How should an AI host handle accessibility and high chair requests?

Record them as flags on the booking ticket, not as extra seats. For service animals, 28 CFR 36.302(c)(6) allows only two questions and bars requiring documentation, so the agent should not ask for proof. This is not legal advice. Have counsel review the wording, then test these requests in your scenario set.

The bottom line

A restaurant phone booking is only as good as the six fields it writes, and most errors hide in the gap between what the guest said and what the book shows. Audit a sample of live calls against the record, turn every miss into a test, and run that set before each change ships.