QR scan-to-order

Each table has its own QR code, printed from the tables screen. Scanning opens the menu in a browser — no app, no download.

The scan starts a table session, so several people at the same table can add to one running bill from their own phones, and the kitchen sees a coherent order rather than four separate ones.

Items, modifier groups, combos and availability all come from the menu you already maintain. Marking the biryani sold out on the POS removes it from every table’s phone immediately.

Orders placed from a table still flow through the normal kitchen routing and appear against the table on the floor plan. Staff can add to the same bill from the POS, apply discounts, and close the table out normally.

Codes are generated per table and printed from the tables screen as a sheet, so a floor of twenty tables is one print job rather than twenty.

Each code encodes its table, which is what lets an order arrive already attributed. A generic restaurant-wide QR cannot do that and pushes the work back onto staff.

A table session is bounded. When the bill is settled and the table is closed, the session ends and a later scan starts a fresh one, so the next party never sees the previous party’s order.

This sounds obvious and is the thing QR ordering most often gets wrong.

Scan-to-order does not remove the need for floor staff. It removes the queue for the first drink and the second round; someone still has to run food, read the room and handle anything that goes wrong.

Restaurants that deploy it as a staffing cut usually regret it. Restaurants that deploy it to shorten the wait at peak usually do not.