QR Ordering for Guests in Meztezz

Some of the best-run restaurants we’ve seen have one thing in common: the guest never has to wave at a waiter to place a second round. A printed QR sticker on the table, a quick scan, and the order lands in the kitchen before the conversation breaks. No app download, no login wall — just the menu on the guest’s own phone.

This guide walks through everything Meztezz ships today for QR-based guest ordering — turning it on, printing the codes, what the guest actually sees on their phone, the approval workflow your staff manages, and the honest list of what it doesn’t do yet. It assumes you’ve already gone through Setting Up Masters (categories, items, stations) and Tables & Reservations. If you haven’t, start with those — the QR menu pulls directly from your existing item and category setup.

The Walkthrough at a Glance

Part	What you’ll learn
1. What QR Ordering Is (and Isn’t)	The big picture — what it replaces, what it doesn’t.
2. Turning It On	The six settings that control the feature, and what each one means for your operation.
3. Generating & Printing QR Codes	How to create codes for every table and get them onto stickers or tent cards.
4. What the Guest Sees	The full phone experience — from scan to confirmation.
5. What Your Staff Sees	The approval sheet on the POS terminal and the Captain App.
6. How QR Orders Reach the Kitchen	KOT creation, station routing, and parity with POS orders.
7. Honest List of What Meztezz Doesn’t Do (Yet)	Limits we’d rather you know in advance.
8. A Few Habits That Save You Later	Small disciplines that keep QR ordering smooth on a busy night.

Part 1 — What QR Ordering Is (and Isn’t)

QR ordering in Meztezz lets a guest scan a code at their table, browse your menu on their phone, and send an order to your kitchen — all without downloading an app. The guest’s phone connects to the POS terminal over your restaurant’s local Wi-Fi network, and everything that follows — menu display, cart, order placement — happens through a lightweight web page served by the terminal itself.

What it replaces: the “wait for the waiter to come take a second round” bottleneck, and the captain walking back and forth to the POS to punch in items. During a rush, this alone can shave minutes off each table’s cycle time.

What it does not replace: payment. The guest browses and orders on their phone, but the bill is still settled at the POS terminal the way it always is — cash, card, UPI, split, credit. There is no payment screen on the guest’s phone. The QR flow covers ordering only.

💡 No internet required for the guest. The QR page is served from the POS terminal on your LAN. As long as the guest’s phone is on the same Wi-Fi network as the terminal, the menu loads — even if the internet is down. This is the same offline-first design that powers the rest of Meztezz.

Part 2 — Turning It On — `Settings → QR Ordering`

QR ordering is off by default. To enable it, open Settings → QR Ordering on the POS terminal. You’ll see five controls:

Setting	Default	What it does
Enable QR Ordering	Off	Master switch. Nothing else on this screen matters until this is on.
Require Captain Approval	On	When on, every QR order goes into a “Pending Approval” queue — a staff member must approve it before it fires a KOT. When off, orders go straight to the kitchen.
Allow Multiple Rounds	On	When on, the guest can place additional orders on the same table after the first one. When off, one order per session — they’d need to call a waiter for round two.
Show Alcohol Items	Off	When off, alcohol categories are hidden from the QR menu entirely — useful where regulations or house policy require staff-mediated liquor orders.
Session Timeout	120 min	How long a guest’s session stays active after scanning. Configurable from 15 to 480 minutes. After timeout, they’d need to scan again.

Saving changes requires a manager PIN — these settings affect the guest experience directly, so they’re gated.

The settings screen also displays your terminal’s LAN IP address and port (e.g. 192.168.1.42:3001). This is the base URL the QR codes will point to. If your network assigns a new IP after a router restart, the QR codes will break until the IP matches again — a good reason to assign a static IP to your POS terminal in your router settings.

Part 3 — Generating & Printing QR Codes — `Settings → QR Ordering`

Once QR ordering is enabled, the same settings screen shows a Generate QR Codes button. Tapping it creates a QR code for every active table in your restaurant.

Each QR code encodes a URL like:

http://192.168.1.42:3001/qr/?table=5

The table parameter tells the system which table the guest is sitting at, so their order gets attached to the right bill automatically.

What you get:

A preview grid showing each table’s QR code with the table number and its section printed below it.
An Export All PDF button that exports every code in a print-ready layout — one code per card, labelled with the table number — plus a per-table PDF button on each tile if you only need to reprint one.

Getting them onto the tables: Print the PDF, cut the cards, and laminate them or slip them into acrylic tent-card holders. Some restaurants print them directly onto the table surface or stick them under a clear tabletop protector. Whatever you choose, make sure the code is scannable under your restaurant’s lighting — test with a phone camera from a comfortable arm’s-length distance before committing to bulk print.

Part 4 — What the Guest Sees

This section describes the full experience from the guest’s phone. There are no app downloads, no account creation, and no personal data collected — the guest never even enters a phone number.

4.1 Scanning & Starting a Session

