Restaurants / front of house to kitchen
Connect table-side order entry, counter checkout, kitchen production, payment and receipt output around the restaurant system you already run.
Discuss your projectRestaurants / front of house to kitchen
The operational cost is rarely the tap on a screen by itself. It is the missed modifier, duplicate ticket, delayed kitchen message, wrong table, failed payment or receipt that cannot be reconciled during a rush. Start by defining what the server, cashier, kitchen and guest each need to see, then assign each step to a device and an application owner.
01 / service flow
A useful restaurant map includes modifiers, course timing, voids, reprints and payment exceptions. Those details are where the physical setup and software contract meet.
Select the table, counter ticket, delivery order or guest reference before entering items.
The restaurant application owns table state, order number, menu availability and staff identity.
Wrong table, stale session or duplicate order number. Require a visible context check before items are sent.
Record quantity, modifiers, allergies or preparation notes using a flow that is fast enough for the busiest service period.
The POS validates menu, price, tax and modifier rules before creating a production ticket.
Item unavailable, modifier conflict or connectivity loss. Define whether the order is held locally, rejected or sent for manager review.
Route the ticket to the correct station, display the queue and update preparation status as the order changes.
KDS or kitchen printer consumes an order event from the POS; the POS remains the source of truth for the ticket.
Ticket not received, duplicate ticket, station offline or printer out of paper. Test acknowledgement and recovery without creating a second order.
Mark items ready, coordinate courses or pickup and preserve the order reference through service completion.
The restaurant application updates ready, served, cancelled or partially fulfilled state.
Partial fulfilment, item remake or guest change after firing. Define who can alter the ticket and how the kitchen sees the change.
Split, merge or close the check, run the approved payment flow and provide the receipt required by the operation or jurisdiction.
Payment service authorizes the transaction; the POS ties payment references to the check and settlement report.
Split-payment failure, decline, timeout, duplicate callback or a receipt that prints after the payment state changes.
Review open checks, voids, refunds, payment settlement, printer/KDS incidents and end-of-shift handover.
POS, payment and production reports are compared by check or order ID.
A kitchen ticket completed while payment failed, or a payment completed while the local order remained open. Define the reconciliation report and owner.
Test the dinner rush with real modifier depth, multiple stations, split checks and a deliberate network interruption. A quiet single-order demo does not exercise the restaurant workflow.
02 / station design
The best starting point is usually a small combination of endpoints, each with a clear job. Exact printer, display, payment and network behavior still requires model and configuration confirmation.
A fixed station for counter orders, cash drawer, receipt output, customer-facing status and manager actions.
A countertop terminal provides a stable service point for orders, receipt printing and peripheral connections.
Printer and cash drawer interface, customer display, menu screen layout, LAN or Wi-Fi and store-level policy.
A mobile endpoint that keeps the server with the guest while handling menu navigation, modifiers and order submission.
Mobile order entry can reduce transcription between paper, counter and kitchen, but battery, grip, scan/print variants and roaming matter during service.
Screen ergonomics, app session behavior, charging rotation, Wi-Fi roaming, order retry and optional receipt output.
A readable queue for station routing, priority, modifiers, timing and acknowledgement, with a printer fallback if required.
A KDS and a kitchen printer solve related but different operational needs. The choice depends on station visibility, noise, paper handling and ticket persistence.
Station routing, font and modifier layout, acknowledgement semantics, cleaning environment, paper format and failure fallback.
A payment endpoint that can receive the amount and order reference without exposing payment ownership ambiguity.
A separate payment role can shorten the handoff for table-side or queue-side service when the acquiring setup supports it.
Acquirer, market, certified methods, transaction callback, tip/surcharge rules, connectivity and receipt responsibility.
03 / restaurant integration
The technical brief should describe order IDs, station events and payment references as carefully as it describes the Android device. That is what prevents a good-looking interface from becoming an unreliable service flow.
The app should present only the menu and modifier combinations that the POS can price and route. Device selection cannot fix an ambiguous menu model.
Define whether a ticket is sent by Intent, SDK, network service or the restaurant platform, and what acknowledgement means at each station.
Payment success should close the intended check exactly once. The app needs a recovery path when authorization succeeds but the callback or receipt is delayed.
Restaurant networks are busy, staff change often and devices move between charging points. Plan access, policy and recovery as part of the operating model.
04 / service rehearsal
Pilot the exact station combination in a live-like service window. The acceptance target is not just a successful order; it is an understandable recovery when something goes wrong.
PILOT / STAGE / HANDOVER
Name every front-of-house, KDS, printer and payment role, then record the exact model, variant, app build, firmware, accessory and network.
Output: one station map with owners and open questions.Use multiple servers and stations. Repeat modifiers, split checks, voids, item remakes, KDS acknowledgement, payment decline, printer failure and reconnect.
Output: raw results, timing observations and known limitations.Preload the approved app, enroll policy, pair or label endpoints, define spares and give managers a short recovery record for common incidents.
Output: deployment profile, acceptance sign-off and support ownership.05 / public reference
The public materials below describe product roles and payment capabilities that can inform a restaurant station map. They are not a UnitWeave restaurant deployment or a compatibility result for your POS.
SUNMI reports 30% lower cost and 40% less space for the all-in-one device.
The registered Elzab reference is a retail and payment case rather than a restaurant delivery. It is included because the same consolidation question appears at a restaurant counter: which checkout, payment and receipt responsibilities should share an endpoint?
All case language above is based on SUNMI manufacturer material and presented with UnitWeave's delivery perspective as SUNMI's global authorized distributor within the scope of our current authorization. It is not a standalone UnitWeave-owned case study or UnitWeave test result; availability, certification, payment and support terms remain specific to the named project and destination.
06 / restaurant questions
No. A KDS supports visible queues and status interaction, while a printer can suit stations that need persistent paper tickets or a simpler fallback. Decide by station, environment, acknowledgement needs and failure procedure.
Sometimes, depending on the device configuration, approved payment integration and market. Keep the order app and payment/acquirer responsibilities explicit, then validate the exact P3, P3 AIR, M3 or other selected setup.
Use a stable order and event identity, idempotent retry behavior and a clear acknowledgement state. The device should expose the state; it should not silently resend a ticket after a timeout without application rules.
Test a full service path with modifiers, multiple stations, item changes, payment decline, partial fulfilment, printer or KDS outage, reconnect, reprint and end-of-shift reconciliation.
Yes, it can be assessed when the named POS build, Android assumptions, order event interface, printer/KDS path, payment integration and permissions are available for review.
Restaurant project intake
Tell us how orders enter, how tickets reach the kitchen, which payment flow is approved and what happens when the network, printer or KDS is unavailable.
