Taking orders by voice: menus, modifiers and payments
Phone orders are a good job for a voice agent and an unforgiving one. The calls are frequent, cluster at the busiest times and follow a pattern, which is why a restaurant at seven on a Friday or a wholesaler first thing on Monday misses so many of them. But every order has to be exactly right: the wrong size, a missing modifier or a substitution nobody agreed to is a refund and a bad review. What makes an order-taking agent work is not how natural it sounds but how well it knows the menu, how carefully it confirms, and how it takes payment without ever hearing a card number.
What does the agent need to know about the menu?
Structure, not a PDF. The agent needs every item with its price, its options and their prices, which options are required and which are optional, what cannot be combined, and what is unavailable right now. A menu pasted in as text lets the agent improvise; a structured catalogue lets it check.
Modifiers are where orders go wrong. "Large, no onions, extra cheese, gluten-free base" is four decisions, each with rules: whether the base is available in large, whether extra cheese costs extra, whether gluten-free is a dietary option or an allergy claim you can support. Each rule needs to exist in data so the agent can apply it rather than guess.
Availability has to be live. An item that sold out an hour ago must disappear from what the agent offers, which means the agent reads from the same source as your POS or online store rather than from a copy updated weekly. Nothing damages trust faster than confirming an order you cannot fulfil.
How should it confirm the order?
By reading the whole order back before it is placed, item by item with modifiers and the total, and asking for an explicit yes. It takes twenty seconds and catches the mishearings that no amount of speech recognition quality eliminates entirely, especially with background noise from a kitchen or a street.
Confirm the high-risk details separately. Allergies deserve their own question and a plain statement of what you can and cannot guarantee. Delivery addresses deserve a read-back, ideally checked against an address lookup. Pickup times deserve a specific time, not "about twenty minutes".
And send a written confirmation by text or email with the order and the time. It gives the customer something to check, gives you a record if the order is disputed, and catches the rare error the read-back missed.
| Stage | What the agent does | What goes wrong without it |
|---|---|---|
| Menu lookup | Checks items, options and availability in live data | Orders for items that are sold out |
| Modifiers | Applies required options and combination rules | Missing or impossible modifiers |
| Allergy check | Asks separately, states what can be guaranteed | An unsafe meal and a liability |
| Read-back | Reads the full order and total, asks for a clear yes | Mishearings reach the kitchen |
| Payment | Sends a secure payment link or uses keypad entry | Card numbers in recordings and transcripts |
| Order placed | Writes to the POS or store, sends a confirmation | Orders that exist only in a transcript |
How should it take payment?
Never by asking the caller to read their card number to the AI. A spoken card number ends up in the audio, the transcript and every system those flow into, which drags your whole voice stack into the scope of card-data security rules under PCI DSS and creates a store of card numbers you do not want to hold.
The clean options keep card data out of the conversation. The most common is a secure payment link sent by text while the caller is on the line, which they complete on their phone with the payment provider. Another is keypad entry with the tones masked, handled by a payment service designed for phone payments so the digits never reach the agent or the recording.
Or take payment on collection or delivery, which many restaurants already do for phone orders. The agent's job is then to place a correct order, not to handle money at all, which is the lowest-risk design.
How does it connect to the POS or store?
Through the POS or e-commerce platform's own ordering API, so an order the agent places appears in the kitchen or warehouse exactly like an online order. Many modern POS and store platforms provide one; some older systems do not, and then the agent can only send the order to a person to key in, which works but loses much of the benefit.
Check this before anything else. The difference between an agent that places orders and one that transcribes them is almost entirely the integration, and it is the question that decides whether the project is worth doing.
Also decide what the agent does when the integration fails mid-call. It should say plainly that it cannot place the order right now and take the details for a callback, rather than confirming an order that never reached the system.
When should it hand the call to a person?
Large or unusual orders, catering and events, complaints about a previous order, and anyone who asks. These calls are worth more than a standard order and often involve judgement about pricing, timing or goodwill that the agent should not exercise.
At peak times the handoff may not be possible, because the staff the agent would transfer to are exactly the people who are busy. For those moments the agent should take the details, promise a callback with a time, and keep the promise.
Common questions
- Can an AI voice agent take restaurant phone orders?
- Yes, if the menu exists as structured data with prices, modifiers, combination rules and live availability, and the agent can write orders into your POS. It should read the full order and total back before placing it, ask about allergies separately, and send a written confirmation. Large orders, catering and complaints should go to a person.
- How should an AI phone agent take card payments?
- Without ever hearing the card number. Send a secure payment link by text during the call, use keypad entry with the tones masked by a phone-payment service, or take payment on collection or delivery. A card number spoken to the agent ends up in audio and transcripts and brings your voice systems into PCI DSS scope.
- How does an AI order-taking agent avoid mistakes?
- By checking against structured menu data rather than improvising, applying modifier rules from data, reading the whole order back with the total and asking for a clear yes, confirming allergies and addresses separately, and sending a written confirmation. The read-back catches the mishearings that better speech recognition alone does not eliminate.
- Does an AI order-taking agent work with my POS?
- It depends on whether your POS or store platform offers an ordering API. Many modern platforms do, and orders then arrive like online orders. If yours does not, the agent can only pass orders to a person to enter, which still helps at peak times but loses much of the benefit. Check this first.
- What happens if the AI cannot place the order?
- It should say so plainly, take the customer's details and promise a callback at a specific time, rather than confirming an order that never reached your system. The same applies when the order is unusual or large: capture the details and hand it to a person.
