Live Kitchen Screen & Cafe OS

The Kitchen Screen (also called the KDS — Kitchen Display Screen) is the live, staff-facing board where every order placed from a table lands in real time. The moment a diner taps Place order on their phone, a big order card appears on this screen, and your team moves it through the kitchen with one tap per stage — from received all the way to completed. It replaces the printed ticket and the shouting across the pass with a single shared display that everyone behind the counter can read at a glance.

It is built for any food business that takes orders at a table or counter: a full-service restaurant, a café, a food truck, a juice bar, a dessert shop. The owner sets it up once from the dashboard; after that the people who actually use it day to day are your kitchen and floor staff — they only ever touch the order cards, never the settings. Because everything runs in a normal browser, the screen works on a cheap tablet propped at the pass, a laptop, or a wall-mounted monitor, with no app to install.

Why it matters: the order is the spine of the whole Restaurant OS. Every tap your staff makes is timestamped and written to a history log, which is exactly what feeds the diner's live timeline ("In the kitchen… Ready!"), your per-table revenue, and the customer record in your CRM. So the Kitchen Screen is not just a convenience for staff — it is how a casual visitor quietly becomes a named customer with a history you can market to later. Get the kitchen flow right and the analytics, loyalty, and customer-intelligence features downstream all light up on their own.

One thing to set right from the start: the Kitchen Screen and the whole ordering surface are part of an OS plan add-on. Your store's type must be set to Restaurant or Café (not a plain Shop), and your plan must carry the matching entitlement (restaurant_os or cafe_os). If either is missing, the kitchen and table-ordering pages return a not-found page — but note that customer capture is never blocked: even without the OS surface, a table scan still records the visit into your CRM. The gate only hides the ordering machinery, never the data collection.

What it is / why: before any order can reach your kitchen screen, a diner has to place one. Every table you create gets its own short, private link of the form /t/{token} — a random 8-character code that is impossible to guess. You print that link as a QR sticker for the table (or encode it on an NFC tag); the diner scans it with their phone camera, no app needed, and your live menu opens instantly. This is the front door of the whole system, so it is worth understanding exactly what the diner sees.

The menu loads with only in-stock items. The diner browses by category, and each dish shows its name, photo, short description, price (the sale price if one is set, otherwise the regular price), and any badge you gave it. Crucially, only products marked in stock appear — anything you mark out of stock disappears from the menu the instant the page is opened, so a diner can never order the soup you ran out of. Some dishes also show a small ETA badge drawn from the prep time you configured, setting expectations before they even add to cart.

The diner picks an order mode. At the top of the cart they choose how they want the order handled: Dine in (the default for a table scan, and frictionless — no name or phone needed), Pickup, or Delivery. Which modes appear is entirely up to you: they mirror the ordering modes you enabled in settings, so a café that only does counter pickup simply won't show a Dine-in option. For Pickup and Delivery the diner is asked for a name and phone (and for Delivery, an address), because you need a way to call the order and reach them; Dine-in stays deliberately anonymous and fast.

Payment is in person — never online. The diner picks how they will pay from the choices your store offers: Cash, Pay at counter, or Pay at table. ScaanMe v1 does not take card payments here; the fine print on the order screen says it plainly — "No online payment — you pay in person. Prices confirmed by the kitchen." This is a deliberate, trust-first design: the diner orders, you confirm and prepare, and money changes hands the normal way. It also means you never owe a gateway fee on a dine-in order.

The diner taps Place order, and the totals are recalculated on the server. This matters for your protection: ScaanMe never trusts the price the phone sends. The moment the order is submitted, the system re-prices every line straight from your database, silently drops any item that has gone out of stock, and computes the real subtotal and total itself. So a tampered or stale cart can never charge the wrong amount. The diner instantly gets an order reference, an ETA, and a live timeline link — and at the same second, the order appears on your Kitchen Screen.

The diner then watches a live timeline. Their phone keeps a page open at /t/o/{order_id} that polls for updates and shows a friendly status gauge: Order received → Confirmed → In the kitchen → Ready → Served → Completed, with an estimated-ready countdown and little touches like "Chef is on it." Every time your staff advances the order on the Kitchen Screen, this page reflects it within seconds — no refresh needed. That is the magic loop: one tap at the pass updates the customer's phone automatically, so nobody has to ask "is it ready yet?"

What it shows / why: open the Kitchen Screen from your Restaurant hub (or go straight to user/restaurant/{cardId}/kitchen). The whole layout is designed to be readable from across a hot kitchen: three colour-coded lanes run left to right, and each active order is one big card sitting in the lane that matches its status. The screen shows only orders that are still in the kitchen — anything already served, completed, or cancelled drops off automatically, so the board never clutters up with finished work.

