Dine-in, QR & group orders

Each table you add gets its own QR code carrying a secure random token — scanning it opens your menu with the table already known. The customer orders without any address step, and the kitchen ticket names the table. Customers never pick a table from a list; the card they scanned IS the table.

The QR carries a long random code, not the table name — it can't be guessed from knowing you have a 'table 12'. Retiring a table kills its code instantly, and a retired code shows the normal delivery page rather than an error.

Old orders keep the name that was true when they were placed — renaming '12' to 'Terrace 3' never rewrites last month's tickets. New scans use the new name.

The QR designer styles the cards — code and background colours (four ready pairings or your own), a caption up to 60 characters, three card styles (Plain, Card, Badge), and an optional 'Show my logo above the code' toggle — with a built-in contrast check that refuses unscannable combinations. The logo sits at the top of Card and Badge styles, never over the code itself, so scanning is unaffected. Then download the print pack — a ZIP with a PNG and SVG per table plus a print-ready A4 PDF — or email the pack from the panel. One format note the designer also tells you: the A4 PDF can carry a PNG or JPG logo; a WebP logo appears on the preview and SVG files only.

For the sitting: the table rides the browser tab for up to 4 hours. Closing the tab and returning later via your normal address is a regular delivery visit again — by design, so yesterday's scan can't misfile today's delivery order.

Yes — dine-in checkout offers only the methods you allow for tables (e.g. cash only). If a saved choice isn't allowed for dine-in, checkout asks again rather than silently switching what the customer picked.

Scan-again (a returning-table perk), the table streak (rewarding consecutive visits), the happy-table draw (the system picks a winning occupied table — it knows which tables are seated), and a treasure hunt. The prize-bearing perks are on the Pro tier.

One customer starts a group order and shares a short link on WhatsApp. Everyone opens it on their own phone, adds their own items under their own name, and the starter sees the combined cart and pays one bill. The kitchen gets one ticket, itemised per person.

The person who started it — one order, one payment, one delivery. Participants choose items; the starter confirms and settles at the door as usual (cash or card machine).

No — coupons don't apply to group orders, deliberately: one shared bill with many contributors makes code discounts ambiguous. Group participants do still get the loyalty-card invitation, so joining a friend's order can still make them YOUR customer.

They give a name and WhatsApp number to join, and they're offered your wallet loyalty card during the flow — many of your future regulars first appear as someone's +1. Their details live under the same privacy rules as every customer.

Completely — the same menu serves both. A scanned visit is a table order; a normal visit is delivery with the address step. You don't run two systems, just one page that knows how the customer arrived.

Yes — dine-in orders carry the table name on the orders board, the kitchen ticket and the receipt. Delivery orders carry the building/unit instead.

The A4 sheet from the pack prints tent-cards that survive real tables. Place one per table, angled to the seat; laminate if you can. Re-download and re-print any single table's card at any time — the code stays stable unless you retire the table.

The kitchen/manager ticket, yes — that's how staff learn table 5 ordered. The customer confirmation flow is lighter than delivery (no rider dispatch, no address), and the customer sees their live order status on their phone right after ordering.

Deactivate tables and their codes stop resolving — scans fall back to the normal page. Reactivate and the same printed cards work again; you don't reprint anything.

Open Settings → Tables & QR ordering, find the table and press 'New code', then confirm 'Issue new code'. The table keeps its name and history, but every card ever printed for it stops working immediately — reprint that one table from the pack. Deleting the table instead would detach its past orders, which is why a used table is switched off rather than removed.

One setting on the Dine-in perks page: 'Minutes a table stays busy after an order' (15–360, default 90). A table is busy while its most recent table order is that fresh; a newer order at the same table replaces the older one, and a cancelled order empties it. Nobody presses a button.

The draw skips itself, quietly, whenever fewer than the minimum number of tables are busy at the hour you chose — and the minimum can never go below three: with one or two busy tables it is not a draw, it is a gift, and the losing table can see who won. It also needs Promotions on your plan; scan-again and streaks keep working without it.

Settings → Group orders (it sits with your marketing pages and needs the Promotions plan). Four settings: how many people including the organiser (2–50, default 20), how long a shared cart stays open (1–168 hours, default 24), who earns loyalty stamps (organiser only, or split by each person's own items — splitting divides the same money, it never creates stamps), and whether the organiser may remove somebody else's item (off by default).

Anyone with the link joins by giving a name and WhatsApp number, and everyone can add, change or remove their OWN items. The organiser can remove someone else's item only if you switched that on — and even then can never change the quantity of another person's item. When something in the cart becomes unavailable, both the organiser and whoever added it get a WhatsApp.

No — the organiser's checkout asks for a building and unit, so a group order is always a delivery order. Card-only (wallet-exclusive) dishes are also hidden from group participants, because a shared cart has one payer and no shared loyalty card.