The drink is ready but the meal is still being prepared. Does dispatch see the whole order as ready? When a cashier voids an item, does the kitchen know, or keep preparing it because the change stayed at POS? These questions reveal more than a perfect order printing one ticket.
Before buying POS, kitchen and delivery integration, involve cashiers, preparation staff and dispatch in one scenario. Compare each component's view of the same order and identify manual work. A kitchen display purchase does not establish integration with every delivery channel or payment provider.
Map the included components
A fictional quick-service restaurant has meal and drink stations and a pickup point. Orders come from POS or a proposed delivery channel. Identify who creates the order reference, its correspondence with the other channel and ownership of menu items, prices and modifiers.
Specify devices, printers, displays, network, versions, accounts and provider approvals. An unproven channel or separate contract should be a pending dependency rather than an arrow suggesting completed integration.
One six-stage acceptance journey
- New order: enter a meal, drink and fictional meal note. Each station should see its relevant items and correct reference without unexplained duplication.
- Change after submission: alter a permitted note or quantity. Verify the station received and distinguished the change, beyond the cashier seeing the new version.
- Partial cancellation: void an item with appropriate authority and inspect preparation, dispatch and sales records. Agree handling of preparation already started rather than treating a disappearing line as resolution.
- Partial readiness: finish the drink while the meal remains in preparation. Dispatch should follow the agreed policy without confusing item readiness with full-order readiness.
- Handover: check confirmation of pickup or availability and updates to the connected channel where scoped. Ready does not necessarily mean collected by a courier.
- State reconciliation: review payment and cancellation or refund where included. A kitchen-state change does not prove a money movement or delivery-channel record changed.
This is a proposed test journey, not universal product capability. Foodics Black documents how modification submission and cancellation affect its kitchen screen; Odoo documents preparation categories and stages. Ask for actual configured behaviour rather than applying one product's buttons to every system.
Own discrepancies between screens
A delivery channel may show acceptance while a preparation station sees nothing. Request an exception route: who notices, checks both references, approves manual intervention and prevents a second entry before verification?
POS, preparation, dispatch and payment states describe different aspects. Agree mappings instead of forcing one shared label onto everything. Staff should understand pending states, next steps and ownership without needing a developer each time.
Try representative volume in training
After the single journey passes, agree closely timed orders representing a realistic test load. Include both stations, a modification and a cancellation. Observe ordering, note visibility and pending work rather than button-press speed alone.
Record devices, network, users, orders and observation period. A passing sample cannot establish unlimited capacity. Technical teams should simulate connectivity loss or channel delay safely without disrupting a working kitchen or sending real courier requests.
Record results with operations
For every stage, record steps, inputs, expected result, each participant's observation and the decision. Name manual cancellation work, its owner and completion evidence. You may accept the boundary, but should understand it before planning staffing or launch.
Ask restaurant staff to repeat the journey after training using ordinary roles rather than an unrestricted administrator. Connect gaps to devices, configuration, integration or policy. This avoids calling a routing defect a training problem or developing unnecessary features to fix a procedural issue.
For branches, stock and shifts, see the multi-branch POS test guide; for repeated-operation failures, see integration retry acceptance tests. Send the journey when discussing POS implementation and integration with Nextwave so departments can inspect a shared result.
Behaviour sources and limits
Foodics Black kitchen-status guidance and Odoo19 preparation-display documentation source were opened on 3 November 2026. They establish neither every integration or device nor local accreditation. The original fictional scenario was prepared with AI assistance and review of the content and sources.
