Getting the tablet ready

A tablet that's signed in and sitting on the counter isn't necessarily a tablet that's actually ready. This page covers what “ready” means for this specific device, the settings worth checking before day one rather than discovering mid-shift, and what a normal ticket looks like so an unusual one is easy to spot later.

01What “ready” actually means

Three things need to be true before a tablet is genuinely ready, not just powered on. It needs to be signed in to the right location, its sound and alert settings need to reflect how this specific station actually wants to be notified, and someone needs to have seen at least one real ticket arrive and look the way it's supposed to. None of the three takes long individually, but skipping any of them means the first time they're tested is during a real shift — exactly the wrong moment to discover a setting is wrong.

A location isn't limited to a single device, either. If more than one tablet is going to be in use — one physically closer to the line, another somewhere else entirely — each one goes through this exact same setup on its own. There's no single configuration that covers every device in the building at once, and skipping this for a second or third tablet just because the first one already works leaves that device untested in exactly the same way an unchecked first device would be.

02Setting it up

1. Sign in on the tablet itself, at the location this device actually belongs to — not on a phone or laptop standing in for it. The tablet is meant to be the always-open surface this device is judged by, and confirming it directly is the only way to know the physical device behaves the way the setup describes.
2. In onboarding's staff step, fill in which staff or station this device is for — a plain description like “kitchen tablet” is exactly what that field expects — and choose whether a new ticket should alert with sound or arrive silently. Sound is the right default for a device sitting somewhere staff aren't necessarily looking at continuously.
3. On the tablet itself, open its own settings and confirm sound is actually on, set the volume and screen brightness for wherever this device physically sits, and consider turning on “Keep screen awake” for a device that shouldn't dim or lock in the middle of a shift.
4. Check which alerts this specific tablet should actually receive — new orders, exceptions like allergies or replacements, handoffs, and wait-time changes are each their own toggle, and a device doesn't have to receive every category to be set up correctly. A tablet meant purely for watching new tickets come in doesn't need wait-time-change alerts cluttering it, for instance.
5. Once forwarding, the menu, and the first-call test are all confirmed, use a real or test order to see a ticket actually arrive here, with its alert firing the way you just configured it. This is the step that turns “the settings look right” into “I watched it work.”

Not every device or browser can actually honor “Keep screen awake” — some genuinely don't support it, and the tablet says so directly rather than pretending the toggle worked: turning it on where it isn't supported produces an honest message explaining the browser doesn't support keeping the screen awake, with a suggestion to disable auto-lock in the device's own settings instead. If the device supports it but the screen still dims or locks, a second, different message points at the device's own power settings rather than this toggle. Either way, the fix lives on the device itself once you know which of the two messages you're actually looking at.

03What a real ticket always shows

Every ticket that reaches this device shows the same things, in the same place, regardless of what kind of order it is: the items and modifiers exactly as confirmed with the caller, the fulfillment type and time, whether payment is settled or still due, any special instruction that was flagged, and whether this is the original ticket or a replacement for one that changed after acceptance. Knowing this fixed shape in advance is what makes it easy to notice when something about a real ticket looks different from usual.

A ticket without either of the last two markers is simply an ordinary order — their absence is itself informative, not a gap in the display. The stage only ever moves forward, one step at a time, never backward and never skipped, so a completed order can't be accidentally reopened from this screen.

Line items themselves show a quantity, the item name, and any modifiers exactly as confirmed with the caller — not a paraphrase and not a kitchen shorthand. That exactness is deliberate: whatever staff read off this screen should match, word for word, what was actually agreed to before the order was accepted, since a ticket that quietly summarized or simplified a confirmed order would undercut the entire point of confirming it carefully in the first place. The staff step in onboarding also has its own field for anything specific this station wants called out beyond what's always shown — worth filling in if this particular device serves a purpose the fields above don't fully cover, though the core set above appears on every ticket regardless of what's written there.

04When something looks wrong

• Sound is off, muted, or the device denied a sound permission. This sounds like a bigger problem than it actually is: a muted or denied sound permission never hides the visible alert itself — a new ticket still shows up on screen with its own visible indicator regardless of whether the device made a sound. Missing an audible alert is worth fixing for a device that shouldn't rely on someone staring at the screen, but it doesn't mean tickets stopped arriving; it means one signal of two stopped firing.
• The tablet shows nothing at all. Before assuming something is broken, check whether the device is actually online — a station that's lost its connection keeps showing the last data it received rather than going blank, with its own dedicated screen explaining exactly that. What still works locally while disconnected: the queue as of the last sync stays visible, advancing an order's stage or marking an item unavailable both still work and simply sync once the connection returns, and alerts for anything already queued still fire. What's stale until it reconnects: new orders placed since the last sync won't appear, a quoted wait time may not reflect a change made elsewhere, and alerts acknowledged on another device won't update here yet. A tablet actually showing nothing at all, rather than this specific offline explanation, is a different and less common problem worth treating as its own troubleshooting question rather than assumed to be the same thing.
• A ticket arrived but looks incomplete or wrong. Confirm first whether the underlying order itself is correct — checking the order on the console rather than assuming the tablet mis-displayed something it received correctly. The tablet shows exactly what it's given; an odd-looking ticket more often traces back to the order itself than to this screen.
• A ticket seems stuck on the same stage. Stage never advances on its own — someone has to tap the action button beneath a ticket for it to move from New to In progress, then to Ready, then to Completed, one step at a time. A ticket that's sat on New for a while usually just means nobody has tapped “Start order” yet, not a synchronization problem; check the button was actually pressed before assuming the device itself is at fault. There's also no way to move a ticket backward or skip a stage from this screen even if you wanted to — if a stage looks wrong because it was advanced by mistake, that's worth a note to whoever's tracking the order rather than something to try to undo here.