Ordering from the table with a QR code

The order is taken twice, and the second time is from memory

At a full table the waiter writes on a pad, walks to the kitchen and says it out loud. Between the pad and the pass, a dish changes, a portion is forgotten, and an allergy that was mentioned at the table is not mentioned again.

The busiest hour is also the one where the pad is hardest to read. Nobody records what went wrong, so the same evening repeats itself next week.

The guest writes it, a person still decides it

The guest picks from the menu already open on their phone, so the dish names, the prices and the declared allergens are the ones you published. Nothing is retyped and nothing is remembered.

What the guest sends is a request, not a job. A waiter confirms it, and only then does it appear in the kitchen. Somebody who is not sitting at that table cannot open work on your stove.

How it works

You switch it on for the branch Ordering is off until you turn it on, and it is turned on one branch at a time. Anyone who can see the orders knows whether the branch is taking them; only the owner can flip the switch.
The guest scans the code on the table The cart appears only when the scanned code belongs to a table, your plan carries the right, the branch is taking orders, and the published menu is priced in one currency.
The basket stays on the phone Nothing is written on the server until the guest sends the order. There is no account to open and no application to install.
The server writes the prices, not the phone Only a dish and a quantity are accepted from the guest. The name, the price and the declared allergens are copied from the menu you published, so the guest cannot set what a dish costs.
A waiter confirms it, or refuses it with a reason Sent orders wait in a queue, oldest first. Confirming and refusing are the same door, and a refusal cannot be saved without a reason written on it.
Only then does the kitchen see it A waiting order is invisible to the kitchen board. Confirmed, preparing and ready are the only states a cook ever sees.
The kitchen moves it, service closes it The kitchen marks an order as being prepared and then ready. Marking it delivered belongs to whoever carries the plate, not to the stove.

What you can do

The table is read, never typed: The order lands on the table whose code was scanned. A guest cannot pick a table, so an order on the wrong table is not a mistake this product can make.
Nothing to install, nothing to sign up for: The guest orders from the same web page that shows the menu, without an account and without giving a name, an email address or a phone number.
The order keeps the price it was sent at: Names, prices and allergens are copied into the order line. Renaming a dish or changing a price tonight does not rewrite this evening's tickets.
Declared allergens travel with the line: What you declared for a dish is carried onto the kitchen board with the order, so it is read where the food is made and not only where it was ordered.
Two boards, two different permissions: The service queue and the kitchen board are separate. A kitchen account sees confirmed work, allergens and sold-out marks, and cannot confirm an order or read anything else about the business.
Two people cannot confirm the same order: A status change is written on the condition that the order is still where it was. The second waiter is told what the order is now, instead of being told the confirmation worked.
A history that is not deleted: Every order stays, with what was in it, what happened to it, when, and the reason if it was refused. There is no way to remove an evening from the record.
A ceiling on open orders per table: One table can hold five orders that are still open. Closed orders do not count, so a table eating all evening can keep ordering.
The boards say when they last updated: The queue and the kitchen board refresh every ten seconds and print the moment of the last successful refresh, using the server's clock rather than the screen's.
Orders sent are counted in the report: Sending an order is recorded as an event beside scans and menu opens, so the menu report can show it. What was in the order is not copied into the reporting table.

What you need

A code that belongs to a table	A poster, a door code or a business card cannot carry an order, because there is no table behind it. Such a scan is refused and the guest is asked to scan the code on their own table.
A plan that carries the right	Ordering from the table is opened by these plans: Restaurant and Team. Without one, the cart is never drawn, and an order sent by hand is refused with the name of the missing right.
The switch, turned on by you	A branch does not take orders until somebody turns it on. This is deliberate: a restaurant that never opens the panel should never have work appear on its stove.
One currency in the published menu	The cart shows a total. If the published menu mixes currencies, no total can be honest, so the cart is not drawn at all.
Somebody watching a screen	An order waits until a person confirms it. On the plan that opens ordering, the owner already carries every ordering permission, so no team invitation is needed to start.

What it does not do

It does not take payment No guest pays through Zabuno. An order has no paid state, no card step and no bill; the money is still handled at the table, exactly as it was before.
It does not talk to your till There is no connection to a point-of-sale system or an accounting package. An order lives in Zabuno and is read on a Zabuno screen.
Only from a table in the room There is no takeaway, no delivery, no collection and no ordering ahead of arriving. The one way to send an order is to scan the code on a table.
No table booking Reserving a table is not part of this product. Ordering starts with a guest who is already sitting down.
The guest has no screen after sending The guest is told the order was received, and that is where the phone's part ends. There is no page that follows the order, no way to cancel it from the phone, and a refusal reason is read out at the table rather than pushed to it.
No notes and no options on a dish An order line is a dish and a quantity. "No onions", "well done" and a choice of sauce cannot be sent, because a dish has no options in the menu either.
Nothing prints and nothing beeps There is no kitchen ticket printer, no sound and no push notification. Orders appear on a screen that refreshes itself, so the screen has to be visible to somebody.
No running tab and no split bill Each order carries its own total. The product does not add a table's orders into one bill and does not divide one between guests.

Questions owners ask about ordering

Can my guests pay through the menu?

No. Ordering carries the request to your kitchen; the payment is taken at the table the way it is today. There is no card step anywhere in this flow.

Does an order go straight to the kitchen?

No, and that is the point. It waits in the service queue until a waiter confirms it. The kitchen board never shows an unconfirmed order.

What happens if I never switch ordering on?

Nothing changes. Guests read the menu as before and no cart is drawn on their phone, so nobody is invited to send an order that would sit unread.

Can a guest order from the poster by the door?

No. A code that is not tied to a table is refused, because there would be nowhere to send the food. The guest is asked to scan the code on their own table.

Can a guest change or cancel an order after sending it?

Not from the phone. The guest asks the staff, and the waiter refuses the order with a reason, which stays on the record.

Does the kitchen screen make a sound when an order arrives?

No. It refreshes every ten seconds and shows when it last updated, so a frozen screen can be told apart from a quiet evening.

Can a guest ask for a dish without onions?

No. An order line is a dish and a quantity; there is no note field and no option list. Those requests are still made out loud.

See which plan opens ordering

Reading the menu costs nothing; sending an order from the table is part of a paid plan.

See the plans