Station views, kitchen tickets and pickup status belong to the same POS. Kitchen views organise the work; analysis needs reliably recorded steps. One POS, the same features — in the cloud or on the venue’s box.
Explore the workflows
Kitchen, counter and bar have separate station views. The pass view brings preparation status together for service. Orders appear according to item routing. In the previous demo, the counter stayed empty and kitchen monitors could not access the pass. Successful device operation is therefore not yet demonstrated.
Kitchen tickets show items, courses and elapsed time. Starting, marking ready, serving and recalling are defined workflows. During the previous run, paired kitchen monitors were blocked from making changes. Controls, timers and recall still need verification after the repair.
A successful ready action creates a “Dish ready” notice at the till and on the waiter’s phone. The run achieved this only through the till. The pass shows ticket status, without a separate alert overlay. Working delivery to buzzers, smartwatches or background push has not been demonstrated.
The pickup display shows orders as “in preparation” or “ready”. It uses the pickup code and kitchen status. Telephone pickup orders follow this route. Guest orders appear only when recorded as pickup orders with a code; an ordinary table QR order does not automatically become a pickup.
When enabled, the POS estimates waiting time from recent preparation times and open kitchen tickets. Guests see it on the guest screen. This is a calculation without a language model. Missing samples trigger a fallback; old orders distorted the demo. Reliable predictions have therefore not yet been demonstrated.
Kitchen analytics separates waiting, cooking and service time. With enough samples, the kitchen copilot can request recommendations through Nova. The run had insufficient data and produced no AI answer. The shopping list is maintained manually; it does not derive requirements from recipes or stock levels.
Step by step
Use the arrow keys or swipe to move on
Step 1 of 2
Samples make each time segment analysable. An old ticket left open for hours is not a reliable guide for the next guest.
Step 2 of 2
Write down what is needed and tick off completed items. The list places no automatic orders and keeps no stock records.
LidoOS Copilot
AI analysis not yet demonstrated
The POS calculates metrics; Nova handles AI analysis with Mistral as the preferred provider. No language model runs inside this POS module.
You check the data and decide on recommendations.
The run had one sample out of at least five required. No model call ran. Waiting-time estimates and the manual shopping list are not AI results.
Nova ↔ POS
Maintain menus, tables and staff in Nova. The POS handles orders, payments and receipts.
The limits
Device controls and pass access need verification after repairs. The counter needs assigned items. Kitchen timings must be complete and plausible. Waiting time and copilot require activation. Additional alert devices and background push have not been demonstrated as working.
Availability
LidoOS POS — coming soon. Terms in the shop; we will plan the introduction together.
Talk to us about how LidoOS POS fits your venue’s workflows.
Short answers
The waiting time display calculates from recent preparation times and open kitchen tickets. It has to be enabled and is an estimate, not a guarantee.
Kitchen tickets and ready reports are part of the workflow. Additional signal devices such as buzzers or smartwatch delivery are not proven to work and are not promised.
Enough measuring points from real operations. In the demo venue the data was not sufficient for a recommendation; the model call then runs through Nova.
The captures show existing tickets of the stations in the demo venue Via Palermo. Nothing was reported ready; the counter is currently empty because no items are assigned.
Tell us how you work: dining room, terrace, counter or self-service. Together we will define your operating mode, devices, Nova modules and terms.