Restaurant Catering Inquiries by AI: What It Gets Wrong

A catering call looks like a long reservation call. It is not. A reservation books a table for tonight. A catering inquiry starts a negotiation that ends days or weeks later with a kitchen producing food for a crowd. The phone call is only the front door. What the agent hears becomes a lead record, a quote, a prep sheet and a delivery slot.

This post is for teams that built their own voice agent inside a restaurant platform, POS or ordering product. Your catering inquiry voice agent now takes calls across many locations, and every prompt change ships to live callers. Here is where a restaurant catering inquiry AI goes wrong, what it must never say, and how to test it first. For the single-table version of this problem, see restaurant AI reservations: party size, time and table errors. For venue-style group bookings, see party booking AI for venues.

Why catering inquiries are a different problem

Three things separate catering from the rest of a restaurant phone line.

First, the stakes per call are larger. A pizza order is one ticket. A catering order can be a day of prep and a deposit. People expect AI catering phone orders to behave like takeout orders. They do not.

Second, the call is rarely a transaction. Callers ask if you can feed 60 people next Friday, what it costs and whether you handle gluten-free guests. The right outcome is often a clean lead, not a booked order.

Third, the commitments stack. One call can set a date, a headcount, a service mode, a dietary constraint and a money expectation. An error in any of them reaches the kitchen later, when nobody is on the line to fix it.

Catering inquiry: a request for food service for a group, captured by phone or web, that is not yet a confirmed order until the restaurant accepts it and the required deposit or approval is in place.

That definition matters for testing. Your agent needs to know which of those two states a call is in. Most failures in this post are a mislabel of state or a mis-capture of one field.

The five commitments a catering call can create

Treat every catering call as five separate captures, and score each on its own. A private event inquiry AI faces the same five.

A call can get four right and one wrong, and the record still looks complete. A whole-call pass hides that.

Headcount: ranges, rounding and the fifty versus fifteen trap

Callers rarely give one clean number. They say "about fifty," "forty to sixty," "fifty, maybe more," or "twenty adults and some kids." Each phrasing needs a different record.

Four headcount errors show up in test scenarios.

1. Range collapse. "Forty to sixty" is stored as 40. The kitchen preps for the floor of the range.

2. Digit confusion. "Fifty" and "fifteen" differ mainly in which syllable carries the stress, and phone audio can flatten that. The number is off by 3x and nobody notices.

3. Unit mix-up. "Twenty adults and ten kids" becomes 20, or 30 at adult portions. Neither is right.

4. Stale number. The caller revises from 40 to 55 near the end of the call. The record keeps 40.

Here is why range collapse costs real money. This is a worked example using a published buffet guideline of 6 to 8 ounces of meat or fish per person from WebstaurantStore's catering portion guide.

A "forty to sixty" call stored as 40 can leave the kitchen 10 pounds short of protein at the high portion (20 lb prepped against 30 lb needed). Stored as 60 when 40 arrive, it overbuys by the same 10 pounds. The agent should store the range, flag it as unconfirmed, and never pick a point for the caller.

A safe record keeps three fields: `headcount_min`, `headcount_max` and `headcount_confirmed`. The last stays `null` until a human sets it. Then the agent cannot finalize a wrong guest count.

Restaurants and caterers already work this way. A published example is the catering office at Tufts University, which requires a final guest count "3 business days before the event" for drop-off service, and states that decreases after the deadline do not reduce the quoted cost (Tufts Catering). Your agent should know your version of this rule. It should not invent one.

Dates, times and lead time

Catering has a lead-time rule that varies by location and order size. One national chain states that catering orders are placed "24 hours before your event at all Restaurants," and notes that lead times vary by restaurant (Chick-fil-A). Your own rule will differ.

So when callers ask how far in advance do you need to book catering, the agent must answer from configuration, per location, per order type. A model's general knowledge will be wrong for you.

Date and time errors cluster around five patterns.

