Start with service, not software
A QR code only opens the door. The important decision is what should happen after a guest scans it. Some venues need a menu that stays current. Others want guests to place and pay for an order themselves. A full-service restaurant may want the guest menu to support the floor team without replacing it.
Write down the service path you already trust before choosing features. Who confirms the order? When is the table known? When is payment taken? Where does the kitchen or bar see new work? A digital flow should make those hand-offs clearer, not create a second version of them.
Option 1: a view-only menu
A view-only menu is the smallest operational change. Guests scan, browse the current categories and prices, then order through the same waiter or counter process the venue already uses. It is useful when the main problem is replacing printed menus, publishing changes quickly, or offering multiple menu languages.
Because the guest cannot submit a cart, the venue does not need to introduce a new preparation queue on day one. The trade-off is that every order still passes through staff. That may be exactly right for a high-touch dining room, but less useful for a busy counter where ordering is the bottleneck.
Option 2: guest ordering, with payment before or after
Self-ordering lets the guest choose items and submit an order from the menu. The venue still needs an explicit destination for that work: a receipt printer, an order board, or a staff workflow that someone is responsible for watching.
Payment timing is a separate decision. Prepayment can make sense where an accepted order should already be settled. Post-payment can fit venues that want to prepare first or settle later. A bill-only flow is different again: the guest is not creating new items, only paying an existing table balance. These modes should not be blended into one vague “pay online” switch because their failure and staff hand-off points differ.
Option 3: waiter-led table service
Waiter-led service keeps the staff member in control of tables, rounds and item entry while using shared preparation and till views behind the scenes. It is a better fit when guests regularly add rounds, split payments, move through courses, or ask staff to manage the order for them.
This is more than a customer cart. The venue needs agreed states for a table, preparation lines, ready or served items, payment allocations and closing the service. Treating it as a simple checkout flow usually hides the exact operational questions that need answers.
Five questions to decide
Use one real shift as the test case. Follow an order from scan to settlement and answer the questions below with the people who will operate it.
- Does the guest order, or does a staff member remain the order authority?
- Is a table required, optional, or irrelevant to the service?
- Should payment happen before preparation, after ordering, or at the till?
- Which person and device will notice a new order, and what is the fallback if that device is unavailable?
- Can the venue start with a view-only menu and add operational steps after staff have tested them?
Launch the narrowest complete flow
Choose the smallest workflow that can run from beginning to end without an improvised hand-off. Test it with the actual menu, actual devices and the staff who will use it. Payment, printing and fiscal integrations require their own provider configuration and go-live checks; a successful menu preview is not proof that those external steps are active.
ProntoMenu supports different venue modes from the same menu platform, so the useful starting point is not the longest feature list. It is the service path your team can explain in one minute and recover when something goes wrong.