Kitchen Display and Order Routing
A restaurant where orders reach the kitchen on paper docket or verbally, and the ones that go missing are discovered by the waiting customer.
The problem
The kitchen has no reliable queue. Nobody can say how long a table has been waiting, which orders are late, or where a lost ticket went.
In scope
- Order intake into a kitchen queue
- Station routing
- Item-level state
- Ticket timing
- Modifications and cancellations
- Ready notification
- Throughput reporting
Out of scope
- Payments
- Stock depletion
- Recipe costing
- Delivery dispatch
- Table reservations
- This runs the pass; it does not run the till.
What this would cover
Grouped by module — open the ones you want to read.
Order intake
- From a counter or server device, or from the WhatsApp and Direct Order Capture concept, into one queue regardless of channel
Station routing
- Items directed to grill, fryer, cold section or bar, so each station sees only its own work while the expediter sees the whole ticket
Item state
- Received, preparing, ready, per item rather than per order, because a ticket is only ready when its slowest item is
Ticket timing
- Elapsed time per ticket, with escalating visual state as it ages; the threshold set by the kitchen, not by the software
Modification and cancellation
- Reaching the kitchen immediately with a reason, and visibly marked rather than quietly changed
Recall
- A completed ticket retrievable for a short period, because disputes happen minutes later
Ready notification
- To the server or counter, removing the shouting
Reporting
- Average and worst ticket time by hour and day, by item, and by station; which items slow the whole pass
Data model
- Order → OrderLine → Modifier
- Ticket → TicketItem → StateEvent
- Station
- Channel
- TimingRecord
Invariants
- State events are append-only, so a ticket's timing history survives.
- An item's state never moves backwards without an explicit recall action that is recorded.
- A modification after an item has entered preparing state is flagged rather than silently applied.
Offline behavior
Must work fully on the local network with no internet at all. A restaurant cannot stop serving because a router lost its uplink, and this is the single most important technical requirement in the concept.
Hard trade-offs
The difficult decisions, stated plainly — not trimmed for length.
A screen replaces a physical ticket that staff can hold, mark, move and stack, and some kitchens genuinely work better on paper.
Cooks with wet or occupied hands do not touch screens. In a small kitchen the honest recommendation may be a printer driven by the system rather than a display, keeping the timing and routing benefits while leaving the physical ticket in place. The design should support both, and the choice should be made after watching the kitchen work, not from a specification.
Screen placement, glare and heat are real.
A display mounted where it catches steam or sunlight will be ignored. This is a site survey question, not a software question.
End state
What would be true about their day once this is running.
- Every order reaches the kitchen the moment it is taken, with its modifiers intact.
- Each station sees its own work and the expediter sees the whole ticket.
- A late ticket is visible before the customer complains.
- The restaurant knows which items slow the pass at which hour.
This is a deliberate first step toward Restaurant Operations & Channel Control Platform — its data model is designed as a genuine subset, so growing into it later doesn't mean starting over.
Let's map how your operation actually runs.
One session. We look at what's breaking, and what we'd build around it — whether or not you hire us afterward.
Start the operations review