• Relative dates. "This Friday" said on a Thursday night. "Next Saturday" meaning the one after the coming one.
• Event time versus arrival time. The caller says "the lunch is at noon." The record stores noon as delivery, with no setup time. Food arrives as guests sit down.
• Below the lead time. The date is 18 hours out. The agent says "sure" instead of routing to a manager.

The agent should read back the date as a full weekday and calendar date, plus the time and what the time means. "Friday, October 30, guests eat at noon, we arrive by 11:15." Read-back is the cheapest fix, and it only works if the test checks the stored value, not just the spoken one.

Pickup, drop-off, delivery and on-site

Service mode changes price, labor and risk. It also changes what the agent must collect.

Pickup needs a collector and a time. Drop-off delivery adds address, access notes and an on-site contact. Delivery with setup adds tables and chafing dishes. On-site service adds staff, rentals and venue rules.

Callers blur these. "Can you bring it over?" may mean drop-off or setup. If the agent assumes drop-off, the customer expects a server. If it assumes setup, the quote is wrong. The agent should ask one clarifying question and store the answer as an enum, not free text.

Addresses carry their own risk. Catering goes to offices, halls, parks and loading docks. The same failure modes appear as in delivery calls, so see pizza delivery address and callback number errors for the address and phone number capture tests.

Food safety adds a time limit. USDA defines the danger zone as "temperatures between 40 and 140°F when perishable food spoils rapidly," and says food should not sit in it more than two hours, or one hour above 90°F (USDA FSIS). A drop-off two hours before guests eat is a safety question. The agent should not answer it. It should capture the event time precisely.

Dietary needs and allergens

Dietary capture on a catering call is a different task from an allergy question on a single order. The group is bigger, the restrictions are often mixed, and the person calling is rarely the person who will eat.

The FDA lists nine major food allergens: milk, eggs, fish, crustacean shellfish, tree nuts, peanuts, wheat, soybeans and sesame. Sesame became the ninth on January 1, 2023, under the FASTER Act (FDA). Your agent's allergen list should match that set. Many prompts still carry eight.

Test these rules.

1. The agent captures dietary restrictions with a count: "6 guests vegetarian, 2 with a tree-nut allergy."

2. It separates preference ("gluten-free by choice") from medical severity ("celiac" or "anaphylactic").

3. It never states that a dish is safe, nut-free or free of an allergen. It records the need and routes to staff.

4. It writes the restriction onto the kitchen-facing prep sheet, not just a CRM note field.

For single-order allergy failures, see AI phone ordering allergy and add-on errors. The catering version adds one more risk. A note in a free-text field that nobody reads is a silent failure, even though the call looked fine.

Money: statements the agent must not make

Money is where a friendly agent does the most damage. Callers ask "what does it cost?" in the first thirty seconds. A model trained to be helpful will try to answer.

Decide in advance which money statements are allowed. Here is a starting policy for an inquiry-stage agent. Adapt it to your menu and your rules.

On deposits, be careful. Policies are specific. The Tufts example above requires "an advance deposit of 50% of the quoted price" from outside clients, due no later than five business days before the event. Yours may differ. If your agent can take a payment, that is a payments flow with its own tests. If it cannot, it should say so plainly and route the caller.

When you ask whether an AI should quote catering prices over the phone, the safe answer for most teams is no, with one exception. Reading a published menu price from config is fine. Combining items, headcount and fees into a total is a quote, and a quote is a commitment.

Tentative hold versus booking, and the callback promise

Two of the quietest failures sit between the inquiry and the confirmed order.

Hold language. Callers hear "we'll pencil you in" as a booking. If no hold exists in the calendar, no hold language is allowed. If one exists, the agent should state when it expires.

Callback promises. "Our catering manager will call you back" is an operational promise. Who is it? By when? In which queue? If the agent says "within the hour" and the queue is closed, the caller waits and the lead goes cold. The agent should only promise what the routing config can deliver, such as "the catering team returns calls on weekdays by end of day."

