QR ordering across three rooms: cafe, restaurant, hotel

QR menus work differently when the room is a 10-table cafe, a 60-table full-service restaurant, or a hotel running poolside and room service in one organization. The mechanism is the same printable QR per table, but the defaults, the approval policy, and the plan tier that fits each room are not. MobiTaste publishes a price for each shape and ships the same kitchen view across all three.

Three rooms, three defaults

A cafe is the smallest deployment. One barista, ten tables, auto-approve on so the second order from a table goes straight through. Starter at $10 a month covers up to 20 tables and stays on the same plan as you add summer seating. The cafe walkthrough is the closest fit for a one-owner operation.

A full-service restaurant is the most common deployment. A waiter team takes drinks and recommends dishes; the QR removes the dead time between sitting down and the first order. Growth at $25 a month covers 60 tables per location across three locations, and waiter approval gates the first ticket from every table. The full-service walkthrough covers the rhythm.

A hotel runs three F&B outlets under one organization: restaurant, pool bar, and room service. Each outlet has its own menu, its own table list, and its own audit log; cross-outlet reporting rolls up. Pro at $60 a month covers ten outlets and includes the REST API for PMS integration. The hotel walkthrough covers brand controls and the room-service approval gate.

How to pick

If you take orders at the counter today and the kitchen is also the bar, start with the cafe page. If you have a floor team and a separate kitchen, start with the full-service page. If you have more than one outlet under one brand, start with the hotel page. Pricing math sits on the pricing page; every feature behind the three rooms is on the features hub.

A note on what we do not cover

MobiTaste fits sit-down and counter-service hospitality. We do not cover food trucks, ghost kitchens, or large-format aggregator workflows. The product runs on a table-token model, so service formats without a stable table position do not fit. That is a deliberate trade-off, not a roadmap gap.