What restaurant callers actually want before anyone takes an order

The five things a restaurant phone line is asked for are: place a new order, chase an order already placed, book a table or ask about a large party, ask a general question about hours, allergens, parking or directions, and complain about food that has already arrived. Only the first is an order. The other four end somewhere else entirely.

That is why intent has to be settled before any ordering machinery starts. An agent that opens by taking an order and only discovers on turn 4 that the caller wanted a refund has already burned the caller's patience and produced a half-built order somebody now has to discard.

Five intents, five systems of record

Two of the five need something ordering agents are routinely not given: a read path into live state. Chasing an order needs current fulfilment status keyed on the caller's number, and a complaint needs order history. Without those, both intents can only be transferred, which is why they dominate the handoff queue on lines that were sized for orders.

One question settles it

The opener does most of the routing work, and 'how can I help you today?' is the worst version of it. It invites a sentence the classifier has to guess at, often delivered over kitchen noise. A closed-set opener that names the branches resolves intent in a single turn and gives the caller a vocabulary to answer in.

• Name 3 branches, not 5. 'Is this a new order, an order you've already placed, or a table?' covers the common cases; the other 2 fall through to a person.
• Put the highest-volume branch first. Callers latch onto the first option they recognise, so branch order is a design decision.
• Accept the answer in any form. 'Already placed', 'I ordered an hour ago' and a phone number spoken alone all mean the same branch.
• Never re-ask a branch already given. Re-asking is the most reliable way to lose a caller who is already annoyed.
• Allow a mid-flow switch. 'Actually, before that' is a change of intent, and the order state must survive the detour.

Measure your own mix before you automate anything

1. Log 2 weeks of calls with a timestamp and a duration. A fortnight covers a weekend peak and a slow midweek, which have different mixes.
2. Tag each call from its first 15 seconds only. Intent is stated in the opening sentence; tagging the whole call biases towards whatever it became.
3. Split by hour, not by day. Friday 19:00 is orders and chases. Tuesday 11:00 is bookings and information.
4. Count abandoned calls separately. A line that rings out during service hides a mix, and those are the intents you are losing.
5. Only then choose. Automate the largest intent your systems can serve end to end, not the one that sounds most impressive.

Why one ordering script mis-serves four of them

An ordering flow is built to accumulate state: items, modifiers, quantities. Four of the five intents have no order to accumulate, so every turn in that flow builds something that gets discarded — and inherits the flow's failure modes for no benefit. The catalog and state problems behind three modifiers in one breath and only two reaching the ticket should never touch a caller who wanted to know about parking.

One exception is worth naming: intent 4 sometimes turns into intent 1. A caller asking whether the pad thai contains peanuts may then order it, and the answer they were given has to become a typed field on the ticket rather than a remembered conversation. That transition is where an allergy is spoken aloud and the ticket carries no trace begins.

Four out of five callers do not want to place an order. A phone line built only to take orders is wrong most of the time it is right.

Where the boundaries sit

Two intents have depth this page does not cover. Chasing an order is a fulfilment-visibility problem before it is a phone problem: a large share of the calls are just: where is my order?. Bookings have their own mechanics, including what secures a table — three ways to secure a booking. Complaints end at a person, and the quality of that ending is the handoff that fires correctly while the call still dies.

The routing table is an operations artefact, not a prompt: an owner, a destination and a fallback per intent, changing when the restaurant changes. Keeping it somewhere staff can edit is internal tools and ops work. The rest sits in voice and phone ordering, within software for restaurants and food service.

• voice ordering
• call routing
• intent classification
• phone orders