Read-back: the moment a spoken order becomes a kitchen ticket
In short
Read-back is the commit boundary of a phone order: the last moment a wrong item costs nothing. Anything the kitchen, the packer or the till will act on differently — every item and quantity, every priced modifier, every substitution, the allergy note verbatim, the fulfilment channel — is spoken aloud before a single line is written to the POS.
Key takeaways
- Nothing reaches the POS until the guest confirms the read-back. The confirmation is the write, not a courtesy before it.
- Speak anything the kitchen will act on differently: items, quantities, priced modifiers, substitutions, allergy notes verbatim.
- Compress what carries no decision — menu sections, unpriced defaults, the standard build nobody changed.
- State the line count as a number first. It is the only cheap check against a line dropped silently.
- A confirmation text lands after the commit, so it prevents nothing. It can only start a refund.
Read-back is where a spoken order stops being a conversation and becomes a record. Until the guest agrees to it, nothing exists in the POS, on the KDS or in the printer queue. After they agree, every correction costs somebody something: a remake, a refund, or a guest who stops calling. That makes read-back a transaction boundary, not politeness.
So it is a rule about order of operations. An agent that writes lines to the POS as it hears them and then reads a summary has already committed; the summary is theatre. An agent that holds the order in memory, speaks it, waits, and only then writes has a free correction window.
A commit boundary, not a courtesy
A person taking orders gets away with a loose read-back because they are also the correction path: they hear the tone shift, they walk to the pass. An agent has 2 correction paths and no others — read-back and handoff. It also has to settle intent first, because a caller changing an order placed 20 minutes ago should never reach an ordering read-back at all. That is the five things a restaurant phone line is asked for.
What must be spoken, and what may be compressed
The test is behavioural, not linguistic: speak anything the kitchen, the packer or the till will act on differently. Compress the rest, because a read-back long enough to be talked over is one nobody hears to the end.
| Element | Treatment | Why it sits there |
|---|---|---|
| Line count | A number, before the list | The only cheap check against a silently dropped line |
| Item and quantity | Every line, quantity first | A missing line is the costliest error and the hardest to notice |
| Priced modifiers | Each one, attached to its line | They move the total, so a wrong one is an argument at collection |
| Substitutions and removals | In the guest's own words | 'No onions' is a build change, not a preference |
| Allergy notes | Verbatim, never paraphrased | Paraphrase turns 'severe nut allergy' into 'no nuts', which reads as taste |
| Channel and time | Collection or delivery, plus the quote | It routes the ticket; wrong here wastes a whole made order |
| Order total | Once, at the end | 1 number after the items, so a mismatch points at a line just heard |
| Defaults and menu sections | Compressed or dropped | 'A large pepperoni' needs no section name |
Two cases sit outside the table. A request the catalog cannot price should never reach a read-back dressed as an ordinary line — that is what counts as off-menu for an ordering agent. And an allergy note the schema cannot store is read back perfectly and still vanishes before the kitchen: a schema failure, not a speech failure.
The sequence, in order
- Close the order. Get an explicit no to 'anything else?' — a read-back interrupted by a new item restarts, and restarts are where callers give up.
- State the count. '4 items' before the list, so the guest counts along rather than listening passively.
- Read line by line, quantity first. Modifiers belong to their line, never to a trailing list: the guest cannot tell which burger the extra cheese landed on.
- Repeat allergy notes verbatim, then pause. The 1 place a deliberate silence pays: room to correct a paraphrase while the ticket does not exist.
- State channel, time and total. Collection or delivery, the quoted time, then the total as a single number.
- Ask an open question, then write. 'What have I got wrong?' beats 'is that right?', because yes is the cheapest thing a tired caller can say.
A confirmation text is not a read-back
A post-order SMS is a useful artefact and a poor control. It lands after the commit, so it cannot prevent a wrong ticket — only start a refund conversation about one. By then the chit is at the pass. The 2 do different jobs: the read-back is a gate, the message is a receipt.
A read-back is the last moment a wrong item is free. Everything after it is a remake, a refund, or a guest who quietly stops calling.
What the confirmation does and does not guarantee
Confirmation commits the order. It does not deliver it. The write can be accepted by the POS and still produce no chit at the pass, which is a routing and printing failure with its own diagnosis. Treat confirmation as the start of a chain you observe, not the end of the call.
Read-back also has a boundary with escalation. If the agent is unsure enough that the read-back would be a guess, it should have stopped 2 turns earlier — those thresholds live in setting the point at which the agent must stop and ask. A guest saying yes to a wrong summary has not made it right.
It is the cheapest reliability control on a phone-ordering build and the one most often shipped as an afterthought. The surrounding problems sit in voice and phone ordering and across software for restaurants and food service. Building the agent is AI agents and automation work, under the constraints in AI agents in production.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
Should the agent read back the price of every item?
No — read back every priced modifier, but only 1 total. Item-by-item pricing roughly doubles the read-back and callers stop listening, while a single total gives one number to check and any mismatch points at a line just heard. Where an item varies by size or daypart, speak the size rather than the amount.
What should happen when the guest corrects one line during the read-back?
Apply the correction, then re-read only the affected line and the total. A full restart on every correction pushes call length past the point where callers abandon, and confirmed lines have not changed. Restart from the top only when the correction moves the line count or the fulfilment channel, because both invalidate what the guest was counting along with.
Is a read-back needed if the order came through chat rather than voice?
No, because the guest can see the order — but the commit boundary still applies. The chat equivalent is an explicit confirm action on a rendered summary, with the write happening on that tap rather than as items are added. Nothing reaches the POS until the guest agrees to a complete view of the order.
Can the read-back be skipped for a regular reordering their usual?
No. Recognition makes it shorter, not optional: a saved order reads back as 1 line plus whatever changed today. The failure a read-back catches is mishearing, not novelty — and a saved favourite carries the extra risk of an item since 86'd or repriced.
- voice ordering
- order accuracy
- POS integration
- phone orders
The work behind this page
Builds from our portfolio that this page draws on.
Read next
- Off-menu: the requests an agent must never improvise onOff-menu is not a property of the request. It is a property of your catalog on the day the call arrives — and only one of the three requests that sound off-menu actually is.definition
- What restaurant callers actually want before anyone takes an orderA restaurant phone line receives five different intents, and only one of them is an order. Each ends in a different system, so a single ordering script mis-serves four out of five callers.definition
- Three modifiers in one breath and only two reach the ticketThe recording contains three customisations and the printed chit carries two. Which one goes missing tells you which layer dropped it — and transcription is the least likely answer.diagnostic
Related across the site
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation