Restaurant OS — Setup

Restaurant OS turns an ordinary ScaanMe store card into a full dine-in QR menu system. Instead of a customer browsing a catalogue and messaging you on WhatsApp, they scan the QR sticker on their table, see your live menu with prices and prep-time ETAs, build a cart, and place an order that lands as a real, tracked order with a lifecycle — Received → Confirmed → Preparing → Ready → Served → Completed. The same store you already built (categories, products, currency) becomes the menu; nothing is rebuilt.

It comes in two flavours, and you pick the one that matches your business. Restaurant is the full dine-in OS: table ordering, kitchen screen, courses, and table QR/NFC stickers — dine_in is on. Cafe shares the table-ordering and kitchen screen but is tuned for counter, pickup and order-ahead rather than dine-in, with simpler item modifiers. A plain Shop has no OS surface at all — it stays the classic catalogue-and-cart store. You choose between these per store, so one account can run a restaurant and a shop side by side.

Two things switch this on: your store's type must be Restaurant or Cafe, and your subscription plan must carry that type's flag (restaurant_os for restaurants, cafe_os for cafés). If your plan doesn't include it, the Restaurant/Cafe options simply won't appear in the store-type picker, and the management hub stays hidden. This is intentional — it's a premium capability. Note that customer capture (CRM) is never gated: even before the OS is on, a table scan still records the visit; only the ordering menu and kitchen tools are plan-locked.

Why this step: Restaurant OS attaches to an existing store card, not a vCard. So before anything else you need a store with at least a few categories and products — that catalogue becomes your menu. If you don't have a store yet, create one first and add your dishes as products with prices, then come back here.

Open Stores from your dashboard, find the store you want, and open its actions menu (the three-dots ⋮ button on the store row). When your plan includes an OS type, you'll see a Store type group inside that menu listing the options your plan allows — Shop, and Restaurant and/or Cafe. The currently active type has a checkmark.

Click Restaurant (or Cafe). The choice saves instantly and the store's os_type flips over. Behind the scenes the system re-checks your plan entitlement on save, so you can never assign a type your plan doesn't carry — an honest guardrail, not a trick. Choosing Shop again at any time simply turns the OS surface back off for that store without touching any of your products, categories, or settings; it's fully reversible.

Once the type is Restaurant or Cafe, a new Business OS group appears in that same actions menu, with three quick links: the hub (Restaurant/Cafe hub), Tables & QR (called *Pickup QR* for a café), and the Kitchen screen. These are your entry points for everything that follows. The labels adapt to the type, so a café shows café wording and a restaurant shows restaurant wording.

What it is: Opening the hub for the first time drops you into a guided 5-step setup wizard that walks you from zero to a working QR menu. The wizard is honest — each step shows a green tick only when its data actually exists, and it lands you on the first unfinished step automatically. You can jump to any step at will; nothing is forced in order once you understand the flow.

Step 1 — Ordering modes. Here you pick which fulfilment modes your menu offers via three toggles: Dine-in, Pickup (take-away), and Delivery. These write straight into the same delivery_options your storefront already reads, so they stay consistent everywhere. Important edge case: a table scan is inherently dine-in, so the system never lets you switch all three off — if you try, Dine-in is forced back on automatically. This step also carries the kitchen-load toggle (covered in its own block below).

Step 2 — Prep times. This is where you set an average minutes per dish, which powers the live ETA badges customers see on the menu and the order's promised ready time. Each product from your catalogue gets a minutes field; the default is 10 minutes if you leave one blank, and values are clamped to a sane 0–240 range. You don't have to fill in every item — a quick pass on your slower dishes (grills, oven items) sharpens the ETA most. If your store has no products yet, the wizard marks this step done so you're not blocked.

Step 3 — Tables. Create the physical tables you'll put stickers on. The wizard offers both a single add a table form and a bulk option (e.g. "add 12 tables"). The step turns green as soon as you have at least one table. Full field-by-field detail is in the Creating tables block below.

Step 4 — Stickers / QR. This step is about getting QR (and optionally NFC) onto the tables. From here you reach the printable QR sheet and the per-table NFC linking. Step 5 is the finish line — a recap confirming your menu is live and pointing you to the hub, the kitchen screen, and your first table's public link. After this, scanning any table token at /t/{token} opens your menu.

What/why: A table is the unit everything hangs off. Each table you create gets a unique, un-guessable token (a short 8-character code) and its own public URL — /t/{token} — which is exactly what the QR encodes. When a customer scans, the system resolves the token to *this table at this store*, opens a dine-in session, and stamps the visit so orders and CRM activity are tied to the right table. Manage tables from the Tables & QR page (or *Pickup QR* for a café).

To add one table: click Add table and fill the form. Label is required (up to 120 characters) — this is what staff and the kitchen see, so use something human like "Table 5", "Patio 2", or "Bar seat 3". Zone is optional (up to 120 characters) — a free-text grouping such as "Indoor", "Terrace", or "VIP room" that helps you organise and print by area later. Save, and the table appears with its token and a ready-to-print QR.

To add many at once: use the bulk control. Set a count (1–100), an optional prefix (defaults to "Table"), and an optional zone applied to all of them. The system names them "<prefix> 1, 2, 3 …" and is smart about continuing the numbering: if you already have "Table 1–10" and bulk-add 5 more with the same prefix, you get Table 11–15, never duplicates. This is the fastest way to stand up a whole floor in seconds.

To edit a table: open it and change its Label, Zone, or Status. Status is active or inactive — set a table inactive when it's temporarily out of service (a booth being refurbished); an inactive table won't show on the printable sheet but isn't deleted. Editing keeps the same token, so any sticker already on the table keeps working — you never have to re-print after a rename.

To delete a table: use the delete action. This is a soft delete — the table is hidden and removed from sheets, and if it had an NFC key linked, that key is automatically released first so a stray tap can no longer resolve a dead table. Because deletion is soft, your historical orders that referenced the table stay intact for reporting. Treat delete as "retire this table", not "erase its history".

What/why: Each table needs a physical QR that customers can scan. The QR sheet generates print-ready stickers for every active table at once, each labelled and pointing at that table's /t/{token}. The QR codes are drawn on your own server (a canvas-based renderer) — never fetched from an outside QR service — so nothing about your tables leaks to a third party. That's a privacy and reliability choice, not an accident.

To print all tables: open QR sheet from the Tables page (or the wizard's sticker step), review the grid, and use the Print action — it opens a clean, print-optimised page (the print view strips the dashboard chrome so only the labelled QR tiles remain). Print on sticker stock or laminate the cut-outs, then place one on each matching table. Re-print any time you add tables; existing tokens never change, so you only print the new ones.

To print one table: the sheet supports a single-table variant — handy when you replaced or damaged one sticker and don't want to re-run the whole floor. Open the print page filtered to that table and print just its tile. This saves paper and keeps the rest of your tables undisturbed.

Adding NFC (optional, premium touch): beyond QR, each table can also carry an NFC tap. On the Tables page, use Link NFC on a table to mint a fresh NFC key tied to that table and your store. You then program a blank NFC sticker/chip with the table's /t/{token} so a tap opens the same menu a scan would. A table can have both QR and NFC, or just one. If a table already has a key, you must unlink it before linking a new one — this prevents two keys silently pointing at the same table.

To unlink NFC: use Unlink on the table. The key is released back to the pool (its link is cleared) and the table goes back to QR-only. Always unlink before retiring or repurposing a physical chip; deleting a table also auto-unlinks its key for you, so you can't leave a dangling tap pointing nowhere.

What/why: Beyond first-time setup, the Settings page is where you keep tuning how ordering behaves. It re-exposes the three ordering modes (Dine-in, Pickup, Delivery) so you can, say, switch Delivery off during a rush, plus the kitchen-load control and a read-out of your Restaurant OS entitlement. Everything saves to the same delivery_options and restaurant_config the storefront reads, so changes take effect immediately on the customer menu.

Kitchen-load is a smart toggle for busy service. When it's on, the ETA shown to customers factors in how many orders are already in the kitchen — so during a rush the promised time stretches honestly instead of over-promising and disappointing. Turn it off if you'd rather quote a flat per-dish ETA. It's a one-switch way to keep customer expectations realistic without you doing any maths.

The ordering-modes guardrail applies here too: you can never save with all three modes off, because a table scan is dine-in by definition — the system silently re-enables Dine-in if you try. Think of the three toggles as "which checkout choices the customer sees", and remember the customer's *physical* context (they're sitting at a scanned table) always implies dine-in is available.