The guest opens their phone camera (or any QR scanner) and points it at the table code. The phone opens a browser page on the terminal’s local address and lands directly on the menu — a session token is created silently in the background.

The session token is stored in the phone’s browser, so if the guest closes the tab and re-scans, they pick up where they left off (as long as the session hasn’t timed out).

The menu screen is a clean, mobile-first layout:

Category tabs across the top — these are the same categories you set up in Masters, including sub-categories: tapping a parent category drills into its children (up to three levels deep), with a back chip and an “All …” tab to see the whole group at once. If “Show Alcohol Items” is off, alcohol categories are hidden entirely.
Item cards in a scrollable list below — each showing the item name, price, and a vegetarian/non-vegetarian indicator.
Tapping an item opens the item detail view.

If you do show alcohol on the QR menu, the bar’s stock guards follow it there: a liquor item the bar can’t actually pour right now — out of stock, expired, or missing its drink recipe — shows as a greyed-out Unavailable card the guest can’t add. The same hard rules that protect the bar at the POS apply on the guest’s phone.

4.3 Item Details — Variants, Add-Ons & Special Instructions

The item detail screen is where the guest customises their order:

Variants (if the item has them) — size or type options, each with its own price. For example, a pizza might show Regular — ₹249, Medium — ₹399, Large — ₹549. The guest picks one.
Add-ons — grouped by category (e.g. “Extra Toppings”, “Sides”). Each add-on has its own price and can be toggled on or off independently.
Special instructions — a text field for free-form notes (“no onions”, “extra spicy”), plus preset chips for common requests that your staff have configured. The guest can tap a chip or type their own note.
Quantity controls — plus/minus buttons.

The running total updates live as the guest makes selections. When they’re happy, they tap Add to Cart.

4.4 The Cart

The cart screen shows everything the guest has added:

Each line item with its variant, add-ons, quantity, and line total.
Plus/minus buttons to adjust quantities, and a remove button for each item.
A Place Order button at the bottom with the grand total.

The cart persists across page refreshes — if the guest accidentally closes and reopens the tab, their selections are still there.

There is a limit of 30 items per submission. For most real-world orders this is more than enough; it’s a safeguard against accidental floods, not a practical limit.

4.5 Placing the Order

When the guest taps Place Order, what happens next depends on your approval setting:

If “Require Captain Approval” is on: The guest sees an hourglass icon and a message: “Order sent to staff!” The order enters the pending queue on the POS terminal, waiting for a staff member to approve it. The guest’s phone polls for status updates automatically.
If “Require Captain Approval” is off: The order fires directly to the kitchen — KOTs are created immediately. The guest sees a checkmark and “Order placed!”

In both cases, the guest gets an order number on the confirmation screen.

4.6 Tracking Order Status

After placing the order, the guest’s phone keeps checking for updates:

Pending approval — waiting for staff (if approval is required).
In the kitchen — KOTs have been created and sent to stations.
Ready — the kitchen has marked items as ready.

The polling is automatic and backs off over time (every 5 seconds at first, then 15, then 30) so it doesn’t hammer the terminal.

4.7 Editing a Pending Order

If the order is still in the “Pending Approval” state — meaning a staff member hasn’t approved it yet — the guest can still make changes:

Adjust quantities of individual items.
Remove items entirely.

Once the order has been approved and sent to the kitchen, edits from the guest’s phone are no longer possible. At that point, any changes go through the normal POS cancellation flow (which requires a manager PIN — see Refunds, Cancellations & Edits).

4.8 Multiple Rounds

If “Allow Multiple Rounds” is on, the confirmation screen shows an Add More Items button after the first order. Tapping it returns the guest to the menu to build and place another order on the same table, using the same session. Each round goes through the same approval (or auto-fire) flow independently.

This is the feature that eliminates the “catch the waiter’s eye for a second round” problem. The guest orders at their own pace.

Part 5 — What Your Staff Sees

5.1 The Approval Sheet — POS Terminal

When QR orders come in with “Require Captain Approval” turned on, the POS terminal shows a QR Orders — Pending Approval panel. Each pending order appears as a card showing:

The table number and order number.
Every item in the order — quantity, name, variant (if any), and special instructions.

For each order, staff have two actions:

Approve (green button) — creates KOTs immediately, grouped by station just like a normal POS order. The guest’s phone updates to show “Order placed!”
Reject (red button) — opens a dialog for an optional rejection reason. The items are removed, and the guest sees that their order was not accepted.

The panel refreshes automatically every 60 seconds, and there’s a manual refresh button for the impatient.

5.2 Captain App

The Captain App shows the list of pending QR orders, and your floor captains can approve or reject them directly from the app — no need to walk back to the POS terminal. Rejecting prompts for an optional reason, just like on the terminal. This is handy on a busy floor where the captain is already moving between tables.

