Food Court Self-Ordering Scenario

Food Court Self-Ordering: An Illustrative Scenario

Illustrative deployment scenario — a composite of the kind of project described, not a named customer engagement.

Illustrative scenario

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.

The situation

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 design

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 build

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.

The effect

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.

Reality check

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.

Talk to us Kiosks for QSRs

Frequently asked questions

No. It is an illustrative deployment scenario written to show how AtashiTech would approach the problem. There is no named customer behind it, and it deliberately carries no results, dates or measurements, because publishing invented ones would be worse than publishing none.

The kiosk takes a single payment for the whole basket, then splits the order by stall and sends each line to that stall's kitchen display. How the money then reaches each operator is a settlement design, scoped with the food-court operator, because the commercial arrangement between an operator and its stalls differs from site to site.

Ordering and cooking continue. Menu, images, prices and modifiers are cached on the kiosk and the kitchen displays sit on the same local network, so the order still reaches the kitchen. Cash keeps working, card and UPI are disabled honestly for the duration, and offline orders post to the cloud POS once each afterwards.

That is the point of a shared kiosk. The guest browses the whole food court as categories and pictures rather than as separate counters, builds one basket, pays once and holds one token, and the routing to different kitchens happens behind the glass.

They do when they read the same cloud menu, which is how we build them. A price change or a sold-out item reaches the kiosks and the boards together. When boards and kiosks are run as separate systems they drift apart, and that mismatch is a common source of guest complaints.

Per item, from the same menu data, so they are maintained in one place rather than reprinted on a board. Food regulation in India expects that information to be available to the guest, and a self-ordering screen is a better place for it than a wall.

Not the guest-facing units, but an employee self-service terminal behind the counters gives crew shifts, payslips, leave applications and attendance corrections after a login. It matters in an industry where most staff have no desk and no work email.

The commercial arrangement between operator and stalls, because it decides the settlement design; the menus in structured form with modifiers, images and allergen data; which POS and kitchen display systems the stalls run and whether they can be standardised; how aggregator orders should be prioritised; the hardware models; and a quiet period to pilot in.