The three lanes are New, Preparing, and Ready. A freshly placed order lands in New (it holds both the *received* and *confirmed* statuses). When a cook starts on it, it moves to Preparing. When the dish is done and waiting at the pass, it moves to Ready. Each lane header shows a live count badge, so at a glance you know how many tickets are waiting, cooking, and plated. Within each lane, cards are sorted oldest first — the order that has been waiting longest sits at the top, keeping your queue fair and first-in-first-out.

Each order card carries everything the line needs. The card headline is the table label (e.g. "Table 7") with a small mode chip (Dine in / Pickup / Delivery). Below that it lists every item and quantity, plus any modifiers. On the right it shows two timers: a big elapsed clock counting up from when the order was placed, and a smaller ETA line. The elapsed clock keeps ticking on its own between data refreshes, so it is always honest about how long this ticket has been waiting — your team's cue to hustle a card that has been sitting too long.

Customer notes are impossible to miss. If a diner typed a note — "no onions," "allergic to nuts," "extra spicy" — it appears on the card in a bright amber strip that stands out from the rest of the card. This is deliberate: special requests are the easiest thing to overlook on a busy line and the most costly to get wrong, so the screen colours them to grab attention. Train your staff to read the amber strip before they start cooking.

The kitchen-load bar at the top is your pressure gauge. It shows the total count of active orders and a one-word busyness band: Calm, Busy, or Slammed. The bands are honest arithmetic off the live count — Calm under 5 active orders, Busy at 5 or more, and Slammed at 12 or more — not a guess or an AI estimate. Beside it, three small counters break down New / Preparing / Ready, and a green pulsing dot with "Live · updates automatically" confirms the screen is connected and refreshing.

The screen refreshes itself every 7 seconds — no websockets, no manual reload. The Kitchen Screen quietly polls the server roughly every seven seconds and re-paints the lanes, which is how a brand-new order silently appears without anyone touching anything. This polling approach is intentional: at real restaurant volumes it is rock-solid and needs no special server setup. There is also a Full screen button in the header so you can hide the browser chrome and dedicate the whole tablet or monitor to the board.

What it is / why: the heart of the Kitchen Screen is the big coloured button at the bottom of every card. It always shows the next action verb for that card's current stage, so your staff never has to remember the order of steps — they just tap the button that says what to do next. One tap advances the order exactly one stage, writes a timestamped record of the change, and instantly re-paints the board and the diner's phone. No menus, no dragging, no typing.

The full lifecycle has six stages, in a fixed order. They are: received → confirmed → preparing → ready → served → completed. The advance button walks this chain one step at a time, and the verb changes to match: from received you tap Confirm; from confirmed you tap Start preparing; from preparing you tap Mark ready; from ready you tap Mark served; and from served you tap Complete. That sequence is the same chain the diner's timeline displays, which is why their phone always shows exactly the stage your kitchen is on.

Every advance is permanently logged. When you tap the button, the system records the exact transition — from which status, to which status, and the precise time — in an order status history. This is not just bookkeeping: that log is what powers the diner's live timeline, your average prep-time reporting, and the customer's CRM record. Because each tap is a clean, single, transactional write, two staff members can't accidentally corrupt an order by tapping at once, and the history is always a truthful trail of who-did-what-when (with staff-name attribution arriving in a later phase).

Marking an order served or completed closes the table session. When you advance a dine-in order to served, completed, or cancelled, the system automatically closes the open dining session that order belonged to. This keeps your table state clean — a finished table is no longer shown as occupied — and means the next group who scans that same table starts a fresh, separate order session rather than landing inside the previous party's tab. You don't do anything extra; closing the session is a free side effect of finishing the order.

Cancelling an order. Beside the advance button on each card is a small X (cancel) control. Tapping it sets the order to cancelled — an explicit, off-the-main-chain status — and like a serve/complete, it closes the table's session. Use it for a mistaken order, a walkout, or a duplicate. Cancellation is logged the same honest way as any other transition, so it shows up plainly in the order history rather than the ticket just silently vanishing. There is no undo on a cancel, so it is the one button to treat with care.

A few honest guardrails protect the flow. You cannot advance an order that is already completed — the system returns a gentle "this order is already complete" rather than looping. You also can't move an order to a status it is already in. And the screen only ever lists orders that belong to your own store, gated by your ownership and plan, so staff on one restaurant's screen can never see or touch another store's tickets. These rules mean the one-tap simplicity never turns into a way to put an order into an impossible state.

What it is / why: ScaanMe ships the same ordering engine in two flavours, set by your store's type. Restaurant OS is the full dine-in experience; Café OS is tuned for counter, pickup and order-ahead. They share the exact same Kitchen Screen, the same six-stage lifecycle, the same one-tap advance, the same QR/NFC tables, and the same live customer timeline — so anything you learned above works identically in both. The differences are deliberate, small, and all about matching the *shape* of how each kind of venue actually serves food.

