Why every first QR order pauses for a staff tap

Open QR menus have a known failure mode: a stranger scans the code from outside the restaurant, fires fake orders, and the kitchen wastes prep on food that no guest will pay for. The pattern hit international news with the 2024 Kunming incident, and it surfaces in nearly every founder conversation we have with restaurant owners. The fix is small, the cost is one tap per table per visit, and the mechanism is what this guide describes.

The pattern has a name: an approval gate. The glossary entry is the 22-word definition. The rest of this guide is the mechanism, the trade-offs, and the edge cases.

The objection in plain words

A QR menu is a URL. URLs are public; anyone with the link or a camera can open one. If you print a QR card and put it on a sidewalk table, a passer-by can scan it from the street and submit an order without ever sitting at the table. The order lands on your kitchen screen, the cook starts prep, and the food is ready for a guest who does not exist.

The 2024 Kunming case escalated because students realized a QR menu published online (intended for an in-store screen) had no gate. They submitted dozens of fake orders from off-site, and the kitchen burned a service worth of prep before staff caught on. The story made the rounds in restaurant tech circles, and “what stops this from happening to me” became a standard objection in every QR menu sales call.

The objection is fair. The fix is also straightforward.

The mechanism: an approval gate

In MobiTaste, every QR menu carries a per-table token. When a new table token submits its first order, the order lands in a Pending column on the floor view. The kitchen screen does not see the order. A staff member taps Approve, and only then does the ticket reach the kitchen.

After approval, follow-up orders from the same table token flow through without another tap. That is the default. If you run a high-stakes setting (hotel F&B, a busy patio that faces the street), you can flip a setting to require approval on every order, not just the first.

The cost is roughly 1.5 seconds of staff time per first order. The benefit is that no prank scan, no curious passer-by, and no joke from across the street wastes a single minute of cook time.

What the kitchen sees

The kitchen screen renders only approved tickets. An unapproved order does not appear, does not flash, does not exist in the kitchen’s world. The cook starts prep on tickets that staff has acknowledged. If approval is on and nobody taps, the kitchen is quiet; the queue is on the floor.

That separation matters because cook attention is the scarce resource in a busy service. A kitchen that reacts to phantom orders loses prep time, loses focus, and loses trust in the screen. The approval gate removes the noise before it reaches the kitchen.

When to keep approval on

Keep approval on in any setting where a prank scan is plausible:

• Restaurants and bars on a street-facing patio where a passer-by can scan from outside.
• Hotels with public-facing F&B and outlets a non-guest can reach (poolside bars open to the public, lobby cafes).
• New venues in their first month, where the staff is still learning the floor.
• Any venue where you have caught one prank order in the last quarter.

The hotel use case covers why approval defaults to on in hotel F&B. The best-practices guide covers the on/off decision for cafes and restaurants.

When to flip approval off

Flip approval off in any setting where the friction outweighs the protection:

• Small cafes where the owner is on the floor and watching every scan.
• Bars with regulars where every scanner is a known face.
• Pop-ups and food trucks where the line is also the QR queue and staff would tap approve on every order anyway.
• Breakfast service in a corner shop where the kitchen is two steps from the host stand.

Auto-approve mode keeps the rest of the order board intact; only the approval step is removed. You can flip approval back on for dinner service the same day.

The audit log writes every approval

Every approval and rejection writes a row to the audit log: user, table token, items, timestamp, device. When you want to know who approved the 9pm order to table 12 last Saturday, that row is there. The log is useful for two things: training (a new server who is slow on approvals shows up in the data), and dispute resolution (a guest claims an order was rejected; the log tells the story).

Audit retention runs 12 months on Starter and Growth, 36 months on Pro, and unlimited on Enterprise.

Edge cases

A guest closes the page before approval. The order stays in Pending until the table session expires (default 30 minutes) or staff explicitly clears it. If you approve after the guest left, you might prep food that never gets eaten. Watch the Pending column during peak.

A table session expires while an order is pending. The order is voided automatically and a void event writes to the audit log. The kitchen never sees it.

Two waiters approve at once. The first tap wins; the second tap is a no-op. The audit log records the winning approver.

A guest re-scans after the session expires. They get a fresh table token, which means the next order is treated as a first order and lands in Pending again. The system does not remember that they were the same person.

The floor tablet is offline when an order comes in. The order queues server-side. When the tablet reconnects, the Pending column populates and staff can approve normally. No order is lost.

What approval does not do

It does not validate identity. The staff tap is a human acknowledgement, not a guest check. If you need real identity on a guest order (very rare in hospitality), that is a separate problem.

It does not block second and third orders by default. The default is “first order per table token gates; the rest flow.” If you want every order to gate, you flip the per-order setting in restaurant configuration.

It does not slow real service when used correctly. A trained host taps approve in under two seconds. The bottleneck is paying attention to the queue, not the gate itself.

How to staff the queue

In a busy service, assign one person to watch the approval queue. The right role depends on the venue:

• Cafes: the barista at the counter, who can glance at the tablet between drinks.
• Full-service restaurants: the host at the host stand, who already controls the door.
• Hotels: the duty server on the floor, with a backup on the dashboard.

The best-practices guide covers the staffing pattern in detail. The rule of thumb: the approver should never be more than 30 seconds from the queue.

When approval breaks

The only real break in the system is operational, not technical. If nobody watches the queue, orders pile up in Pending, and guests wonder why their food is slow. The fix is staffing, not software.

The second-most-common break is leaving approval on at breakfast in a venue where it does not belong, then forgetting to flip it off. The audit log catches this: any approval that took over two minutes is a candidate for review.

Where to go next

For the underlying feature page, see waiter approval. For the operational walkthrough, the best-practices guide is next. For the spam-prevention questions in short form, the FAQ page has the standard answers.