When counter tickets, a phone order and the website each land on a different device, the kitchen quietly invents a third sequence to survive the rush — and a dish that runs out at 20:00 keeps selling online for another twenty minutes. The Menuella terminal brings every order — counter, phone, web and delivery — onto one screen at the pass, in one readable line with the detail the kitchen needs to cook, and it shrugs off short Wi-Fi drops instead of stalling. Because the terminal is a view onto the same menu that web, app and QR ordering run on, marking a dish sold out at the pass removes it from ordering across every one of those channels, typically within seconds — no second toggle to remember, no channel left selling what the kitchen can no longer make. One screen to read, one place to say "we're out."
It's 20:05 on a Friday. The lamb is gone — the last portion just left on a table order. The counter knows. The kitchen knows. But the website doesn't, so three more lamb orders arrive online in the next ten minutes, and now someone has to phone three guests to apologise. Meanwhile a tablet by the till is ringing with a delivery order nobody has looked at, and the counter is scribbling a phone order on a pad because there's nowhere else to put it.
None of this is a staffing problem. It's a screen problem. Every order channel has its own device, so the pass never reads one truth — it reads three or four, and stitches them together by hand in the middle of the rush.
One screen, every channel
The fix isn't a faster tablet. It's fewer places to look. Every order a restaurant takes — someone at the counter, a call, the website, a delivery order — is the same object: dishes, a time, a fulfilment type. There's no reason for each to live on its own device.
On the terminal, those four arrive in one line the whole pass understands, each with the detail the kitchen actually needs to cook — modifiers, notes, the fulfilment type — not a notification you have to open and decode. The counter isn't inventing a running order in their head, and nobody is reconciling a paper pad against a chirping tablet.
The comparison that decides the shift
A table says more than 500 words here. The scattered setup doesn't fail because anyone is careless — it fails because it asks a busy team to be a message router. One screen removes the routing.
The sold-out switch that actually sticks
Here's the part that quietly saves the most Friday nights. When the lamb runs out, someone at the pass marks it sold out on the terminal — one action, at the screen they're already looking at.
Because the terminal isn't a separate island — it's a view onto the same menu your website, your app and your QR menu all run on — that one action removes the dish from ordering across every one of those channels, typically within seconds. There's no second system to also update, no "did anyone change it on the website?" The pass says "we're out," and the guest ordering online a minute later simply doesn't see it.
That's the difference between a sold-out signal that's real and one that's a lie in slow motion. A dish you mark out at 20:05 stops being orderable everywhere that runs off the same source — so the kitchen isn't left cooking what it can't, and the counter is spared apologising for what the website promised.
When the Wi-Fi blinks
Restaurant Wi-Fi drops. A microwave runs, someone reboots the router, the connection stutters for fifteen seconds at exactly the wrong moment. An off-the-shelf tablet treats that as a catastrophe — the order spinner hangs, and service stalls while everyone stares at it.
The terminal is built to ride out short drops rather than fall over. Orders already at the pass stay readable, and the screen catches up when the connection returns, so a blink in the network doesn't become a gap in the service. It's not magic — it's a device designed for a kitchen, not a boardroom.
The 7 most common terminal mistakes
- A device per channel — till, phone pad and two tablets — so the pass reads three truths, not one.
- A sold-out signal that only reaches the counter, while the website keeps taking orders for it.
- Two menus to update — one for the floor, one for online — that drift apart within a week.
- Notifications instead of a queue — a chirp you have to open and decode mid-rush.
- Handwritten tickets the line cook has to interpret under a heat lamp.
- An office tablet at the pass that dies on the first Wi-Fi blink or grease splash.
- Reconciling by hand — a person whose real job, during the rush, has become message router.
Get every order onto one screen
Frequently asked questions
Do counter, phone, web and delivery orders really share one screen?+
If I mark a dish sold out at the pass, does the website stop selling it?+
What happens if the Wi-Fi drops for a few seconds?+
Is this a kitchen display or a printed ticket?+
Does one screen mean I'm locked into one way of working?+
One place to read, one place to say "we're out"
A restaurant doesn't get slower because orders are hard to cook. It gets slower because the team spends the rush being a switchboard — copying a phone order onto a pad, checking whether the website still sells a dish that's gone, deciphering a handwritten ticket. Put every order on one screen, and let that same screen be where you mark a dish sold out, and the rush gets quieter without a single extra pair of hands. The kitchen reads one line, cooks only what it can, and the guest ordering online sees the truth the pass just told.