The Restaurant OS line on Settings reflects your plan entitlement — it's an honest status, not a free switch. You can't grant yourself an entitlement your plan doesn't carry; if it shows as unavailable, that's a billing/plan matter, not a settings toggle. This is the same gate that decides whether the whole OS surface (menu, tables, kitchen) is visible at all.

Build your menu before you print. The QR menu shows whatever in-stock products and prices your store has at scan time. Get categories, dish names, prices, and at least your slower dishes' prep times set *first* — then print stickers. A customer scanning an empty or half-priced menu is a bad first impression you can't un-do for that table.

Use Zones to stay organised. Even if you only have 15 tables, tagging them "Indoor / Terrace / Bar" makes the printable sheet and your kitchen screen far easier to scan at a glance, and it scales cleanly when you add a section. Zones cost nothing and pay off the day you expand.

Bulk-add, then rename the exceptions. The fastest setup is one bulk-add for the whole floor (e.g. 20 tables) followed by editing the two or three special spots ("Bar 1", "Window booth"). Because edits keep the same token, you can rename freely after printing — the sticker still works.

Add NFC where the moment is premium. QR is universal and free to print; reserve NFC taps for high-touch spots — a host stand, a VIP room, the bill folder — where a tap-to-order feels special. You don't need NFC on every table to look high-end; a few well-placed taps do the trick.

Test one table before the whole floor. Print a single sticker, scan it with your own phone, place a test order, and watch it appear on the kitchen screen. Five minutes of testing on one table catches a wrong price or a missing prep time before 30 customers hit it at once on opening night.

Do I need a separate plan to use Restaurant OS? Yes — your subscription plan must carry the restaurant_os flag (or cafe_os for a café). Without it, the Restaurant/Cafe options won't even appear in the store-type picker and the hub stays hidden. One exception worth knowing: customer capture is never gated, so a table scan still records the visit into your CRM even before the OS is unlocked.

What's the difference between Restaurant and Cafe mode? Both give you table ordering, a kitchen screen, and table QR/NFC. Restaurant adds full dine-in sessions, courses, and full item modifiers. Cafe turns dine-in off in favour of counter, pickup and order-ahead, with simpler modifiers — and even its labels change ("Pickup QR" instead of "Tables & QR"). Pick the one that matches how guests actually receive their food.

If I switch a store back to Shop, do I lose my tables and menu? No. Switching to Shop only turns the OS *surface* off — your products, categories, tables, tokens, prep times and settings are all preserved. Flip the store back to Restaurant or Cafe and everything reappears exactly as it was. The type is a display gate, not a delete.

Can one table have both a QR and an NFC tap? Yes. QR and NFC both point at the same /t/{token}, so a guest can scan *or* tap and land on the identical menu. A table can carry both, just one, or neither (until you print). If a table already has an NFC key, unlink it before linking a new one — the system blocks a second key to avoid two chips silently pointing at the same table.

Where do incoming orders go? A placed order becomes a tracked restaurant order with a live status (Received → Confirmed → Preparing → Ready → Served → Completed) and shows up on your Kitchen screen and the hub's today's-orders count. The customer sees a live timeline of their order's status. The kitchen screen is a separate guide, but you reach it from the same Business OS menu.

Why is the ETA different each time? If you turned on kitchen-load, the promised time adapts to how busy the kitchen is right now, on top of each dish's base prep minutes — so a quiet afternoon quotes faster than a packed Friday night. Turn kitchen-load off if you prefer a fixed per-dish ETA. Either way, ETAs are clamped to a sensible 0–240-minute range so a bad input can't promise an absurd time.

Do I have to set a prep time for every dish? No. Any dish you leave blank uses a sensible default of 10 minutes. It's worth setting real numbers for your slower items (grills, oven dishes) so the customer ETA is honest, but you're never blocked from going live just because some quick items use the default.