From QR Scan to Kitchen: How the Order Actually Travels
Scan, order, KOT, cook, bill, paid — five steps that look instant from the table but involve several systems talking to each other in the background. Here's exactly what happens in between.
A guest scans a QR code, taps a few things, and twelve minutes later there's food on the table. From where they're sitting, that's the whole story. Behind it, though, that single scan sets off a small relay race between four or five separate parts of a system — a menu server, an order queue, a kitchen printer or display, a table management layer, and finally a billing engine — and if any one of those handoffs is clumsy, the guest notices, even if they can't say exactly why.
This isn't the article that tells you whether to adopt QR ordering — we've already made that case in does QR ordering actually work for restaurants. This one opens the hood. If you've ever wondered what really happens between a scan and a ticket landing in the kitchen, or why some systems feel instant while others lag by ten seconds, this is that explanation.
How the Menu Gets to the Guest's Phone
Every table (or every till, for counter service) carries a QR code that isn't a picture of a menu — it's a link to a live page. Scan it and the phone's browser opens a page fetched fresh from the café's server, not a PDF or an image someone uploaded three months ago. That matters more than it sounds: the moment a dish sells out or a price changes, the person doing the updating changes it once, in one place, and every table's code reflects it on the next scan. There's no reprinting, and no laminated menu with a price crossed out in pen.
Under the hood, that code usually encodes two pieces of information — which café, and which table. Table 7's code and table 12's code point to the same digital menu but tag the order differently once it's placed, which is what lets forty tables share one menu system without forty separate setups. The same structure works for counter-only cafés with no table numbers at all — the table tag is simply left out.
Placing the Order: What Actually Happens on Tap
The guest picks items, adjusts quantity, maybe adds a note ("less spicy", "no onion"), and hits place order. From that tap, three things need to happen almost at once: the order has to be written down permanently, the kitchen needs to know about it, and the table's status needs to update so staff walking past can see it's now occupied-with-an-order instead of still browsing.
- The order is saved with a timestamp, table number, item list and notes — this becomes the record the bill is built from later.
- A kitchen ticket is generated automatically, without a waiter re-typing anything by hand.
- The table itself flips state on the live floor view, so a manager glancing at a tablet can see which of fifteen tables have an active, unbilled order.
This is also the point where QR ordering either saves a café real labour or doesn't. In a fully manual setup, a waiter still walks to the table, notes the order, walks to the kitchen, hands it over, and walks back — the QR code is decoration. In a properly wired system, the guest's tap does the writing-down and the handing-over in the same second, and the waiter's actual job shifts to running food and checking on tables instead of taking dictation.
The KOT: From Order to Kitchen Ticket
The kitchen order ticket, or KOT, is the internal document that tells the kitchen what to cook — separate from the bill, which the guest never sees until they ask for it. A KOT for one table might read: 1x Paneer Tikka, 2x Cold Coffee, 1x Veg Biryani (no onion), Table 9, 7:42 PM. No price on it anywhere. The kitchen doesn't need to know what a dish costs; it needs to know what to make and how fast.
Where this gets interesting is timing. If a table orders in two rounds — starters first, mains fifteen minutes later — a well-built system treats that as two KOTs against one running order, not one edited ticket that gets confusing to read. That way the kitchen sees "new items" clearly instead of hunting through a ticket it's already halfway through cooking from.
Inside the Kitchen: Screen or Paper
From here the ticket goes one of two ways — a thermal printer produces a paper slip, or it lands on a kitchen display screen mounted above the pass. Both get the same information to the same place; the difference is what happens after it arrives.
| Printed KOT | Kitchen Display (KDS) | |
|---|---|---|
| New order arrives | Printer prints a slip; cook pulls it off the spike | Ticket appears on screen instantly, usually with a sound |
| Marking progress | Cook crosses it out by hand, or leaves it as-is | Cook taps to mark in-progress / ready — visible to the counter |
| Multiple stations (grill, tandoor, beverage) | Needs a second printer per station, or one slip passed around | Same ticket can route to each station's own screen |
| Paper and ink cost | Ongoing — rolls, ribbons, a spike full of old slips | None — nothing to print |
| Finding a lost ticket | Gone once torn off, unless someone kept it | Still in the system, searchable by table or time |
Neither is objectively wrong — plenty of small, fast kitchens run perfectly well off a spike of paper tickets, and a thermal printer stays useful even alongside a display, as a backup and for handing a physical slip to a delivery rider. We've gone deeper on choosing between them in kitchen display system vs KOT printer.
Mid-Order Reality: Holds, Add-ons and Cancellations
Orders rarely stay clean once they hit the kitchen. A table wants to hold their order because they're waiting for one more person. A guest wants a plate of fries added after mains are already cooking. A dish gets cancelled because the kitchen ran out of an ingredient. A system built for a real café floor needs to handle all three without the KOT and the eventual bill drifting out of sync with each other.
- Held orders sit in a queue without going to the kitchen until someone releases them — useful for a table that's still deciding, or an order taken before everyone has arrived.
- Adding items later creates a second KOT for just the new items, so the kitchen isn't handed a full reprinted ticket it's already half-cooked.
- Cancelling an item after it's fired needs a reason attached — out of stock, guest changed their mind, kitchen error — because that reason is what shows up in reports later. It's the difference between "we're losing money on wastage" and "we're losing money and nobody knows why."
This is one of the places a notebook-and-memory setup quietly breaks down. Cancelling an item by hand isn't hard — it's that three weeks later, nobody remembers why twenty dishes across the month got voided.
Closing the Loop: Bill, Payment and Receipt
Once a table is done ordering, the running order becomes a bill — same underlying data, different document. This is where discounts get applied, GST is calculated by rate, and the format shifts from "what to cook" to "what was consumed and what it costs." A compliant GST invoice needs the café's GSTIN, a proper CGST/SGST breakdown, and a sequential invoice number — not a hand-totalled slip written on the back of an order pad.
Payment itself can go a few ways depending on how the café is set up — settled at the counter, a guest paying their own UPI directly, or a card machine brought to the table. Whichever path it takes, once the bill is marked paid, the table flips back to free on the floor view, and a digital receipt can reach the guest instead of a paper slip that ends up in the bin. The guest's own order history — what they had last visit, visible on their own phone — comes from this same billing record, not a separate system someone has to sync by hand.
What Happens When the Wi-Fi Drops
All of this depends on data moving between a phone, a server, a kitchen screen and a billing counter — which raises the obvious question: what happens on the Saturday evening the internet actually goes down? A cloud system genuinely needs a connection to accept a new order or send a fresh KOT; there's no getting around that, and it's worth knowing going in rather than discovering it mid-rush.
The Full Flow, Start to Finish
- Guest scans the table's QR code and the live digital menu loads.
- Guest builds an order and taps place order.
- The order is saved with table, items, timestamp and notes.
- A KOT is generated and sent to a printer or a kitchen display.
- The table's status updates to "ordered" on the floor view.
- Kitchen marks items in progress, then ready; a waiter runs the food.
- Guest adds items, holds, or cancels as needed — each change leaves its own trail.
- Table requests the bill; the order becomes a GST invoice with tax and any discounts applied.
- Payment is taken — counter, UPI, or card — and the bill is marked paid.
- Table clears on the floor view and a digital receipt reaches the guest.
None of these ten steps is complicated on its own. What's genuinely hard is making all ten happen without a human re-typing information that already exists somewhere in the system — that's really the whole pitch behind a connected ordering-to-billing setup instead of a QR code bolted onto an otherwise manual café. If you'd rather see the flow live than read about it, you can sign up free and place a test order through the full pipeline in a few minutes.