Illustrative deployment scenario — a composite of the kind of project described, not a named customer engagement.
Illustrative deployment scenario
A worked example of shared self-ordering kiosks in a multi-stall food court, written to show the method rather than to report a project.
This is an illustrative deployment scenario. It is not a case study, describes no named customer, and contains no results, dates or measurements. The food court is composite: the situation, the order flow and the integration list come from how shared-kitchen formats generally work and from the food ordering and self-service restaurant solution in our catalogue. The QSR and food courts page covers the wider picture.
Twelve stalls, one lunch hour, twelve queues
A food court's problem is not throughput at any single counter. It is that the guest has to choose a queue before they choose a meal.
Each stall takes its own orders, its own payments and its own tokens. A guest who wants a main dish from one stall and a drink from another queues twice and pays twice. Counter staff spend the peak taking orders instead of serving food, order errors come from a spoken order retyped under pressure, and a guest standing at a stall cannot see that the one behind them is empty.
The operator has a second problem the stalls do not see. Sales, price changes and sold-out items live in twelve places, so the concourse menu boards drift out of step with what the kitchens can actually cook, and the settlement conversation at the end of the month is reconstructed rather than reported.
The journey we would design
One kiosk, one basket, one payment, and the routing problem handled behind the glass.
Browse every stall in one place
The guest sees the whole food court as categories and pictures rather than as twelve counters, with a sold-out item removed the moment the stall marks it so. Navigation is image-led so it works without reading, and the language switch is on the first screen.
Build a mixed basket with modifiers
Items from different stalls sit in one basket. Modifiers, combos and portion choices are presented as the menu structure allows, and allergen and nutritional information is available per item rather than pinned to a board somewhere.
Pay once for the whole order
Card, UPI QR or cash where the format allows, with coupons and loyalty applied before the total. The guest pays once even though the order will be cooked in several kitchens.
Split the order behind the glass
The software splits the basket by stall and sends each line to that stall's kitchen display, so each kitchen sees only its own work while the guest holds one token. The split, and the settlement rules that follow it, are scoped with the operator because every food court's commercial arrangement differs.
Call the guest back when it is ready
Order-ready boards and a message to the phone are driven by the same order events the kitchens complete, so a guest can sit down and nothing is called twice.
Keep selling when the broadband fails
Menu, images, prices and modifiers are cached on the kiosk and the kitchen displays sit on the same local network, so ordering and cooking continue. Card and UPI are disabled honestly for the duration, and offline orders post to the cloud once each afterwards.
The software and integrations involved
The ordering engine is packaged; the routing rules and the menu data are where the engagement goes.
- The food ordering and self-service restaurant kiosk for the menu, modifiers, upsell, payment and kitchen display integration.
- Per-stall routing and settlement rules scoped on top of it, because a shared food court is not the same as a single-brand outlet.
- The queue and token solution for order-ready boards and the message that calls a guest back.
- Menu boards above each counter built under the Android TV and signage service, reading the same cloud menu the kiosks sell from.
- POS, gateway and loyalty links through the integration service, with peripherals by category on the integrations page.
- An employee self-service kiosk behind the counters for crew who have no work email, and fleet monitoring from the kiosk management platform.
What changes for guests, stalls and the operator
Described qualitatively, because a real deployment's numbers belong to the operator that runs it.
For the guest, choosing a meal stops being a bet on which queue moves fastest. A mixed order is one transaction, the token covers all of it, and the wait happens at a table rather than at a counter.
For the stall, the counter goes back to serving food. Orders arrive on the kitchen display as they were entered rather than as they were heard, which removes the class of errors that comes from repeating an order across a noisy counter at the peak.
For the operator, the menu becomes one thing rather than twelve. A price change or a sold-out item reaches the kiosks and the boards together, and the settlement conversation is a report from the same system that took the money rather than a reconstruction at month end.
What a real deployment would need from you
This scenario is a sketch. Turning it into a project needs facts only the operator has.
- The commercial arrangement between the operator and the stalls, because it decides the settlement design.
- The menus, in structured form: categories, modifiers, combos, images and allergen data.
- Which POS and kitchen display systems the stalls run, and whether they can be standardised.
- Whether delivery-aggregator orders share the same kitchen displays, and how they should be prioritised.
- The kiosk, printer and payment terminal models, agreed with your hardware vendor.
- A quiet period to pilot in, before the kiosks face a full lunch rush.
Would this work in your food court?
Describe your stalls, your POS and your kitchen setup, and we will scope a self-ordering deployment around them rather than quote from a rate card.
Frequently asked questions
Tell us the journey, the sites and the hardware you already have — every engagement is scoped and quoted individually.