Bump
Tap a ticket "ready". It leaves the kitchen screen, lands on the runner pickup screen, and the customer-facing display updates. The line cooks see the next ticket move up to the top of the column.
Kitchen Display Screen
Run the kitchen queue on a colour, not a hand-written docket
A native Android kitchen display that routes every ticket to the right station, colours it by elapsed time, fires courses in order and lets the chef mark an item sold out to every channel from the kitchen wall. The expo screen shows the bottleneck before the runner does.
Kitchen queue · Friday 7:32pm · 12 open tickets
88 Customs Street West, Auckland7:21Delivery
via DoorDash
- 2Entrée Napolitana
Potato Gnocchi
- 1Antipasto
- 1Tiramisu
Jane Appleseed5:21Walk-in
via Walk-in
- 1Cappuccino
- 1Banana Bread
15 Karangahape Road, Auckland12:32Delivery
via Uber Eats
- 2Entrée Meatballs
Spaghetti
- 2Kids Margherita
- 1Large Quarter
- 1/4 Verona
- 1/4 Mushroom
- 1/4 Capricciosa
- 1/4 Greek
- 1Chocolate Mousse
What the kitchen sees
Four numbers worth memorising
Every ticket inherits these four guarantees the moment it lands. The kitchen runs on this discipline; the expediter just reads the colours.
30s
paper docket fallback
If the device is unreachable for more than 30 seconds, the same kitchen ticket prints to the thermal docket. The kitchen never stops cooking.
3
marketplaces on one view
Every supported marketplace lands on the same kitchen screen as direct, dine-in and counter, with the order channel kept on the ticket.
3
colour states per ticket
Green within target, yellow approaching, red over. Configurable per station. A wood-fired pizza is not held to the same threshold as a salad.
1
order history per recall
Every recall, remake and sold-out marker is logged with a reason so Sunday morning, the manager can read what happened, not guess.
On the wall, on the line
Four views. One screen. The whole kitchen runs on this device.
The same Android tablet bolted to the kitchen wall handles every station, every batched delivery, every bump and every menu change. Pick a view or just watch — it walks through all four on its own.
Four columns, four service modes, every ticket coloured by elapsed time. The chef reads the wall the same way every night.
NONext Order
1234
Romilda Vane15:49Pickup
via Direct
- 2Main Seafood
Penne
- 2Large Vegetarian
- 1Large Prosciutto
- Add Cheddar Cheese
- Remove Tomato
- 1Medium Half/Half
- 1/2 Hawaiian
- 1/2 Hot Pepperoni
- 1Garlic Bread
- 1Nutella Pizza
15 Karangahape Road, Auckland12:32Delivery
via Uber Eats
- 2Entrée Meatballs
Spaghetti
- 2Kids Margherita
- 1Large Quarter
- 1/4 Verona
- 1/4 Mushroom
- 1/4 Capricciosa
- 1/4 Greek
- 1Chocolate Mousse
142 Ponsonby Rd6:49Delivery
142 Ponsonby Rd2:11Delivery
88 Customs St8:21Delivery
88 Customs Street West, Auckland · 2/2
via DoorDash
- 1Main Arrabita
- 2Focaccia Garlic & Herb
- 1Pescatore
Fettuccine
- 1Salmone
Gnocchi
Oliver Wood4:25Pickup
via Direct
- 3Entrée Lasagne
- Add Cheese
- 1Small Terra Rossa
- 1Large Prosciutto
- Add Cheddar Cheese
- Remove Tomato
- 1Medium Half/Half
- 1/2 Hawaiian
- 1/2 Hot Pepperoni
- 1Pomodora
- 1Pescatore
A real Friday at 7:32pm
The KDS is at its most useful when the kitchen is deep. Here is what the screen does when the queue stacks up.
Worked example. Friday 7:32pm through the KDS
Twelve open tickets across four stations. Pizza T-007 is 11:42 old and pulsing red.
The expediter sees the red chip at the top of the pizza column without reading the screen. Colour does the work, not text. They tap T-007 ready as soon as the cook bumps it; the ticket leaves the kitchen screen, the runner pickup screen turns green for that ticket, and the customer-facing display reads "order 24. Ready". The manager reads one screen, one colour, one tap. The chef did not have to read out the order number; the runner did not have to ask.
Every order channel lands on the same kitchen view
Counter, phone, dine-in, your branded ordering site, your app, QR / table, kiosk and every marketplace. All into one queue with the order channel kept on the ticket. The kitchen does not need a different process for each channel.
Counter and phone
The POS finalises, the kitchen sees the ticket. No paper docket walked across the room, no typed phone-order pad to reread.
Dine-in
Table number and seat on the ticket. Servers stop walking back to the kitchen to check whether mains have fired.
Direct online and branded app
Pickup and delivery promise times come on the ticket. Your commission-free orders are operationally indistinguishable from counter orders.
QR and self-order kiosk
Tableside and kiosk orders fire to the kitchen the moment payment confirms. No re-keying at the POS before the cook starts.
Marketplace
Every supported marketplace lands on the same screen with the order channel kept on the ticket. The kitchen knows which packaging the order needs.
Scheduled pre-orders
Tomorrow lunch, Friday family-pack. Held until the prep window the customer chose. The kitchen does not fire next-week orders tonight.
Every ticket carries its order channel. Counter Pickup is not the same as Uber Eats Pickup, and the kitchen needs to see which is which without thinking about it.
The kitchen sees the actual build, not the menu name
Every modifier, every removal, every extra, every half. The cook does not have to remember “no onion” or “extra cheese”. It is on the ticket in the kitchen’s language, not the customer’s.
Size and variant
Small, large, family, catering. On the line, not buried in a code. Wrong-portion remakes stop happening.
Modifier groups
Sauce, base, finish, cooking style. Selected as the customer ordered them, displayed as the kitchen reads them.
Nested options
A pizza with half-toppings, a stuffed crust and a side of garlic dip resolves into the lines the cook needs, not a single "Custom Pizza" string.
No-this
No onion, no cheese, no sauce as explicit kitchen instructions. Allergy and preference removals are the build, not optional notes.
Extra-this
Extra cheese, double bacon, two of the same modifier. Visible with quantity. Paid extras land on the plate.
Allergy flag
Captured by the customer, surfaced on the ticket card with a colour and an icon. The chef sees it at the same glance they read the item name.
Item-specific note
"No salt on the chips for table 12" stays attached to the chips, not the order. Multi-item tables get clean per-item notes.
Customer name
On pickup and delivery tickets, so the counter and the driver have a name to match against, not just a number.
Worked example. Half Margherita / half Capricciosa, Friday 7:18pm
The pizza station sees the actual halves, not a paragraph of notes.
The customer ordered a large half-Margherita / half-Capricciosa with no olives on the Capricciosa side and extra mozzarella across the whole pizza. The pizza station sees the ticket as: large pizza, half 1: Margherita base + extra mozzarella, half 2: Capricciosa, no olives + extra mozzarella. The two halves are visually separated on the card; the toppings stay on the correct half. The base "extra mozzarella" applies across the whole pizza because that is how the customer ordered it. No kitchen note. No phone call back to the POS. The cook builds it the way the customer asked.
Combos and specials decompose into the actual items the kitchen builds. A "Family Friday Deal" reaches the kitchen as a 14-inch Margherita, a 14-inch Pepperoni, two garlic breads and a 1.25L drink. Not as a single "Family Friday Deal" string the cook has to look up.
How the kitchen reads the screen
One screen for the chaos. Two rules to read it.
Every ticket lands on the right station automatically, then ages itself by colour. The expediter does not have to read the queue. They read the chips.
Station routing
The cook at the pizza oven only sees pizza
Pizzas hit the pizza screen. Grill items hit the grill screen. Drinks hit the bar screen. Salads and cold prep hit the salad screen. Routing is configured at item level in admin. Set it once, and the kitchen sees it forever after.
- Multi-station orders fire in parallel. The steak, the salad and two cocktails all start the moment the order lands
- Items that need two stations (a salad with a hot protein) appear on both, each with only the lines that station owns
- No scribbling on a paper docket. No shouted clarifications across the line.
15 Karangahape Road, Auckland12:32Delivery
via Uber Eats
- 2Entrée Meatballs
Spaghetti
- 2Kids Margherita
- 1Large Quarter
- 1/4 Verona
- 1/4 Mushroom
- 1/4 Capricciosa
- 1/4 Greek
- 1Chocolate Mousse
Elapsed-time colour
Run the kitchen on a colour, not a clock
Green, yellow, red. The only at-a-glance metric the manager needs to read. By the time three tickets are red on one station, the expediter reroutes a hand or pulls an order off pickup before the customer notices.
- Within target — the expo screen barely shows these
- Approaching target — worth a glance from the expediter
- Over target — the chip pulses, the bottleneck shows before the runner asks
- Thresholds configurable per station so colours mean what they mean for your kitchen
Romilda Vane15:49Pickup
via Direct
- 1Large Prosciutto
- 2Large Vegetarian
88 Customs Street West, Auckland7:21Delivery
via DoorDash
- 2Entrée Napolitana
Potato Gnocchi
- 1Antipasto
Oliver Wood2:25Pickup
via Direct
- 3Entrée Lasagne
- 1Small Terra Rossa
Coursing for dine-in
Tables, courses and pacing all run from the same record. First course fires when the floor seats the table. Mains hold off the kitchen screens until the floor taps it. Mains do not arrive while entrées are still on the table.
Worked example. Saturday 8:15pm, four-top on table 9
Starters, mains, dessert. Three fires. Zero served too early.
The host seats table 9 at 8:15pm. Two starters and a shared bread board fire to the cold-prep screen within five seconds of the order landing. The kitchen knows starters before the runner walks. The mains (a steak medium for seat 2, a steak well-done for seat 4, two pastas) sit greyed-out on the grill and pasta screens, visible but not in the active queue. At 8:38pm, the floor taps "ready for mains" on table 9 from the floor map; the four mains move to the active queue at the top of grill and pasta. At 9:14pm, the floor taps "ready for dessert"; two desserts land on the cold-prep screen with the seat numbers attached. Three deliberate fires from the floor, three on-time courses, no plates sitting under a heat lamp.
- First course fires automatically when the floor seats the table. Appetisers and shared plates land on the salad and cold-prep screens within seconds of seating
- Mains and desserts hold off all kitchen screens until the floor taps "ready for mains" or "ready for dessert" on the floor map. Held tickets stay visible but greyed out, so the chef knows what is coming without it competing for screen real estate
- Each course is colour-coded so a server scanning the runner pickup screen knows whether the table is on entrées, mains or dessert
- Seat numbers travel on the line items. A steak medium for seat 2 and a steak well-done for seat 4 land on the runner pickup screen tagged to the right place at the table
- Split-check continuity. The kitchen ticket stays whole even when the bill splits four ways at the POS, so the cook never sees a half-cooked order from a half-cooked transaction
The bump that runs on muscle memory
Every kitchen interaction is two taps. Press the line, the row turns green, the row fades to a green tick, the ticket clears. The runner pickup screen and the customer-facing display update the same second.
Bump a single line
Press a line to bump just that item
15 Karangahape Road, Auckland12:32Delivery
- 2Entrée Meatballs
Spaghetti
- 2Kids Margherita
- 1Large Quarter
- 1/4 Verona
- 1/4 Mushroom
- 1/4 Capricciosa
- 1/4 Greek
- 1Chocolate Mousse
Bump, recall, remake
Four real interactions the kitchen does on the screen every service. Each one is logged so the order history has a complete record. Useful for refunds, for staff coaching and for the rare angry customer who turns up the next day.
Recall
A bumped ticket can be pulled back up for reference with a manager PIN if a runner returns it (wrong build, dropped plate, customer change), so the kitchen can reread the original build and reprint it. The recall is logged in the order history with a reason. To redo it, fire a fresh ticket with Remake.
Remake
A fresh ticket clones the original with a recall reason and resets the colour timer to green. The kitchen does not have to reread the build, and the cost lands on the Voided/Refunds report.
Reprint
Any ticket can be sent to the thermal printer as a paper backup. Useful when the chef is mid-flour and tapping a screen costs ten seconds, or when a runner wants something they can scribble on.
Mark sold out from the kitchen, not from the back office
The chef knows when stock runs out. Marking it sold out should be just as quick. One tap on the kitchen screen and it updates everywhere in real time: the POS hides it, the branded site hides it and every marketplace hides it within seconds. No juggling order tablets, no logging into the admin panel mid-service.
Worked example. Chef marks salmon sold out at 7:32pm from the expo screen
One tap from the kitchen screen. Every channel updates before the next ticket lands.
The chef taps the salmon line on the kitchen screen and selects "Mark sold out". The POS hides salmon, the branded site hides salmon, the branded app hides salmon, and the Uber Eats / connected marketplace menus hide salmon (direct integrations propagate immediately; marketplaces that batch updates take a minute or two on their end). No customer orders salmon at 7:33pm that the kitchen has to refund at 7:45pm. The city store stops selling salmon; the suburban store keeps selling it because sold-outs are store-aware.
NONext Order
1234
Settings
Sold out
2 currently sold out
Search items⌘K
Mark sold out until
1 hourServiceAll dayManual
- Traditional Pizza4 items
- Margherita · Large
- Pepperoni · Large1h
- Hawaiian Half/Half · Medium
- Quattro Formaggi · Large
- Pasta3 items
- Carbonara · SpaghettiService
- Salmone · Gnocchi
- Pescatore · Fettuccine
- Entrée9 items
- Desserts5 items
- Drinks18 items
The settings panel pulls forward from the kitchen display — same tablet, same login, no second device. Toggle a category off and every screen on every wall updates without anyone in the back office.
Prep times the customer sees
The KDS measures how long each station takes on real tickets. The customer-facing quote times use those measured times. A realistic ETA, not the menu-claim time that ages badly when the queue is deep. The kitchen has levers, not just a screen.
Bump-out time per station per shift
The KDS measures how long each station takes on real tickets. The real Friday-night pizza time, not the menu-claim time. The number updates every shift.
Customer-facing quote times use measured times
The branded site, branded app and marketplaces show ETAs based on what the kitchen is doing right now. A customer ordering at 7:32pm gets a realistic ETA, not an optimistic one that ages badly when the queue is deep.
Order Value Time Adjustment
A 12-pizza family order does not get the same eight-minute promise as a single calzone. Larger orders quote longer prep automatically. The customer expects it, the kitchen is not surprised by it.
Capacity controls when the queue stacks up
Pickup window throttling
When the KDS queue crosses the threshold you set, online pickup windows tighten automatically. The customer sees a 25-minute promise instead of a 12-minute one. The kitchen does not get sent into a hole.
Buffer time around close
Online ordering closes a configurable number of minutes before the kitchen does. Staff close on time; customers do not arrive at 9:55pm with a 20-minute order.
Manual rush priority
A late courier is at the door, a complaint is at the counter. The manager taps a ticket to push it above sequence without losing the rest of the queue.
The expediter view
The same Android tablet the kitchen display uses, in expediter mode. Aggregate ticket counts, median ages, oldest open ticket and station-load distribution. All surfaced at the top so the bottleneck is one glance away.
- Aggregate ticket counts and median ages per station, refreshing every few seconds
- Oldest open ticket pinned to the top so the bottleneck is one glance away
- Station-load distribution. See when grill is at 6 and salad is at 1 before the runner does
- One-tap station rerouting if a station goes long and another is empty
- Expediter view runs on the same Android tablet as the kitchen display. Flip into expediter mode without changing devices
Worked example. Friday 7:36pm, the grill is at 4
Aggregate strip catches the bottleneck before the runner does.
Open tickets 12, median age 6:24, oldest T-007 at 11:42, Grill 4 / Pizza 5 / Salad 2 / Drinks 1. The expediter reroutes the next two pizza tickets to the cold station before the runner notices it sitting waiting.
NONext Order
1234
Open tickets
12
Median age
06:24
Oldest
T-007 · 11:42
Station load
Grill 4 · Pizza 5Salad 2 · Drinks 1
Romilda Vane15:49Pickup
via Direct
- 2Main Seafood
Penne
- 2Large Vegetarian
- 1Large Prosciutto
- Add Cheddar Cheese
- Remove Tomato
- 1Medium Half/Half
- 1/2 Hawaiian
- 1/2 Hot Pepperoni
- 1Garlic Bread
- 1Nutella Pizza
15 Karangahape Road, Auckland12:32Delivery
via Uber Eats
- 2Entrée Meatballs
Spaghetti
- 2Kids Margherita
- 1Large Quarter
- 1/4 Verona
- 1/4 Mushroom
- 1/4 Capricciosa
- 1/4 Greek
- 1Chocolate Mousse
142 Ponsonby Rd6:49Delivery
142 Ponsonby Rd2:11Delivery
88 Customs St8:21Delivery
88 Customs Street West, Auckland · 2/2
via DoorDash
- 1Main Arrabita
- 2Focaccia Garlic & Herb
- 1Pescatore
Fettuccine
- 1Salmone
Gnocchi
Aggregate strip pinned to the top of the same kitchen tablet. No second device, no swap of context — flip into expediter mode and the bottleneck reads itself.
The tablet pile, retired
Stop reading four screens at the counter
Marketplace tablets multiply faster than venues can find places to bolt them. The KDS swallows them all into one queue without losing track of which order belongs to which courier.
What most counters run today
- Uber Eats tablet1 device
- DoorDash tablet1 device
- Delivereasy tablet1 device
- POS for direct + counter1 device
4 devices on the bench. 3 menu updates per change. 3 tablets to forget on a Friday.
On Next Order
- One kitchen queueall sources
- One menu updateevery aggregator
- Order channel kept on the ticketno ambiguity
- Cancellations clear the screenno waste
1 device. 1 menu update. The packer reads the source and grabs the right bag.
Marketplace tablets, retired
Every supported marketplace lands on the same kitchen screen as direct, dine-in and counter, with the order channel kept on the ticket so packaging, timing and customer expectations are obvious without a separate device per channel.
One queue, four channels kept distinct
The kitchen reads pizza-station tickets as pizza-station tickets, not as "the Uber Eats tablet" and "the marketplace tablet". The order channel on the ticket tells the packer which courier bag to use.
Cancellations clear from the kitchen
When a marketplace cancels an order before pickup, the ticket disappears from the kitchen screen. The food does not get cooked into a bin. The cancellation is logged in the order history so the manager can read the trend.
One menu update reaches every aggregator
mark the salmon sold out from the kitchen wall and the marketplaces hide salmon within their propagation window. No customer pays for an item the kitchen cannot make.
Worked example. Friday 7:08pm, eight orders in two minutes
Three marketplaces, two direct, three counter. One queue.
Between 7:08 and 7:10pm on a Friday, eight tickets arrive: one Uber Eats, one from another marketplace, one courier-driven, two direct (one app, one branded site), and three counter walk-ins. They all appear in the same kitchen queue, sorted by elapsed time, with the order channel kept on each ticket. The packer at the expo screen reads "Uber Eats Pickup" as "Uber bag, Uber receipt"; "Direct Pickup" as "branded bag, branded receipt"; "Counter" as "no bag, customer waiting". One screen. Three packaging flows. Zero tablets to read.
The customer never asks “is my order ready?”
When the chef bumps a ticket, the runner pickup screen, the customer-facing display, the SMS notification (where enabled) and the courier handoff status all update in the same second. The counter staff stop being interrupted; the customer stops asking.
Ponsonby Eats
Order pickup
Preparing
- 214
- 215
- 216
- 217
Ready to collect
- 211
- 212
- 213
We’ll text you the moment your order is ready
Customer-facing display board
Order numbers and ready statuses on a screen the customer can read from the door. The pickup queue clears itself; staff stop pointing at the back.
Ready notification on direct orders
Customers who ordered on your branded site or app get an SMS or push when the kitchen marks the order ready. They walk in, instead of leaning on the counter.
Driver handoff readiness
Marketplace and own-driver orders move from "kitchen ready" to "courier handoff" on the same screen the chef just bumped from. Drivers are not waiting on cold food; food is not waiting on a missing driver.
Dine-in service readiness
The runner pickup screen lights up the table number when the kitchen bumps the last item. Servers walk plates while they are still hot.
Kitchen reporting that finds the bottleneck
Bump-out times by station and shift, late-ticket counts, refund and remake reasons, station bottleneck patterns and busy-hour queue load. All in the same admin dashboard the manager already uses for sales and labour. Kitchen performance becomes a number, not a story.
Bump-out times by station, by shift
The pizza station’s median bump-out on a Friday is not the same as a Tuesday lunch. The KDS records both, not the menu-claim time.
Late-ticket counts and reasons
How many tickets crossed the red threshold last week, on which station, and what the manager-on-shift recorded as the cause. Trends instead of anecdotes.
Refund and remake reasons
Every recall is logged with a reason. Sunday morning, the manager sees whether the three remakes from Friday were a kitchen miss, a wrong build from the POS, or a runner mistake.
Station bottleneck patterns
When grill consistently runs hot at 7:30pm Fridays, the report says so. Move a hand, simplify a menu item, or change the routing. The data tells you which.
Worked example. Sunday morning, last Friday's pizza station
Median 11:42, fourteen reds, two remakes. Both on family-pack pizzas.
The manager opens the kitchen report on Sunday morning. The pizza station's median bump-out last Friday was 11:42. Fourteen tickets crossed the red threshold. Two remakes. Both on family-pack pizzas, both on the back-half of service when the cook was solo. The fix is not a person; it is the station coverage at 8pm. The data was already there; the manager just had to look.
When the screen freezes
A frozen tablet, a network blip or a kitchen Wi-Fi drop should not stop service. The platform handles it without anyone having to call support. And surfaces what happened in the reconciliation log so you know after the fact.
Tickets survive a crash or a dropped connection
If the tablet restarts, the app reopens and reloads the current orders, so the same tickets are back on screen. If the store loses internet, the orders already on screen stay put and still print locally, and new orders update automatically the moment the connection returns. No reboot, no one re-entering anything.
Paper docket fallback fires automatically
If the KDS device is unreachable for more than 30 seconds, the same kitchen ticket prints to the thermal docket. The kitchen never stops cooking. When the screen comes back, the queue picks up where it left off.
Printer health is monitored independently
Thermal printer response time is tracked separately from the KDS app. Managers get alerted at 11:30am when a printer is going slow, not at 12:30 when the kitchen has run out of dockets and service is already deep.
Hybrid by design. Run paper, screens, or both
KDS is flexible, not anti-printer.
Many operators run paper dockets and KDS screens together during launch week, then keep the printer for backup once the screens are doing the work. The kitchen ticket format and content are identical on both surfaces, so staff are not learning two layouts. Run paper only at the salad station and screens at the hot line if that is what your kitchen wants. The platform does not insist on paperless.
The screen on the wall
The KDS is a native Android app. Reuse the Android tablets already on your wall, or buy new where you need splash-proof or heat-rated mounting. Same operating system as the floor handheld and the kiosk.
- Native Android app. Runs on Android tablets you can buy off the shelf, including the ones already on your wall
- Splash-proof and heat-rated mounts available for hot-line and pizza-oven adjacency
- Multiple screens per station supported. A pizza station can have a bench tablet and an oven tablet, both showing the same tickets, with bump and recall mirrored across them
- Runs on a Windows touchscreen you already have, too, via a Google TV or Chromecast device plugged in over HDMI with USB for touch
- Same Android app used for the KDS, the floor handheld and the kiosk. One system to maintain across the venue
- Each store runs its own routing, station setup and screen count. A 60-seat full-service venue does not need the same kitchen layout as a quick-service shop next door
- KDS device licences managed centrally. Add a screen at one store and the licence shows up on the group dashboard, no separate billing per location
- Standardised station logic and colour meanings travel between stores, so a chef who picks up a shift at the next site reads the screen the same way
Frequently asked questions
What operators ask us before they sign.
What runs the kitchen screen. Does it have to be a special device?
The KDS is a native Android app. Any Android tablet from the last few years runs it; reuse the ones already on your wall, or buy new where you need splash-proof or heat-rated mounting. You can also run it on a Windows touchscreen you already have, using a Google TV or Chromecast device that runs Android apps, plugged in over HDMI with USB for touch. The same Android app also runs the floor handheld and the kiosk, so your team has one system to learn instead of three.
What happens if the device crashes or the network drops mid-service?
Neither stops service. If the tablet restarts, the app reopens and reloads the current orders, so the same tickets are back on screen and nothing is lost. If the store loses internet, the orders already on screen stay put and still print locally, and as soon as the connection returns any new orders update automatically, with no reboot and no one re-entering anything. As a backstop, if a screen is unreachable for more than 30 seconds the same kitchen ticket prints to the thermal docket, and printer health is monitored so a slow printer shows up as a manager alert before service notices.
Can the chef mark an item sold out from the kitchen, or does it have to come from the POS?
Chef taps the item from the kitchen screen and selects "Mark sold out". The item updates across the POS, the branded site, the branded app and every marketplace within seconds (direct channels update immediately; marketplaces that batch updates take a minute or two on their end). Sold-outs are store-aware, so the city store going off does not stop the suburban store selling.
Can we run two screens at one station?
Yes. A pizza station can have a bench tablet and an oven tablet, both showing the same tickets, with bump and recall mirrored across them. Both run the same Android app, paired to the same station ID in admin. Useful when the cook at the bench and the cook at the oven need to see the same queue without one of them turning around every twenty seconds.
Does the KDS work for venues that still want paper dockets?
Yes. You can run paper dockets only, KDS only, or both at once. Many venues run both during launch week and then keep the printer for backup once the screens are doing the work. The kitchen ticket format and content are the same on both surfaces, so staff are not learning two different layouts.
What does the kitchen see when a customer orders a half-half pizza?
The build is split visually on the ticket card. Half 1 with its base and toppings, half 2 with its base and toppings. Toppings stay attached to the half they were ordered on. Base modifiers (like "extra mozzarella across the whole pizza") apply across the whole pizza. Quarter and side-specific builds work the same way where the menu supports them. No kitchen note. No phone call back to the POS.
What happens to a marketplace order if the customer cancels before pickup?
The ticket clears from the kitchen screen automatically. The food does not get cooked into a bin. The cancellation is logged in the order history with the order channel kept on it, so the manager can read the trend. Which marketplace cancels most, on which days, and at which volumes.
Can a station screen be locked down so kitchen staff cannot accidentally edit settings?
Yes. The KDS app runs in a kitchen-only mode. Routing, thresholds and station setup live in admin behind a manager PIN; the kitchen screen only exposes ticket actions. Bump, recall, mark sold out, request a reprint. A line cook cannot accidentally reroute the grill station or change a colour threshold.
Put the KDS through your Friday
Bring your menu, your station layout and your real Friday-night ticket count. We will walk station routing, course firing, the sold-out updates and the bump-recall flow on your numbers. Tailored to your kitchen, not a generic demo.