Kitchen display system that keeps the pass moving

Ramlyon's kitchen display system turns managed restaurant orders into a clear live board for the team preparing them. Pending, Preparing and Ready tickets sit in distinct columns, the important item choices remain on the card, and one touch advances work to the next stage. It is part of the Operations plan and uses the same order data as the POS and web ordering flow.

A live board designed for kitchen work

The kitchen route is a dedicated screen rather than a small dashboard widget. It presents active tickets as large, status-coloured cards in a kanban layout. The team can see the human-readable order code, elapsed time, customer or table context, quantities, item names, selected variants, add-ons and the notes carried by the order.

The three active columns make the queue readable at a glance. Pending holds orders that still need confirmation when the restaurant enables that step. Preparing is the current kitchen work. Ready shows what can leave the pass. Completed and cancelled orders remain available in their own order views without cluttering the active board.

Cards and controls are sized for a busy touch screen. One action advances a valid ticket; other order pages provide the fuller editing, step-back and cancellation tools to staff who have those permissions. The display does not require kitchen staff to navigate reports, billing or settings to move service forward.

Orders arrive without a refresh ritual

Real web orders and POS orders enter the same managed order model. After an accepted write commits, the database emits a change signal, one server-side listener resolves the updated order, and the application fans it out to open screens for that restaurant. The kitchen does not need to refresh the page or wait for a timer that queries the database every few seconds.

A newly seen order can produce an in-app chime and toast on an open staff screen. Updates from a cashier, waiter or another kitchen device converge into the same board. If a connection is interrupted, the client reconnects and can catch up from its last cursor; if the gap is too large for a safe partial replay, it requests a full domain refresh.

This is live in-app delivery, not an operating-system push notification. The relevant Ramlyon screen must be open for the live connection and sound alert.

A status flow protected from stale devices

The shared order state progresses through Pending, Preparing, Ready and Done, with Cancelled as a final alternative. The server accepts only valid transitions from the state it currently holds. Repeating the same state is harmless, while a stale instruction that is no longer valid is ignored rather than corrupting the ticket. Done and Cancelled are terminal.

Each significant transition has its own timestamp. That gives the analytics layer real inputs for time to accept, preparation time, waiting time and total completion time. Because order records snapshot item and price facts, a later menu edit does not rewrite the ticket that the kitchen handled.

Order changes are granular. A status update, item edit and details change are separate intentions. If a waiter advances a status while another authorised user changes a different part of the order, the system applies those aspects independently and recalculates derived money on the server. It does not replace the whole order with whichever device happened to write last.

Built on the dashboard's offline foundation

Orders are a full offline domain in the Ramlyon dashboard. Supported creates, item edits, detail changes and status actions can queue on a disconnected device and replay when connectivity returns. The interface keeps local data available, shows connection state, and reconciles against the server result after replay.

Live fan-out naturally pauses while there is no connection; it resumes and catches up after reconnect. Offline work does not bypass permissions, plan access, read-only state, status rules or server pricing. A rejected replay is rolled back visibly instead of disappearing silently.

Give the kitchen only the access it needs

The kitchen display is an Operations feature. Ramlyon includes built-in restaurant roles and also supports custom roles assembled from granular permissions. A chef can be given access to the kitchen and order-status work without receiving prices, analytics, billing or settings. Capability, plan entitlement and account writability are all enforced on the server, not just hidden in the interface.

Operations also includes the connected POS, real web orders, order pages and advanced analytics. The Menu plan retains the QR menu and WhatsApp hand-off without the managed kitchen board. Compare the two on the pricing page.

Kitchen display questions

Which statuses appear on the live kitchen board?

The active board is organised around Pending, Preparing and Ready. Done and Cancelled remain available in their dedicated order views.

Do new orders appear without refreshing the page?

Yes. Accepted POS and real web orders are pushed to open authorised staff screens through the restaurant's live connection.

Can a chef be limited to kitchen work?

Yes. Role permissions can allow the kitchen and required order actions without granting reports, billing or settings.

What happens when the kitchen connection drops?

The dashboard reconnects and catches up or fully resynchronises as needed. Supported offline actions queue for replay, while server rules remain authoritative.

Put one shared order queue in front of the team

Create a Ramlyon account and explore the Operations plan to connect the public menu, POS, orders and kitchen display.