Skip to content

Point of sale — overview

The point of sale — POS for short — is the spine of front-of-house. It’s not one screen; it’s four, and they run together as one nervous system. The server picks the items at the terminal, the line sees them appear on the kitchen display, the host watches tables flip colours on the floor plan, the cashier reads the running take on the cashier dashboard. Four surfaces, one ticket underneath. When the server taps Send, the kitchen sees the fan-out before the tablet has finished animating; when the line marks a course Ready, the server’s cart turns green a heartbeat later. The point of having four surfaces is that each one shows a different slice of the same truth and gets out of the way the rest of the time.

This page is the entry into that whole world. The owner who’s never seen the system reads “Why this page exists” to understand what they’re buying. The manager about to put the system on the floor reads “The four surfaces” and “The state machine”. The chef and the head server skip the rest and go straight to the page for their tool — the terminal, the kitchen display, the floor plan, the cashier dashboard.

Why this page exists

Service is loud, fast, and unforgiving. The notebook in the apron pocket loses tickets. The shouted order across the pass gets mis-heard. The bill written by hand at the end of a long meal has the wine pour the table forgot to ask about, the dessert that got 86’d half-way through, the customer who switched seats. Every one of those everyday frictions costs a few seconds, and a few seconds across a hundred tables on a Saturday night is the difference between a calm shift and a crisis.

The POS replaces every loose thread with one shared object — the order. The server types the order on the terminal; the line sees it on their screen one second later; the host sees the table go red on the floor plan; the cashier sees the till go up. Nobody copies anything anywhere. Nobody re-types. The order is the truth, and the four surfaces are just different windows onto it.

The other reason the POS exists is that the pantry needs to know the dish left the kitchen. The same chain that powers the receipt also walks the recipe for every plate sent and subtracts the ingredients from stock. Without that, you’ve got a beautiful order screen sitting on top of a kitchen running blind — the till sells a margherita, nobody tells the pantry the dough and mozzarella are gone, the morning order is a guess, and the food-cost report at the end of the week is fiction.

The rule

One order, four windows. The server, the line, the host, and the cashier all read and write the same ticket — they never copy it. If the same fact is showing differently on two surfaces, that’s a sync glitch, not two truths; reload, don’t reconcile by hand.

The four surfaces

Four screens, each one optimised for the person staring at it.

The terminal. The order-taking screen the server lives on. It’s a big grid of menu tiles on the left, the running ticket on the right, a payment pad behind a button. The server taps items, the ticket fills up, the totals move on every tap. The terminal handles every channel — dine-in, takeaway, delivery, kiosk, online — though only dine-in and takeaway are switched in-place from inside the terminal; the rest arrive from other surfaces and stay read-only on their channel chip. The full walkthrough is on the terminal page.

The cashier dashboard. The till’s situational awareness. One cashier per shift opens the till with a starting cash float, and from that moment everything that gets rung up rolls into this dashboard — today’s revenue, expected cash, open tables waiting to settle, average ticket, the breakdown by payment method (cash, card, mobile transfer, on-account), the running tally of tips and discounts and service charge. At the end of the shift the cashier counts the drawer, types the count, and the dashboard shows the variance. See the cashier dashboard page for the open/close-shift flow.

The kitchen display. The screen above the line. Tickets land here the instant the server taps Send on the terminal. Each station — the hot line, the cold prep, the bar, the pass — gets its own filtered view: pizzas don’t land on the bar’s screen, cocktails don’t land on the hot line. Line cooks tap once to mark an item Cooking, tap again for Ready, and the server sees the colour change in the cart pane. The kitchen display page walks through state transitions, audio alerts, and the per-station font and layout settings.

The floor plan. The dining room as a map. Every table sits where it actually sits — terrace, main room, mezzanine — and each one is coloured by what’s happening on it: green if available, amber if occupied, blue if reserved, yellow if just settled and waiting to be cleaned. Tapping an available table opens a new ticket; tapping a busy table jumps straight into that ticket’s terminal view. The floor plan page covers the live mode the host uses during service and the design mode the manager uses once to lay out the room.

The state machine

Every ticket walks the same three steps, and the four surfaces all read the same state to decide what to show.

Open. The server has started the ticket but nothing’s been sent to the kitchen yet. New items added to the cart sit in an amber NEW group with Edit and Remove controls — they’re disposable until they cross the bridge to the kitchen. The terminal is the only surface that does anything with an open ticket; the kitchen display doesn’t know about it yet, and the floor plan shows the table as occupied but with no item count.

Sent. The server has tapped Send. The items move from the amber NEW group into a green SENT TO KITCHEN group in the cart, each one tagged with a tiny status badge — Queued, Cooking, Ready, Served — that mirrors the kitchen display in real time. The kitchen display now has one ticket card per station, holding only that station’s slice of the order. Adding more items afterwards (the customer wants one more glass of wine) and tapping Send again creates a second ticket — the kitchen sees it as an addition and the server’s previously-sent items stay marked Sent with their kitchen badges unchanged.

