Features

Waiter approval blocks fake QR orders

Make the first order from each table wait for a staff tap. Stops random QR spam, keeps service calm.

Waiter approval: the kitchen sees nothing until staff taps

Open QR menus invite a known prank: someone scans the code from outside the building, fires fake orders, and the kitchen burns prep on food that was never ordered. The 2024 Kunming incident put the pattern on the news, and it surfaces in nearly every founder conversation we have with restaurant owners. MobiTaste handles it with an approval gate that pauses the first order from each table until a staff member taps once.

How the gate works

When a new table token submits its first order, the order lands in a Pending column on the waiter view. The kitchen screen does not show it. Staff taps Approve, and only then does the ticket reach the kitchen. The cost is roughly 1.5 seconds of waiter 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.

After approval, follow-up orders from the same table token flow through without another tap. That is the default. You can flip a setting to require approval on every order if you run a high-stakes setting like hotel F&B; most restaurants do not.

The approval-gate glossary entry is the 22-word definition; the explainer guide is the 1,300-word version.

Who taps, and from where

Any role above guest can tap Approve: server, manager, owner. The Pending column shows the table number, the items, and a one-line note from the guest if they wrote one. The tap takes one finger and one second. Most cafes assign a single host or a senior server to watch the queue during peak service.

On a tablet on the host stand, the queue ticks in real time. On a phone in the head waiter’s pocket, the same queue rings a soft tone on a new pending order. You choose the device based on how busy the floor is; the system does not care.

When to keep it on, when to flip it off

Keep approval on during dinner service, on patios that face the street, in hotels with public-facing F&B, and in any setting where a prank is plausible. Keep it on for the first month after launch in any new venue. The audit log records each approval with the user and the timestamp, which is useful when you later look back at a chaotic shift.

Flip it off for breakfast in a corner cafe where the owner is on the floor and watching every scan. Flip it off for a small bar with regulars. Flip it off for a pop-up where the line is also the QR queue and staff would tap approve on every order anyway.

The hotel use case discusses why approval defaults to on at hotels even when the rest of the F&B settings differ. For a smaller setting, the best-practices guide covers the on/off decision in detail.

What approval does not do

It does not validate identity. The system has no idea who the scanner is, and the staff tap is not a person check. The point is to gate kitchen work behind a human acknowledgement, not to authenticate the guest. If you need real identity on a guest order (rare in hospitality), that is a separate problem and a separate product.

It does not reject orders silently. If an order is pending and the table closes the page, the order expires with the table session. If the server explicitly rejects, the order disappears from the queue, and a rejection event is written to the audit log.

Audit log on every approval

Every approval and rejection writes 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. Audit retention runs 12 months on Starter and Growth, 36 months on Pro, and unlimited on Enterprise.

What this changes about your shift

Two things. First, the floor is calmer because the kitchen no longer reacts to phantom orders. Second, the kitchen is calmer because every ticket that arrives is a ticket that should arrive. The cost is one tap and a second of attention per new table. The explainer guide discusses the trade-offs and walks through an edge case (a guest who closes the page before approval).

Where to go next

If you want the full mechanism in plain words, read the waiter approval explained guide. If you want the wider feature list, the features hub is the index. If you are running a hotel F&B, the hotel use case is the closest fit. For specific objections, the FAQ page covers the spam-prevention questions.