The easy calls are easy. A caller wants your hours, a pickup time, a large pepperoni. Any competent agent handles those, and that's not the question operators actually ask.
The question is what happens on the messy ones. The guest whose order arrived wrong last night. The caller who wants a dish you don't make. The office manager who needs food for forty on Thursday and has a budget question. Those calls are a small share of volume and a large share of the risk, and how a system handles them is most of what separates a phone agent you can leave running from one you can't.
It solves what it can, start to finish
Order status, a substitution, hours, directions, a wait-time quote, a repeat of last week's order: these run end to end with no human involved. So do the calls nobody counts as calls, the vendor checking on a delivery, the wrong number, the person who dialed you looking for the barber next door.
That last group matters more than it seems. On a slow Tuesday afternoon, a meaningful share of your ring volume isn't revenue at all, and each one still pulls a host away from a table. An agent that quietly disposes of them is doing real work even on a day when it takes almost no orders.
Modifications inside your menu also belong here. "No onions, sauce on the side, cut in squares" is not an edge case, it's ordinary, and an agent that can't map it to real modifiers has a comprehension problem rather than an edge-case problem, and it's worth separating the two before you start blaming edge cases for ordinary misses.
It hands off the rest, with context
A complaint, an off-menu request, an upset caller: the agent recognizes the intent and routes to a person. Depending on your rules, that's a transfer to a live line or a voicemail captured with a transcript and the caller's details, so your team picks up an informed call instead of a cold one.
The word doing the work in that sentence is "context." A transfer that arrives as a ringing line with no information is barely better than the caller dialing again. A transfer that arrives with the caller's number, what they said, and what they were trying to do lets a manager open with "I'm sorry about the order last night" rather than "how can I help you." That difference is the whole argument for handoff over deflection, and human handoff and failover covers how to configure it.
What this looks like on a Friday at 7:15
Three calls land in the same two minutes.
The first is a regular ordering the usual. The agent takes it, confirms the modifiers, and it prints. Nobody at the restaurant knows the call happened.
The second is a guest whose delivery arrived missing a side. The agent recognizes a complaint, doesn't try to negotiate a remake, and transfers to the manager line with the order number and a transcript already attached. The manager spends ninety seconds on it instead of five minutes reconstructing what happened. If the manager line doesn't pick up within your set number of rings, it drops to voicemail with the same context rather than dying in a loop. Handling refund and complaint calls works through the policy side of that.
The third is a caller asking whether the fried rice has egg in it. This is the one worth watching. A well-configured agent gives the answer you loaded, or says it can't confirm and offers a person. An agent that guesses at an allergen answer is a liability, not a convenience, which is why allergen and dietary questions deserve an explicit configuration decision rather than a default.
Catering and large orders
A catering inquiry is the most expensive call you can mishandle, because the ticket is large and the caller is usually shopping two or three restaurants that afternoon.
The agent should capture the inquiry, the date, the headcount, the contact, and route it immediately to whoever owns catering, so a high-value lead doesn't sit in a mailbox overnight. Whether it should attempt to quote depends on your business. A fixed per-head package can be quoted. Anything requiring judgment about staffing or delivery should not be. Catering lead qualification covers where to draw that line.
Response time is the metric here, not containment. A catering call that reaches a human within the hour is a working system, even though the agent escalated every single one of them.
The failure modes worth testing for
Three things go wrong, and none of them announce themselves.
The agent refuses to let go. A caller asks for a person, and the agent asks another clarifying question instead. This is the most damaging failure because it makes your metrics look better while the caller experience gets worse, a trap explained in what call containment hides.
The agent is confidently wrong. It accepts an off-menu request into a notes field, or answers a question about an ingredient it was never told about. The error surfaces later, at the pass or at the door, and it costs more than the original call was worth.
The handoff lands nowhere. The transfer rings a line nobody staffs during the rush, or the voicemail box fills, or the escalation goes to a manager who's off that day. This is a routing problem rather than an AI problem, and it's the one most likely to be discovered by a guest instead of by you.
Test all three during a demo. Call in and ask for a human immediately. Order something you don't sell. Then check where a transfer actually lands at 7 p.m. on a Friday, not at 2 p.m. on a Tuesday when the office is quiet.
You set the rules, per location
Which calls transfer, which go to voicemail, which get a text follow-up, and which are simply closed out: that's your configuration, and it should differ by location and by daypart. A store with a manager on the floor until close can take live transfers all evening. A store where the last manager leaves at nine should route after that to voicemail with a transcript rather than to a phone nobody is holding.
Write those rules down before you launch. Most of the disappointment operators report with voice agents traces to routing decisions that were never made explicitly, so the defaults made them instead. A complaint escalation matrix is a reasonable format for writing yours.
The monthly hour that keeps it honest
Once a month, pull the calls that escalated and read twenty transcripts. Sort each one into "by design" or "by failure."
Complaints, catering, caller-requested transfers, vendors: by design, no action. An item the agent couldn't parse, a question it had no answer for, availability it didn't know: by failure, and each one has a small specific fix, usually a menu alias or an added answer.
If the failure bucket is shrinking month over month, the system is being maintained. If it's the same three items every month, nobody is doing the maintenance, and that's a conversation to have with your vendor before it's a conversation to have with a guest.