One screen, open the whole shift, built to be read in passing.
A new ticket, an alert that needs a person, a component just marked unavailable — none of it asks anyone to stop and study the screen before they can act. What lands here has one shape, every time, so a glance is enough.
Accepted means visible.
Not queued behind a decision.
Once a caller’s order is confirmed it does not wait for someone to approve it before staff can see it. The moment it is accepted, it lands on the screen, marked clearly as pickup, delivery, or scheduled. An order held for manager review shows up differently, in its own place, with the reason attached — never sitting indistinguishable from the tickets around it.
A changed order after acceptance does not quietly edit the original. It arrives as its own new ticket, marked plainly — replacement, do not re-charge — with the earlier version still there to check against. A mid-shift change is something staff watch happen, not something they discover afterward.
FOUR PLAIN STAGES — THE SAME FOUR THIS SCREEN ACTUALLY TRACKS · NO STAGE IMPLIES A DURATION, AND NONE IS STATED ANYWHERE ON THIS PAGE
The same five regions,
in the same five places, every time.
A ticket carries what a person actually needs in order to act on it, laid out identically on every one of them. Nothing moves around between tickets, which is what makes reading one in passing possible at all.
The payment line can also read card paid — a real state the ticket itself supports — but a phoned-in order does not produce that state, and payments covers the full, honest shape of why.
A special instruction earns its own flag because it is exactly the kind of detail that gets lost inside a line of item text. Where a caller’s instruction touches a stated allergy or dietary concern, it is not carried onto the ticket silently: the caller already heard, plainly, what a flagged instruction actually means before the order was ever confirmed — that it was heard, whether the restaurant has actually responded to it yet, and that none of it is a guarantee about ingredients, preparation, or cross-contact. The exact wording is quoted in full at allergy and ingredient questions.
By the time that instruction reaches this screen as a flag, the caller has already heard exactly what it does and does not promise. What lands here is the instruction itself, set apart from the rest of the ticket — not a claim that the kitchen has already handled it, and not a guarantee this screen makes on the kitchen’s behalf.
Acknowledging is not deciding.
Not everything that happens needs a person to stop and deal with it. What does — an order sent to manager review, a callback that has come due, a handoff request — shows up as an alert, distinct from the ordinary flow of tickets landing on the screen.
Acknowledging one clears it from view without quietly changing what it was about. Tapping past an alert about an order in manager review does not accept that order; it means somebody has seen it. The decision still happens through its own action. In the figure, the order’s own state label is identical in both frames — only the seen marker changes.
Alerts are heard and seen on purpose, and one does not stand in for the other. If sound is muted, or was never allowed on the device, the visible alert still shows. A denied permission is not the same thing as an alert nobody was told about.
See what it touches,
then confirm it.
Marking a component unavailable from this screen shows what else it touches before anything changes — every item and group that depends on it, not just the one thing tapped. What actually happens to each depends on how that relationship was configured when the menu was set up: some items become unorderable outright, others offer a substitution, some just lose an optional extra. The full 86 cascade lives on menu.
Restoring an item works the same way, just as fast. Once it is marked available again it is back on the next call, not held for a later batch update. What is marked here only touches the location being worked from — each location manages its own menu and its own availability.
The current wait, set here
The wait a caller hears comes from a number set on this screen, not a figure the system estimates on its own. A manager updates it as the kitchen actually runs — busier than usual, or ahead of schedule — and every call from that point quotes the number that is current, not whatever was set at the start of the shift.
Callers hear a configured default rather than a made-up number. The restaurant sets both — the ordinary default and the number being quoted right now — not just the one used on an ordinary day.
Nothing here asks anyone
to stop and study the screen.
A TICKET LANDS
Pickup, three items, cash due at the counter. It goes onto the screen the moment it is accepted, no different from any other order tonight, in the same five regions as every other ticket on the rail.
AN ALERT FIRES FOR A DIFFERENT ORDER
A large catering request crossed the restaurant’s own threshold and is sitting in front of a manager. A staff member taps to acknowledge it — clearing the alert without deciding anything about the order, which stays exactly where it was, still in manager review.
THE KITCHEN RUNS OUT OF A SHARED SAUCE
Someone marks it unavailable and sees, before confirming anything, exactly what that touches — two sandwiches lose an option, one dish goes dark entirely. They confirm.
THE NEXT CALLER HEARS THE HONEST VERSION
Not an outdated menu. The change is on the next call rather than in a later batch update, and the wait being quoted is whatever a manager last set on this same screen.
What staff actually ask about this screen
What if the tablet loses connection mid-shift?
The data on screen is shown as stale rather than silently current — the same honesty this screen runs on everywhere else. It does not keep displaying a list that might no longer be right.
Can staff accidentally accept an order by dismissing an alert?
No. Acknowledging and deciding are two separate actions. Dismissing the alert clears the notice; it does not touch the order’s own state.
Does marking something out of stock affect other locations?
No. What is marked here only touches the location being worked from. Each location manages its own menu and its own availability.
What happens to a ticket if the printer's down?
Nothing about the ticket on this screen depends on a physical device to exist. It is a structured record here regardless of whether a receipt device is connected — a restaurant’s own printed workflow, where it has one, runs alongside this screen rather than through it.
Do I have to keep this open on a specific device?
This page describes what the screen shows and how it behaves, not which device it runs on or where that device sits. No source backs a claim about physical placement, so none is made. What matters is that it stays open through the shift.
A screen, not a kitchen printer —
and not the person keying it in.
What it shows is an on-screen record. A restaurant’s own printed or point-of-sale workflow still happens the way it happens today.
Getting an accepted order into the restaurant’s own equipment is down to a person, not this screen — see orders for exactly where that limit sits. What changes is what that person works from: something already checked, not a blank slate.
How quickly a new ticket appears, or how quickly staff act on an alert, is not a number this page states. Nothing here borrows one from anywhere else to fill the gap.
If the connection drops, the screen says the data is stale rather than quietly continuing to show a list that might not be current anymore.
Staff still cook the food, still run the pass, and still make the judgment calls a screen cannot make for them. What changes is having one clear place to look — not who does the work.
RELATED READING
Owner console
The dashboard: tonight at a glance, analytics, menu, team, closeout.
OPEN →PLATE Nº 007Menu intelligence
Your menu with its real rules: components, modifiers, the 86 cascade, pronunciations.
OPEN →PLATE Nº 006Orders
Sizes, halves, swaps, allergies — the whole order, read back in full for a yes.
OPEN →See it running through your own rush.
Request access and watch a real ticket land on this screen — pickup, modifiers, cash due, flag and all.