Restaurant OS is dine-in-first. It turns on dine-in mode (table sessions, so a party keeps one running tab across several orders), coursing (sending starters, mains and desserts to the kitchen in sequence), and full item modifiers (the rich "no onions, medium-rare, add cheese, side of fries" depth a sit-down kitchen needs). Its hub and links are labelled in restaurant language — the QR section is "Tables & QR", because the unit of service is a physical table a guest sits at. Choose Restaurant if your guests sit down and you bring food to them.

Café OS is counter-and-pickup-first. It turns dine-in mode off and instead enables counter / pickup and order-ahead (a customer orders before they arrive and collects when it's ready). Coursing is off — a café sends everything at once, not in sequence — and modifiers are kept simple rather than the full restaurant depth (think "oat milk, extra shot" not a five-step build). Its QR section is even relabelled "Pickup QR" instead of "Tables & QR," because the unit of service is an order at a counter, not a seated table. Choose Café if customers order, wait, and collect.

The Kitchen Screen itself looks and works the same in both. The lanes, the cards, the load bar, the one-tap advance, the 7-second refresh — all identical. The only practical difference your kitchen staff notice is the order mode chip on each card (Dine in vs Pickup), and that a café's cards rarely carry a table label. So you don't retrain staff when you run a café: the board is the board. The OS type only changes what the *owner* configures and what the *diner* sees on the ordering page, not the pass.

A plain Shop has no OS at all. The third store type, Shop, is the regular catalogue-and-cart store every plan already has — no tables, no kitchen, no live timeline. It is always available with no add-on. Switching your store between Shop, Restaurant and Café is a setting on the store, but you can only pick a type your plan entitles you to: Restaurant needs restaurant_os and Café needs cafe_os. You can never grant yourself an entitlement you don't have, which is why the type selector only offers what your plan carries.

Mount one tablet at the pass and leave the Kitchen Screen open in full-screen. Because the board self-refreshes every 7 seconds, a dedicated always-on tablet means new orders simply *appear* — nobody has to check a printer or a phone. Tap Full screen to hide the browser bars and turn off the device's auto-sleep so it never dims mid-service. A cheap Android tablet on a stand is all you need; there is no app to buy or update.

Set realistic prep times before you go live. The diner's ETA is built from the per-product prep minutes you configure plus a kitchen-load factor that adds time automatically as you get busier. If your prep numbers are wishful, every ETA will be wrong and diners will feel misled. Walk through your menu once and enter honest average minutes per dish; you can always tune them after a few real services. A truthful ETA you beat builds far more trust than an optimistic one you miss.

Confirm orders promptly — the first tap matters most. The moment a new card lands in New, tapping Confirm flips the diner's timeline from "Order received" to "Confirmed," reassuring them you've seen it. That single tap is the cheapest customer-service win in the whole system. Make it a habit: glance at the New lane, confirm anything sitting there, then work the cards oldest-first down each lane.

Watch the load band, not just the count. When the bar reads Slammed, the ETA engine is already padding new orders' promised times — but that's also your signal to pull a second cook to the line, or to temporarily mark slow-prep items out of stock so they vanish from the menu and stop new tickets for them. Managing the band proactively keeps your real prep times close to the promised ones even during a rush.

Use out-of-stock as your live menu control. You don't edit the menu mid-service from the Kitchen Screen — you do it from your store catalogue by toggling a product's stock status. Because the diner menu only ever shows in-stock items, marking the last portion of a dish out of stock removes it from every phone instantly, with no risk of taking an order you can't fulfil. This is the cleanest way to run "86'd" items during a busy night.

Let the system do the customer intelligence — your job is just to run the kitchen. Every order you advance quietly stitches that diner into your CRM: their order, their spend, their phone if they gave one, and the channel they arrived through. You never type a customer record by hand. Over time this builds the "regular who always orders the latte at 8pm" profile that powers loyalty and re-marketing — all as a free byproduct of working the Kitchen Screen normally.

Do I need to refresh the Kitchen Screen to see new orders? No. The screen polls the server automatically about every 7 seconds and re-paints the lanes on its own, so a freshly placed order simply appears in the New lane without anyone touching the tablet. The green pulsing "Live" dot at the top right confirms it's connected. You only ever reload manually if the device lost its network connection.

Can two staff members use the Kitchen Screen at the same time? Yes — open it on as many devices as you like (a tablet at the pass, a screen on the line, a phone in someone's hand). Every device shows the same live board and each advance is a single safe write, so two people tapping won't corrupt an order. They'll just both see the card move on their next refresh. This is how a bigger kitchen splits the board across stations.

What happens to an order after I mark it served or completed? It immediately drops off the Kitchen Screen — the board only shows orders still in the kitchen, so finished work never clutters it. The order itself isn't deleted; it lives on in your order history and the customer's CRM record, and its table session is closed so the table reads as free again. If you marked it served, the diner's phone shows "Enjoy your meal!"; completed shows the order is done.

Can a customer change a wrong price or order from a hacked phone? No. ScaanMe never trusts the totals the phone sends — when an order is placed, the server re-prices every single line from your own database and ignores whatever the device claimed. Any item that has gone out of stock is silently dropped, and an order with nothing valid left is refused. So the total on the Kitchen Screen is always the real, database-true amount.

Do diners pay through the app? No — ScaanMe v1 takes no online payment for table orders. The diner chooses how they'll pay in person (Cash, Pay at counter, or Pay at table) and the order screen states clearly that prices are confirmed by the kitchen and paid in person. This keeps things simple and trustworthy, and means you never lose a gateway fee on a dine-in order. Card payment at the table can be added later without changing this flow.

Should I choose Café OS or Restaurant OS for my venue? Pick Restaurant if guests sit at tables and you serve them there — you'll get dine-in sessions, coursing and full modifiers, and the QR section labelled "Tables & QR." Pick Café if customers order at a counter, wait, and collect — you'll get counter/pickup and order-ahead, simpler modifiers, dine-in turned off, and the QR section labelled "Pickup QR." The Kitchen Screen is identical either way, and you can switch types later as long as your plan entitles you to the one you want.

The kitchen and ordering pages show "not found" — what's wrong? That gate appears when your store type isn't set to Restaurant or Café, or your plan doesn't carry the matching OS entitlement (restaurant_os / cafe_os). Set the store type from your Stores list and confirm your plan includes the OS add-on. Important: even while the gate is up, customer capture still works — a table scan is recorded into your CRM regardless. Only the ordering and kitchen surfaces are hidden, never your data.

Modifiers let a dish carry choices and add-ons — "Size: Regular / Large", "Milk: Whole / Oat", "Extras: +Cheese, +Bacon", "Spice: Mild / Hot". They're part of the Business OS capability set: Restaurant OS enables full modifier groups (multiple groups per item, required or optional, single- or multi-select), while Cafe OS keeps the same idea but simpler — well-suited to a few quick options on a drink. A plain Shop has no modifiers at all. Which depth you get follows your store's OS type, not a separate switch.

On the customer's menu, a dish that carries options shows a small "Customizable" cue so guests know to tap in and choose before adding to the cart, and their selections ride along with the order line into the kitchen. Practical tip: keep modifier groups short and clearly named — guests order faster, and the kitchen reads tickets at a glance. Reserve required groups ("choose a size") for genuinely necessary decisions so you don't slow the order down.

Coursing is the ability to group a dine-in order into courses — starters first, then mains, then dessert — so the kitchen fires and serves them in the right order instead of dumping a whole table's food out at once. It's a Restaurant OS capability and is on for restaurants only; Cafe mode, built around counter and pickup, doesn't use coursing. It's the difference between a proper sit-down service and a grab-and-go counter.

Because coursing rides on the dine-in flow, it pairs naturally with table sessions and the Kitchen Screen: each course advances through the same Received → Preparing → Ready → Served lifecycle, just grouped. If your venue serves guests at tables, choose Restaurant as your store type to unlock coursing; if you picked Cafe and find you need it, switch the store type (your plan must entitle Restaurant) — nothing else is rebuilt.

Finished orders never vanish. Once you mark an order served or completed, it drops off the live Kitchen Screen but lives on in your store's order history — the Orders page under that store — and in the customer's CRM record. There you can reopen any past order, read its lines and totals, update its order or payment status, and pull up its invoice, which you can print or download as a PDF for your books.

This is also where the money side closes out: because table orders are paid in person, you mark an order's payment status (e.g. paid) here once you've collected. So the same Orders surface is both your history for reference and your reconciliation tool at the end of service — one place that ties each kitchen ticket back to a receipt and a paying customer.

Order-ahead is a Cafe-mode capability: it's tuned for customers who order before they arrive or while they wait, then collect at the counter — the natural rhythm of a café rather than a sit-down restaurant. It rides on the same counter/pickup fulfilment that Cafe OS turns on (dine-in is off in Cafe mode), so a customer can place a pickup order from your menu and you prepare it for collection.

Order-ahead is one of the capabilities that distinguishes Cafe from Restaurant: Restaurant centres on dine-in table sessions and coursing, while Cafe centres on counter, pickup and order-ahead with simpler modifiers. Pick the OS type that matches how guests actually receive their food — and remember the prep-time ETAs (and optional kitchen-load) you set in Restaurant OS — Setup drive the "ready by" promise customers see when they order ahead.