Live state across connected service surfaces.
Orders, tickets, tables, payments, staff and delivery updates move across connected POS, QR, KDS, Storefront, Admin and Rider workflows through shared live state.
Supported updates across configured POS, QR, KDS, Storefront, Admin and Rider workflows.
Supported order, ticket and payment events on a connected stream.
Shared table state available to authorised connected staff devices.
Supported updates arrive through subscriptions while the device is online.
What 'check the other screen' actually costs
From refresh-driven to live by default
- Staff refreshing screens to see state
- Servers add the same item twice
- Tickets arrive in the kitchen with no source
- Customers ask staff for status
- Delivery is a phone call away
- Connected surfaces receive the same supported live state
- Shared table state reduces duplicate entry
- Tickets trace to the order that produced them
- Configured QR, Storefront and Rider views receive supported status updates while online
- Configured courier status can flow across pickup, transit and drop-off
A typical moment in service
What updates in real time
One table across connected surfaces
- 19:42QR scan opens the table on the live recordThe server POS can receive that shared state while connected.
- 20:00Server adds a side from Staff MobileConnected QR, KDS and POS views receive the order update.
- 20:30KDS bumps a ticket; customer view ticks to 'Ready'No separate status re-entry is required while the workflow remains connected.
- 21:00Rider courier picks up an online orderStorefront customer view ticks to 'On the way'.
- 21:25Card authorised on TerminalThe POS payment drawer receives the authorised state against the order.
Shared state instead of separate refresh loops. Connected surfaces follow the same shift.
Supported order, ticket, table, payment, staff and delivery events move across the products participating in that workflow while they are online.
Real-time questions
Do staff need to refresh anything?
Connected clients subscribe to supported live state and do not normally require a manual refresh. A working network connection is required, and the application shows reconnect or retry state when it cannot confirm an update.
What happens if a device loses connection?
Cibus is online-first. If connectivity is lost, the affected application shows an explicit reconnect or retry state rather than pretending that an order or payment write succeeded. Staff should verify the latest state after reconnection.
Can multiple servers share a table?
Multiple authorised staff devices can work with the shared table record. Reconnect and concurrent-edit behaviour should be tested against the restaurant's venue workflow before rollout.
Does the customer view also update?
Yes. QR, Storefront and delivery tracking views reflect live order state.
Is the kitchen connected automatically?
Supported configured order surfaces can route tickets to assigned KDS stations in real time while connected.
See real-time service in action.
See how Cibus connects service, kitchen operations, payments, reporting, customer engagement and delivery into one restaurant operating system.