One guard worth knowing: only the captain currently serving that table — or the terminal — can approve its QR orders. If another captain holds the table (they opened it and hold its lock), everyone else sees the pending order read-only, with a “Being served by …” banner instead of the Approve/Reject buttons. That stops two captains from approving the same round twice, and keeps the table’s order history with the person actually serving it. The terminal can always approve, and a lock that’s gone stale (the captain walked off, five-plus minutes idle) releases automatically.

Part 6 — How QR Orders Reach the Kitchen

Once a QR order is approved (or auto-fired), KOT creation follows exactly the same path as a POS order:

Items are grouped by station — if you have a Tandoor station and a Bar station, the tandoor items and bar items each get their own ticket, just like they would from the billing screen.
The KOT prints on the station’s assigned printer (or queues on-screen if no printer is configured).
The guest’s phone shows live status as items move through the kitchen — pending, in progress, ready.

This parity is intentional. A QR order and a POS order are the same thing once they enter the kitchen pipeline. Your reports, stock decrements, day-close totals — everything downstream — treat them identically. There is no separate “QR orders report” because there doesn’t need to be.

The parity includes the kitchen guards: before a QR order fires a KOT, Meztezz runs the same checks a POS order gets — expired batches, expired liquor at the bar, insufficient liquor stock. If an auto-fire order (approval turned off) trips one of these, it isn’t silently dropped and it isn’t forced through — it falls back into the captain-approval queue so a human decides. A guest can’t order their way past the bar’s excise rules just because the order came from a phone.

Part 7 — Honest List of What Meztezz Doesn’t Do (Yet)

We’d rather you know in advance.

No payment on the guest’s phone. The QR flow is order-only. The bill is settled at the POS terminal — cash, card, UPI, split. There is no in-browser checkout.
No item images on the guest menu. The menu shows item names, prices, and veg/non-veg indicators, but not photos. The data field exists under the hood — this is a display feature we haven’t shipped yet, not a data gap.
No multi-language menu. The guest sees item names and descriptions exactly as you entered them in Masters. If your menu is in English, the QR menu is in English. There is no language switcher.
No allergen or dietary filter. The guest can’t filter by “gluten-free” or “contains nuts”. The veg/non-veg badge is the only dietary signal today.
No real-time push notifications. The guest’s phone polls for order status — it doesn’t receive instant push notifications. The polling is fast enough that delays are measured in seconds, not minutes, but it’s not truly real-time.
No favourites or order history. Each session is fresh. A returning guest can’t pull up “my usual” from a previous visit.
No loyalty or reward integration on the guest side. The QR flow doesn’t identify the guest at all — linking the bill to a customer record (and their loyalty points) happens at the POS when the bill is settled, the same as any walk-in. There’s no “you have 200 points, redeem now” screen on the QR menu.
No public internet access. The guest must be on the same Wi-Fi network as the terminal. A guest on mobile data can’t reach the QR page. This is a feature of the offline-first architecture, not a bug — but it means you need reliable Wi-Fi in the dining area.

If any of these are important to your operation, write in — we prioritise feature work based on what real restaurants ask for.

Part 8 — A Few Habits That Save You Later

Start with approval on. Even if you plan to let orders auto-fire eventually, keep “Require Captain Approval” on for the first week. It lets your staff build trust in the system and catch any menu mistakes (wrong prices, missing variants) before they reach the kitchen. Turn it off once the flow feels natural.
Assign a static IP to your POS terminal. If your router reassigns IPs after a restart, every QR code on every table will point to the wrong address. A one-time static IP assignment in your router settings avoids this entirely.
Test the QR codes under real lighting. A code that scans perfectly on a bright countertop may fail under dim mood lighting. Test from a seated position, at the distance a guest would naturally hold their phone. Laminate or use clear protectors — ink smudges kill scans.
Keep alcohol off the QR menu if you’re unsure. In many Indian states, serving alcohol requires a visible staff interaction. If your license has conditions around how liquor is ordered, keep “Show Alcohol Items” off and let the waiter handle those orders traditionally.
Tell your guests it exists. A QR sticker alone isn’t always enough — some guests assume it’s a feedback form or a Wi-Fi login. A one-line table tent (“Scan to order from your phone”) or a brief mention from the host (“you can also order directly from the QR code on your table”) goes a long way.
Set the session timeout to match your typical table turnover. If your average dine-in is 90 minutes, a 120-minute timeout is fine. A quick-service café might drop it to 30–45 minutes so stale sessions don’t pile up.

Stuck? We’re Here to Help

If the QR code won’t scan, the menu won’t load, or an order got stuck in the approval queue and you can’t figure out why — drop us a line at bazimat@gmail.com or contact us. Tell us which part of this guide you’re on and what you’re seeing; screenshots from the guest’s phone and the POS screen help us sort it out fast.

QR ordering isn’t about replacing your staff — it’s about freeing them from the back-and-forth so they can focus on hospitality instead of logistics. Set it up once, print the codes, and let your guests order at their own pace.