Counter, Orders & Kitchen
One order record, with clear boundaries.
Counter, orders, approved payment records, and invoices operate in the pilot. Kitchen routing and handoff are being validated; guest QR and direct pickup ordering are not part of the current promise.
Discuss the workflowOrder context should not disappear between tools.
A counter sale, payment record, invoice, and external-order context need one traceable order record. Kitchen execution is the next workflow being tested against that foundation.
The operating loop
Current core and validation path
One source record follows the work. Each step keeps its context.
- 01 Capture Create a counter or Wolt-aware order
- 02 Price Keep lines, totals, and context together
- 03 Record Use an approved payment method
- 04 Document Create the linked invoice record
- 05 Validate Test kitchen routing and preparation states
- 06 Review Trace the order and its operating evidence
No re-entry between steps. Corrections keep the original evidence.
Operating in the pilot
- Counter entry
- Staff create and update orders from the counter interface.
- Order handling
- Order lines, quantities, status, and venue context stay together.
- Wolt context
- External Wolt order context can be represented without claiming a full delivery integration.
Payments and documents
- Approved methods
- The venue records only the payment methods configured for its pilot workflow.
- Invoices
- Invoice records stay linked to the order they document.
- Traceability
- Operators can review who recorded an order or payment action and when.
Kitchen workflow under validation
- Routing
- The team is testing how order lines reach the correct preparation view.
- Preparation states
- New, preparing, and ready states are validated with real service behaviour.
- Handoff
- The counter-to-kitchen handoff is not marketed as broadly available until the workflow is accepted.
Exceptions stay visible
- Order changes
- Edits remain attached to the order rather than becoming an unexplained total.
- Failed actions
- A failed record is shown for review instead of being presented as completed.
- Human authority
- Protected payment and correction actions require the appropriate role.
Current boundaries
- No guest-ordering claim
- Table QR, order-ahead, and guest pickup ordering remain outside this pilot scope.
- No refund claim
- Refund automation is not included in the current public promise.
- No full delivery integration
- Wolt-aware context does not mean end-to-end marketplace reconciliation.
A clear boundary
Scope
Included
Counter order entry, order handling, configured payment records, linked invoices, and active kitchen-workflow validation at the current pilot venue.
Not claimed in this scope
Broad kitchen availability, guest QR ordering, order-ahead pickup, automated refunds, and end-to-end third-party delivery integration.
Tell us how orders move through your venue.
We will separate what can be piloted now from what still needs validation.