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 six controls:

Setting	Default	What it does
QR Ordering Enabled	Off	Master switch. Nothing else on this screen matters until this is on.
Require Phone Number	Off	When on, the guest must enter a 5–15 digit phone number before seeing the menu. Useful for loyalty lookups later; annoying for guests who just want to browse.
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 printed below it.
A Download PDF button that exports all codes in a print-ready layout — one code per card, labelled with the table number and your restaurant name, with “Scan to order” text.
You can filter by section if you only want to print codes for specific areas (e.g. just the rooftop tables).

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 beyond an optional 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. Two things can happen:

If “Require Phone Number” is off: The guest lands directly on the menu. A session token is created silently in the background.
If “Require Phone Number” is on: A simple screen asks for a 5–15 digit phone number. After entering it, the guest taps “Start Ordering” and arrives at the menu.

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. 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.

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.
The guest’s phone number (if phone collection is enabled).

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 plays a sound alert when new orders arrive (if enabled), so staff don’t need to keep checking manually. There’s also 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.

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.

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. If you collect phone numbers and later match them to customer records, that’s a manual step — 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.