Kitchen screen: receive, prepare and serve orders
The kitchen screen shows active table orders and online pickup or delivery orders when that option is enabled. Staff confirm each order, start preparation, mark it ready and then served. Keep the screen open during service and check the connection warning if updates stop.
Know where the order came from
Table QR or linked table NFC: the customer opens the table menu, selects items and required choices, reviews the cart and submits. The system returns an order reference and a status page. Check the table label and service method on the kitchen ticket.
Public storefront WhatsApp checkout: this prepares a message for the customer to send. It is a separate flow and does not automatically appear on this board. Arrange who receives and confirms those messages.
Online pickup and delivery: these appear in the kitchen only when Send online pickup and delivery orders to the kitchen is enabled in Restaurant settings. This is off by default and changes Feast checkout to the tracked order flow. It does not import old WhatsApp messages or create scheduled orders. Restaurant and Cafe share the kitchen workflow.
Handle an order
Received: review the items, choices, quantities, notes, service method and table or customer details. Receipt by the system is not acceptance by the restaurant.
Confirm: accept the order when your team can fulfil it. Then use Start preparing when preparation begins.
Ready: mark the food ready when it can be handed over. Staff can then serve it or hand it to the customer according to the service method.
Served: mark the handover. The ticket leaves the active kitchen board. This screen does not provide a further Complete action for a ticket that has left the board, and serving does not confirm payment.
Cancel without losing track
Use the cancel control on the active ticket and confirm. The ticket should leave the board after the server accepts the change. Reload to verify if its state is unclear. Cancelled orders retain their recorded history; there is no ordinary Undo action.
If another operator changed the order first, read its refreshed status before acting again. Do not repeatedly click an outdated action or assume a timeout means the order was not changed.
Connection and session recovery
The board refreshes periodically. If a request stalls, the last visible tickets stay on screen while it retries. Treat the warning as a sign that these tickets may be out of date.
If your sign-in session expires, actions pause and the screen explains how to reload. Use Reload kitchen, sign in again if required, and check the latest status before changing an order.
A customer status page shows when live updates are interrupted. Keep the order reference and reconnect. If the submission response was lost, use Retry original order to retry the saved request. The cart and customer details stay fixed until the result is resolved; do not start another order merely because the response timed out.
Estimates, prices and payment
The customer estimate uses the longest preparation time among the ordered dishes. When kitchen-load is enabled, other active orders add time. A change to preparation settings affects new orders; do not promise that an existing estimate is rewritten.
The server checks current products, availability, choices and prices at submission. If a cart includes an unavailable or invalid item, the customer must review it; the order is not silently shortened. Surcharges and currency precision are included in the stored receipt.
Selecting cash or another displayed payment method records a preference. It does not collect money, mark a bill paid or issue a refund. Follow the restaurant's payment procedure separately.
Order history and payment records
Open Orders from the restaurant hub. Search by order reference or customer name, and filter by status or payment record. Open an order to review its items, choices, totals, service details and status history, including served or cancelled orders that have left the active kitchen board.
After the restaurant receives the full payment, open the order, choose Received via and use Record payment received. Choose cash, card terminal, bank transfer or other. This is a manual record of money already received. It does not charge the customer or change the kitchen status. Cancelled orders cannot receive a new paid record.
To correct an entry, open Correct this payment record, enter the required reason and choose Remove payment confirmation. The payment activity keeps the correction. Arrange any refund separately. If another operator changed the record, reload before trying again.
The hub's order value uses the restaurant's local day and shows each currency separately. Treat it as order value, not proof of cash collected; check each order's payment record.
Table sessions and the next service
After service, finish or cancel every active order for the table and record payment for each non-cancelled order. Check the table physically, then open Tables & QR and choose Clear for next guests. The action refuses active orders or missing payment records and closes the old table cycle. Serving an order alone does not clear the table.
Before service, check the correct restaurant, connection and availability. Practise one full order with the team using Restaurant OS setup. Keep a separate fallback process for an unavailable device or internet connection.