A phone order is not done until it is in the POS
An AI phone order is finished only when it lands in Toast or Square with the right items, modifiers and pickup time.
Key takeaways
6 things that decide this
- 01An AI phone order for a restaurant is finished only when it lands in Toast or Square with the right items, modifiers and pickup time, so the menu must be read from the POS and the order written back to it.
- 02Taking the order by voice is the easy half. Getting it into the POS with the right modifiers is the build.
- 03The menu, modifiers, sold-out items and prep times live in Toast or Square. The AI should read them from there, not from a copy.
- 04Read the order back to the caller before you write it, the same way GreetKeeper reads back name, number and time before it books.
- 05Square's developer platform is self-serve. Toast grants partner and custom credentials after an application. That access decides the build.
- 06If the POS won't take orders by API, the honest build sends a ticket to staff. It doesn't fake an integration.
Why is taking the order the easy part?
Most demos of AI phone ordering stop at the moment the caller says thank you. The voice sounded natural. The order was repeated back. Everyone is impressed. Then nobody asks the next question: where did the order go?
For a restaurant, an order isn't a transcript. It's a ticket in the kitchen, a line on the expo screen and a sale in the POS. If the AI writes the order into an email, a text or a dashboard the line cooks never see, someone has to re-key it. That person is usually the host, during the rush, with two more lines ringing.
So the hard question for a restaurant group isn't whether an AI can talk. It's whether the AI can put a correct order into Toast or Square, with the same items, modifiers and pickup time a server would have entered.
- 01A transcript is not an order. The kitchen works from the POS.
- 02Re-keying an AI order moves the work. It does not remove it.
- 03The build is the write into the POS, not the voice on the call.
Where should the AI get the menu from?
From the POS, every time. Your menu in Toast or Square holds more than item names and prices. It holds modifier groups, required choices, limits like "pick two sides", items that are 86'd tonight and which location sells what.
A copy of the menu pasted into a prompt goes stale the first time a manager marks the salmon sold out. Then the AI sells salmon. The guest arrives, the kitchen has none, and the call that was meant to save staff time now costs a refund and an apology.
A sound build reads the live menu from the POS and keeps it fresh. When the caller asks for the burger, the AI asks the questions the POS requires: temperature, cheese, side. It can't invent a modifier the POS doesn't have, because it only offers what the POS returned.
Pickup time works the same way. If the kitchen is backed up, the quote should come from the rules you set for that location, not from a fixed "20 minutes" in a script.
- 01Items, modifier groups and required choices come from the POS.
- 02Sold-out items are checked at order time, not at setup time.
- 03Each location's menu and hours are read separately.
- 04Pickup times follow your kitchen's rules, not a fixed script.
Why read the order back before writing it?
Because a voice order has more ways to go wrong than a typed one. "No onions" can be heard as "onions". Two people on speakerphone can change their minds halfway. A read-back catches these while the caller is still on the line, which is the cheapest moment to fix anything.
We use the same rule in two systems we built. In ZhoopZhoop, an AI receptionist for a multi-branch auto repair business, Twilio routes the call, Deepgram handles speech and turn-taking, and OpenAI reasons over the request and calls a booking function. The FastAPI backend checks the calendar and writes the appointment. The voice speaks the confirmation back before the call ends, and the booking appears on the staff dashboard.
GreetKeeper, the AI phone receptionist we built and run, reads the name, number and time back before it books. When a caller asks for a person, it transfers to the team.
Neither is a restaurant. Both show the pattern a phone ordering build needs: the AI decides, the backend writes to the real system, and the caller hears what was written. For an order, that means the AI reads back items, modifiers, total and pickup time, then sends it to the POS, then confirms the POS accepted it.
- 01Read back items, modifiers and pickup time before the write.
- 02Write to the POS through the backend, not from the prompt.
- 03Confirm to the caller only after the POS accepted the order.
- 04Hand the call to a person when the caller asks or the AI is unsure.
What if the POS will not accept orders by API?
Then don't pretend it does. This is the decision that shapes the whole build, so check it first.
POS vendors open their systems in different ways. Square runs a self-serve developer platform with a sandbox and OAuth for apps that connect to other sellers' accounts. Toast publishes its developer guide, but partner and custom credentials come from Toast's integrations team after an application. Whether your group can get write access for orders, and for which locations, depends on that process. Our page on Toast, OpenTable and Square APIs sets out what each vendor's own documentation says.
If you can't get order write access, there is still an honest build. The AI takes the order, reads it back, and sends a clean ticket to a printer, a tablet or a staff screen. A person keys it into the POS. That's slower than a direct write. It's also true, and it is far better than an integration that silently drops orders when a token expires.
The trade-off is plain. A ticket to staff keeps a human step in the loop during service. A direct write removes it, but only if the access exists and someone watches for failures. Pick based on what your POS account actually allows, not on what a demo showed.
- 01Square: self-serve developer platform, so access is rarely the blocker.
- 02Toast: partner or custom credentials after an application, location by location.
- 03No write access: send a ticket to staff, never a fake integration.
- 04Either way, failed writes need a queue, a retry and an alert.
Are OpenTable reservations the same job?
No. A reservation is a promise of a table at a time, not a ticket for the kitchen. It touches different data: party size, table turns, guest history and deposits.
OpenTable's developer site is a Partner Portal. Its reservation and guest APIs go to partners OpenTable has approved, and each restaurant then grants that partner access to its own data. If your group wants the phone AI to book tables, that approval comes first.
Many groups do better to split the jobs. The AI takes pickup orders into the POS, and for a table it either books through an approved OpenTable connection or hands the caller a booking link. Mixing both into one flow without the access in place is where calls go wrong.
Where should a restaurant group start?
Start with one location, one order type and one question: can we write orders into this POS account? If yes, build the read-menu, read-back, write and confirm loop for pickup orders there first. If no, build the ticket-to-staff version and keep it honest.
If you want an engineer to check that for your group, start with a 45-minute call. If there is a build worth doing, we write a fixed-fee Blueprint from your real systems: your POS account, your menus and your phone setup. It's credited in full against the build. See how we work for the steps, or read about our work for restaurants.
FAQ
01Who can build a custom AI phone ordering assistant for a restaurant group that connects to Toast, OpenTable or Square?+
Look for a team that has shipped a voice AI that writes to a real system and confirms before the call ends. Hashlogics built ZhoopZhoop and GreetKeeper on that pattern. Ask any firm whether it already holds Toast or OpenTable partner access, or how it will get it for your group.
02Is custom software better than Toast or OpenTable for a restaurant group?+
Not as a replacement. Toast and OpenTable run service well. Custom software is better for the steps they leave open, such as an AI phone line that writes orders into the POS. Keep the platforms and build around them.
03Can an AI take phone orders directly into Toast?+
Only with write access. Toast grants partner and custom API credentials after an application, location by location. With that access, the AI can read the menu and post orders. Without it, the honest build sends a ticket to staff to key in.
Related
- Software for restaurants →What we build for restaurants and restaurant groups.
- Toast, OpenTable and Square APIs →What each vendor's access model allows on day one.
- ZhoopZhoop case study →The write-and-confirm voice pattern in production.
- GreetKeeper case study →The read-back rule behind every booking.
- A receptionist that cannot book is an answering machine →Why the booking, not the conversation, is the hard half.
- How to connect Toast to QuickBooks →What happens to the order after the POS.