The same labels should drive the CRM stage. `inquiry` is not `quoted`, and `quoted` is not `confirmed`.

Write-back: the record that matters

The call ends and a record is left. For a restaurant catering inquiry AI, that record is the product. If it is wrong, a good-sounding call still failed.

A minimal catering record might look like this. It is simplified. Field names are yours to define.

{
  "lead_state": "inquiry",
  "event_date": "2026-10-30",
  "event_time_meaning": "guests_eat",
  "event_time": "12:00",
  "headcount_min": 40,
  "headcount_max": 60,
  "headcount_confirmed": null,
  "service_mode": "drop_off",
  "address_verified": false,
  "dietary": [
    {"type": "tree_nut", "count": 2, "severity": "allergy"},
    {"type": "vegetarian", "count": 6, "severity": "preference"}
  ],
  "quote_status": "none",
  "hold_status": "none",
  "callback": {"owner": "catering_queue", "by": "2026-10-23T17:00"},
  "contact_phone_confirmed": true
}

A validator can check the record before it is written. This is simplified Python.

from datetime import date

ALLERGENS = {"milk", "egg", "fish", "shellfish", "tree_nut",
             "peanut", "wheat", "soy", "sesame"}

def validate(rec, min_lead_days=1):
    errs = []
    if rec["lead_state"] not in {"inquiry", "tentative", "quoted", "confirmed"}:
        errs.append("bad lead_state")
    lo, hi = rec["headcount_min"], rec["headcount_max"]
    if lo is None or hi is None or lo > hi:
        errs.append("headcount range invalid")
    if rec["lead_state"] != "confirmed" and rec["headcount_confirmed"]:
        errs.append("final headcount set before confirmation")
    if rec["lead_state"] == "inquiry" and (
        rec["quote_status"] != "none" or rec["hold_status"] != "none"):
        errs.append("inquiry carries quote or hold")
    days = (date.fromisoformat(rec["event_date"]) - date.today()).days
    if days < min_lead_days:
        errs.append("below lead time: route to manager")
    for d in rec["dietary"]:
        if d["severity"] == "allergy" and d["type"] not in ALLERGENS:
            errs.append(f"unknown allergen {d['type']}")
    return errs

A validator is a floor, not a judge. It catches inconsistent records. It cannot tell you that the caller said "fifty" and the record says 15. For that you need to compare against what was actually said. Silent failures of this kind are covered in how to detect silent tool failures in voice agents.

Why the speech layer matters for catering

Catering calls are hard audio. Callers phone from kitchens, cars and offices. They read long numbers and spell names.

Two published studies set sober expectations.

Koenecke and colleagues tested five commercial speech recognition systems on interviews with Black and white speakers. The average word error rate was 0.35 for Black speakers and 0.19 for white speakers (PNAS, 2020). That was on interview speech, not phone orders. But it is a clear warning that error rates are not uniform across callers, so an average over your test calls can hide a bad tail.

A second study looked at hallucination. Running OpenAI's Whisper on 13,140 short audio segments, the authors found hallucinated content in about 1.4% of transcriptions. 38% of those hallucinated transcriptions included at least one explicit harm (Careless Whisper, FAccT 2024). Hallucinated segments had a higher share of non-vocal audio (29% versus 26%). Long pauses are common on catering calls, when a caller checks a spreadsheet or asks a colleague.

Your own stack may differ from both. The point is not the exact figure. It is that a transcript is an output, not ground truth, and a judge that only reads it will miss errors the audio contains. Evalgent evaluates from the audio, not only the transcript, which is the reason a "fifty" heard as "fifteen" can still be caught. For the metric itself, see how to measure hallucination rate for voice agents.

How to test catering inquiry calls before they reach every location

Use this sequence for any prompt, model or flow change. It assumes a small team and no QA function.

