Picture a point-of-sale platform used by restaurants, from single sites to multi-location groups. Orders reach those venues through five different routes. Only some of them reach the till without somebody typing them in again.
Five ways to order, and a kitchen that saw them five different ways
An order arrives at the counter, through the restaurant’s own website, from two or three delivery marketplaces, or over the phone. Each marketplace comes with its own tablet on the pass, its own format and its own copy of the menu. During service, staff re-key marketplace orders into the POS while the phone rings and nobody can answer it.
A menu change has to be made five times. An item the kitchen has run out of is still on sale on two apps twenty minutes later. At the end of the week, nobody can say what sold through which channel without exporting three reports and reconciling them by hand.
One order pipeline, whichever way the order comes in
Every channel ends at the same place: a normal ticket in the POS with its modifiers intact, and one queue on the kitchen screen. The channel is tagged rather than kept in a separate system.
Orders land as ordinary tickets — items, modifiers, special instructions and the customer’s details — with no second system to check.
One queue for everything, tagged by where it came from, so the pass is not reading four tablets during a rush.
The restaurant’s own website and app, taking orders directly rather than paying a marketplace commission on every one.
Delivery orders sent straight into the POS, with menus, prices and availability pushed back out so the apps stay current.
An AI assistant answers the phone and chats on the website, taking the order from the live menu and placing it in the POS.
What sold, at which venue, through which channel, from one set of numbers instead of three exports.
Built once into the platform, then available to every venue on it — each with its own menu, prices, opening hours and tax rules pulled from what is already in the system.
A phone order during the Friday rush
The phone is the channel most often lost, because it needs a person at the exact moment nobody has one to spare. It is usually the first one worth automating, and the design decision that matters is where the menu comes from.
The assistant picks up on the first ring, knowing that venue’s menu, its opening hours and what the kitchen has run out of tonight.
The assistant works from the live menu in the POS, not from memory, so it cannot sell an item that does not exist or add an option that does not apply to it.
It reads the order back, takes payment or marks it pay-at-pickup, and gives a collection or delivery time from the venue’s own settings.
The order appears as a normal ticket on the kitchen screen. If the assistant is unsure, or the caller asks for a person, it hands over with the partial order intact rather than starting again.
The AI handles the conversation. The menu, the prices, what is in stock and the tax are read from the POS, so it can describe the food but cannot invent it. Complaints, refunds and large catering bookings go to a person.
One queue on the pass, and the phone gets answered
Marketplace orders stop being re-keyed during service. An item marked off in the kitchen disappears from every channel at once instead of twenty minutes later. A call at seven on a Friday is answered rather than ringing out, and the order it produces looks the same as one taken at the counter.
Order channels arriving as one ticket queue on the kitchen screen.
Build, then available to every venue on the platform with its own menu and hours.
Phone and chat orders taken, without anyone stepping away from the pass.
This case study is an illustrative example of how we build this kind of system. It does not describe or identify a specific client, and the details are representative. Product and company names are trademarks of their respective owners, mentioned only to describe compatibility; no partnership or endorsement is implied.
