LiftedPOS
Sign in Run the demo

Home/features / restaurant kitchen display

Restaurant kitchen display

A kitchen display that follows the ticket to ready.

A kitchen ticket is a changing piece of work, not a receipt pinned to a screen. LiftedPOS gives the line a station-filtered view of active work, elapsed time, order context, and the next whole-ticket state.

Run this workflow See pricing

WORKSPACE LENSSee the kitchen display. Use the current seeded Grill station proof to inspect station filtering, active whole-ticket state, source context, ready behavior, and eligible recall before service. We help shape station routing and rehearse the restaurant's representative ticket path during a scoped rollout.

Current LiftedPOS kitchen display in a seeded restaurant sandbox with station filters and active ticket states
  1. 01Create the order
  2. 02Route the station
  3. 03Advance the ticket
  4. 04Ready and recall
Two rails

Paid and pre-payment work have different terminal states and recovery behavior.

Configured stations

Menu items can be assigned to station views, with Kitchen as the fallback for anything not yet assigned.

Whole ticket

The visible control advances the ticket as a whole and the refreshed state confirms it.

01

Start with the rail the ticket is actually on

Paid-sale work follows New → In Progress → Ready → Completed. Pre-payment fires and accepted QR work follow New → In Progress → Ready → Served. They share an active board, but they do not share the same completion or recovery behavior.

02

Route each menu item to the team that owns it

Assign each menu item to the kitchen station that owns it, with a Kitchen fallback for anything not yet assigned. Confirm the station map against the real menu during rollout.

03

Bump the whole ticket, then confirm the board changed

The visible action advances the ticket as a whole. Eligible active paid-sale tickets can expose Recall before completion; pending and accepted QR tickets are forward-only on the current display. Staff verify the refreshed state instead of treating the button press as operating evidence.

04

Use attention cues to keep the line moving

Elapsed-time cues and optional sound help staff notice new work. Use the visible ticket state and the restaurant’s handoff procedure as the operating record.

05

Verify both ticket paths with your real menu

Fire one paid ticket, one pre-payment ticket, and one accepted QR order with modifiers and multiple station assignments. Confirm the fallback Kitchen route, whole-ticket bump behavior, eligible paid-ticket recall, forward-only rails, and the record left after work exits the active board.

✓

Rehearse the complete kitchen handoff before service

Create a paid sale, a pre-payment fire, and an accepted QR test order with representative modifiers and more than one configured station. Confirm each item appears on the intended view, the Kitchen fallback catches anything unassigned, the team owns the whole-ticket action, eligible recall works, and the distinct Completed and Served endings are understood.

Inspect in the live demo

Create a restaurant order, open Kitchen, select the exact station view, and verify each whole-ticket state change. Availability can depend on enabled modules, hardware, payment setup, role, location, and rollout configuration.

→

Move from the feature to the operation

This capability shares product, table or order, ticket, sale, and employee context with the restaurant workflow. Station filtering is tenant-scoped in the current product, so multi-location topology belongs in rollout acceptance.

Run the restaurant KDS operator workflow →Restaurant POS →Bar POS →Restaurant QR ordering →Online orders →Restaurant table management →Self-service ordering kiosk →Recipe inventory →

See the capability inside a working store.

Run it with safe demo data, then map the locations, roles, devices, and configuration your operation needs.

Run the workflow Plan the rollout