1. List the commitments. Write down the five fields, the allowed states and the statements the agent must never make. This is your spec.

2. Build scenarios from the prompt. Cover each branch: pickup, drop-off, setup, on-site, each allergen, each state. Evalgent generates test scenarios from an agent's prompt and flows, including branches, policies and coverage gaps, which saves the first pass of this work.

3. Add caller conditions. Vary accent, speech pace, interruptions, response delay and background noise. Include a kitchen-noise caller and a slow caller who checks a number mid-call. Evalgent's caller profiles cover these settings and languages including English, Spanish, French, German and Hindi/Hinglish.

4. Write hard-constraint assertions. "Never quotes a total." "Never says nut-free." "Never says reserved when `hold_status` is none." These should fail the call on one violation.

5. Compare record to audio. For every scenario, check the stored fields against what the caller said. Score each field separately: date, headcount, mode, dietary, money.

6. Run it before and after each change. A prompt tweak that improves greeting tone can break range handling. Compare pass rates per field.

7. Review a sample by ear. Humans should listen to failures and to a random slice of passes. Evalgent supports human review of verdicts.

8. Monitor live calls. After launch, push recordings, map them to scenarios and flag tool-call failures, policy failures and PII leakage. For setup guidance, see how to monitor voice agents in production.

Keep the set as a golden dataset and a go-live gate. Test a restaurant AI phone agent catering flow on its own, apart from ordering.

A scorecard with thresholds

These thresholds are starting points, not industry standards. Together they define catering order accuracy for a restaurant catering inquiry AI.

Scripted scenarios are deterministic, so a miss is a defect, not noise. For live traffic, track rates and review the tail. See escalation accuracy for handoff measurement and how to test a food-ordering voice agent for the order-side playbook.

Frequently asked questions

Can AI answer restaurant catering calls?

Yes. Using AI for restaurant catering calls works for front-door tasks: greeting, capturing event details, answering approved FAQs and creating a lead. It should not quote totals, certify allergens or confirm holds. Treat it as an intake agent that hands a clean record to a person.

How does AI handle catering headcount?

Done well, it stores a range and a confirmed number as separate fields. It repeats the number back, flags ranges as unconfirmed and never rounds. A final headcount should come from a human or a confirmation step that follows your policy, such as a guarantee deadline before the event.

Should AI quote catering prices over the phone?

For most teams, no. Reading a published per-person menu price from current config is fine. A total depends on items, headcount, fees, tax and setup, and a spoken total becomes a commitment. Route quote requests to staff or to a documented quote flow.

How far in advance do you need to book catering?

It depends on the restaurant and the order size. One national chain states 24 hours for its restaurants, with variation by location. Your agent should read the rule from per-location configuration and route anything below it to a manager, not say yes.

Can AI take a catering deposit over the phone?

Only if you build and test a payment flow for it. Otherwise the agent should explain the next step and route the caller. Never let it imply a date is held because the caller mentioned a deposit. Hold status should come from your system.

How do you test a catering voice agent?

Generate scenarios from the prompt, vary caller conditions, and compare each stored field against the audio. Add hard assertions for forbidden statements. Run the set before every change, then monitor live calls for tool failures and policy misses. The how-to section above gives the steps.

What happens if AI gets the guest count wrong?

The kitchen preps for the wrong crowd. Food runs short or is wasted, the quote is off and the customer finds out on event day. Prevent it by storing ranges, confirming read-backs and checking the record against the audio before launch.

How should AI handle allergies on catering orders?

It should capture each restriction with a count and severity, never claim a dish is safe, and write the need to the kitchen-facing sheet. Anything medical should go to staff for confirmation. Use the full nine-allergen FDA list in your test set.

The bottom line

A restaurant catering inquiry AI is safe when it captures commitments exactly and refuses to make the ones only staff can make. Test each field against the audio, keep inquiry and booking states separate, and re-run the set before every change.