Settled. The customer’s paid. The cashier tapped Pay, picked a method (cash, card, mobile transfer, on-account), confirmed. The ticket’s payment status flips to paid, and the inventory deduction fires: the system walks each line’s recipe and subtracts ingredients from the pantry. Tapping Close then frees the table — green again on the floor plan — and the dashboard’s revenue and order count tick up.

What none of these steps does is leave anyone copying numbers. The handoff from the terminal to the kitchen, from the kitchen to the floor plan, from the floor plan to the dashboard — all of it is the same ticket reading slightly different parts of itself.

How the surfaces fan out

The most consequential thing the POS does on every Send is fan one order out to several kitchen tickets. A table-seven order with a margherita, a caprese, a Negroni, and a glass of Chianti doesn’t land on one big screen as one big card. It splits four ways by station. The hot line sees margherita. The cold prep sees caprese. The bar sees Negroni and Chianti, one glass. None of the stations sees what the others got. Each one cooks or pours its slice, taps Ready, and the pass — or the server, glancing at the cart — sees all four green and knows the table is ready to be plated and brought out together.

This is why the POS menu catalogue carries a station tag on every item. Without it, the system has no way to decide whether the Negroni belongs on the hot line or the bar. The catalogue is the one place where the routing rule lives, and the moment an item is created without its station, sends start landing on the wrong screen and the line shouts.

The same fan-out runs the other way too: when the line marks the margherita Cooking, the server sees the badge change on the cart a second later. When the cold-prep cook hits Ready on the caprese, the green badge appears in the server’s cart even though they were on a different table. The kitchen and the floor are looking at the same ticket from opposite sides.

How orders deduct from stock

When payment is recorded and the ticket settles, the system walks every line on the order, looks up the menu item’s linked recipe, and subtracts the recipe’s ingredients from the pantry — pasta, mozzarella, tomato, whatever the recipe says. A dish without a recipe is invisible to this cascade: the till still rings the sale, the customer still pays, the kitchen still cooks — but the pantry’s count doesn’t move and the food-cost report for the week has a hole where that dish should have been.

This is the single load-bearing reason the recipe on every POS menu item is non-optional in practice. Pricing without a recipe works. Selling without a recipe works. Knowing what tonight cost you in flour — that only works when every dish on the till has a recipe behind it.

Worked example — a Friday dinner rush

Friday, 8:15 PM. Three tables, two takeaways, one cancellation, all live on the same shift.

Table 4 — a deuce. The host taps a green table on the floor plan, the Open Table dialog asks how many guests, enters 2, taps Open. The terminal opens on the new ticket. The guests order an antipasto misto to share, two tagliatelle al ragù, a half-litre of house red. The server taps, taps, taps, hits Send. Three kitchen tickets fan out: cold prep gets antipasto misto, hot line gets tagliatelle al ragù × 2, bar gets house red 0.5 L. The cart shows everything in the green SENT group, each line tagged Queued. Subtotal €52.

Table 6 — a four-top, mid-meal. The server adds a bottle of Chianti to the cart, picks the modifier to be opened tableside, taps Send again. A small second ticket lands on the bar’s display: “Chianti, bottle, tableside”. The previously sent items stay green, their kitchen badges unchanged.

Takeaway A — counter. The cashier taps + Quick Service (Takeaway) on the landing view; a new takeaway ticket opens with no table. Two pizzas to go — margherita, capricciosa — tap, tap, Send. The customer waits. Two minutes later both pizzas show Ready on the cart. The cashier taps Pay, picks Cash, types the Cash received (€22 on a €19.40 ticket), the dialog shows the change due, confirm. The pantry deducts the recipes — 250 g pizza dough × 2, 80 g mozzarella × 2, 60 g tomato × 2, plus the capricciosa’s olives, mushrooms, ham, and artichoke. The receipt prints, the cashier taps Close Order, the dashboard’s revenue ticks up €19.40, the order count ticks to 47.

Takeaway B — online. A diner placed an order twenty minutes ago; the operator confirmed it from the inbox. It’s already in the open-orders list under the Takeaway mode of the landing view. The cashier taps it, glances at the items — spaghetti al pomodoro, tiramisù — and taps Send. The channel chip reads online and the Change order type affordance is greyed out (only dine-in and takeaway swap in-terminal; the others are sticky to their channel).

The cancellation — table 3. Two guests changed their mind, nothing had been sent yet. The server opens table 3’s terminal, taps the ⋮ Actions menu, picks Discard, confirms. The order is cancelled with reason Empty order discarded from POS; the table flips green on the floor plan; the host can re-seat.

Through all of it, the cashier dashboard is reading the same shift session: every paid order rolls into today’s revenue, every open table is listed in the Open Tables strip, the Close Shift button stays disabled while any ticket is unpaid. At 11:30 PM the last table settles. The cashier taps Close Shift, counts the drawer, types the count; the dashboard shows a variance of −€2 (close enough to dismiss), and the shift moves into the Recent Shifts list.

One shift, four surfaces, dozens of tickets, one ledger. No paper, no shouting, no transcription.