Two hours, one table, six decisions
A dining room does not have transactions, it has services. The system's job is to know what has been fired, what is plated, which seat it belongs to and when the next course should start.
What this actually needs
Courses fire when the pass says so
Each line carries its course, and a round is sent when the previous one clears. The kitchen sees a table's service, not a queue of unrelated items.
The bill knows who ate what
A seat number on the line means the check can be presented per cover, per couple or whole, without the waiter reconstructing the table from memory.
The floor plan is the host's screen
Tables carry status, capacity, view and the waiter assigned for the shift. A reservation seats a table and every surface — floor plan, till, waiter tablet — shows it occupied at once.
The guest is remembered, not profiled
An order can be linked to a customer for allergies and preferences, with the GDPR erasure path built in. What is stored is what the room needs to serve them well.
The apps that matter here
Frequently asked
Can the kitchen hold a course until the room is ready?
Yes. Courses are fired explicitly rather than on a timer, so the pass decides. Lines that have not been fired stay off the kitchen screen entirely.
How does a manager approve a void on a fired dish?
Once a line has gone to the kitchen it takes a one-time manager approval to void, entered on the device and recorded in the audit trail. An unfired line is voided without ceremony.
Do reservations come from our existing booking site?
Reservations live in the platform with the floor plan. Whether an existing booking channel can feed them depends on that channel's API — it is a fair question for the demo rather than a promise here.
Service starts at six.
Are you ready?
A live demo, thirty minutes. No slides: we build a scenario from your own restaurant, answer what you ask and talk pricing straight.