# Kitchen Preparation, Packing and Order Handover Restaurants | MT BYTES solution study Station tasks connect preparation, packing and handover, with component checks and owned exceptions showing what still prevents an order from leaving. The fulfilment workspace follows order components through station preparation, packing and handover. A finished dish retains its relationship to the complete order, including missing sides and special requirements. Packing checks determine when the order is ready to leave. Delays, unavailable components and corrections remain visible with a responsible team and a practical next action. ## Solution design ### Ready means the whole order is ready Preparation status stays visible by station, packing confirms the complete order, and handover records the transfer to the correct customer or courier. Staff can identify the missing component without restarting or marking the entire order incomplete. - Clear work for each preparation station - Packing checks before readiness messages - Traceable collection and courier handovers **Business context:** A restaurant operation handling dine-in, collection and delivery orders through multiple preparation stations. **Core capability:** Software Development ![Solution study artwork](../../images/solution-studies/selected/06-hero.webp) ## Scope - Item routing and station preparation tasks - Order assembly and packing checks - Collection and courier handover records - Delay, cancellation and missing-item exceptions - Shift views and integration recovery controls ## A finished dish can still belong to an unfinished order An accepted order crosses several work areas before it leaves the restaurant. Hot food, drinks and sides may finish at different times. A courier may arrive before the packing team has the whole order, while a collection customer waits at the counter. An order-level ready button hides these differences and can trigger a message too early. The operational view follows the components that matter to preparation and the checks that matter to release. It gives each station a focused queue and gives the packing team the combined picture. Staff can distinguish an unfinished item from an assembled order awaiting handover, without interpreting a stream of unrelated status updates. ## Verbal checks reveal what the software is missing The workflow is mapped around the moments when staff ask another station whether something is done, search for a printed ticket or repeat an update already entered elsewhere. Those questions reveal missing dependencies. The model records which station owns each component, which items can proceed independently and which confirmation allows the next person to act. Priority, preparation time and the customer promise remain separate. An early courier arrival does not automatically make that order the kitchen's highest priority. Likewise, cancellation before preparation differs from cancellation after food has been made. Staff need states that reflect those operational consequences rather than a small set of labels chosen only for customer-facing simplicity. ## Station work stays attached to the original order Each order generates the required item tasks with quantities, modifiers and destination stations. Stable references connect those tasks to the original channel order and payment context. Preparation, assembly, packing and handover have explicit completion events, including who recorded them and when. The history can explain a disputed update without overwriting what another station saw. Integration events use repeat-safe handling. A delayed channel message cannot create another set of kitchen tickets, and a retry does not complete a task twice. The system retains the current task state separately from the incoming event log. This makes recovery possible without asking staff to recreate the order or guess which version is authoritative. ## The packing view brings the components back together Station screens show the work relevant to that team, including required modifiers and any preparation dependencies. Completing a station task updates the shared order but does not announce that the whole order is ready. The packing view shows which components have arrived and which still need attention, with a concise check matched to the order type. Once the order is assembled, staff confirm its contents and fulfilment route. The handover step matches the bag or tray to the customer, table or courier reference. If a missing component is found during packing, its specific task reopens while the completed work remains recorded. This preserves useful progress and prevents a blanket reset from confusing every station. ## A delay needs an owner and a practical action A blocked station can affect several orders at once. The shift view identifies the affected tasks and directs the issue to the person who can rebalance preparation, adjust the customer promise or pause incoming demand. Alerts distinguish a single overdue item from a wider service problem, avoiding a screen full of identical warnings that nobody can prioritise. During an integration or device outage, the interface shows the last confirmed state and any unacknowledged updates. The restaurant's fallback process defines who records manual actions and how they are reconciled. Cancellation after preparation requires an authorised reason. Operational changes and financial reversals remain separate, so stopping kitchen work does not silently issue a refund or leave payment resolution assumed. ## The screen is tested where staff actually use it The first flow includes mixed preparation times, modifiers, a late cancellation and a missing component at packing. Staff use the intended screen positions and input devices during the check. Ticket density, touch targets and viewing distance matter because a readable desktop prototype can become unusable beside a busy preparation area. The initial operational record is compared with the existing handoff process before more channels are added. Staff agree on what each completion means and which actions remain available after it. Additional channels then map into that model using their original order references. A new marketplace integration should not introduce a different meaning of ready for the same packing team. ## One shared view does not remove local ownership Each station owns its preparation tasks. Packing owns the completeness check, handover staff own the final transfer, and the shift lead handles delays that cross those boundaries. Central operations maintains routing and timing rules. Technical support owns synchronisation failures, with enough event context to investigate without asking the kitchen to reproduce a rush-period problem. Operational reviews group delays by workload, station, routing error and integration issue. The same elapsed time can reflect different causes and needs different action. Proposed routing changes are previewed against representative orders before use. Staff feedback is especially valuable when a required confirmation creates extra work without helping the next person make a decision. ## Preparation speed is only one part of the result The service separates working time from waiting between stages. It reviews orders by type, size and service period so a complex delivery order is not treated as equivalent to a single drink. Packing corrections and handover mismatches show whether faster preparation is simply moving unresolved work further downstream. Customer readiness messages are checked against packing confirmation, and handover records against the actual recipient reference. Recurring missing items point to menu routing or packing checks; repeated waits after packing may point to dispatch coordination. The purpose of the review is to locate the next operational correction, with enough detail to avoid blaming the busiest station for every delayed order. ## Operational flow 1. **Distribute preparation work.** Accepted items reach the correct stations with quantities and modifiers. 2. **Confirm each component.** Stations record completion against their assigned tasks. 3. **Assemble and check.** Packing verifies the complete order and reopens any missing component. 4. **Release for collection.** The confirmed packed state permits the appropriate readiness update. 5. **Record the transfer.** Handover staff match the order to its customer, table or courier. ## Key decisions ### Track station tasks separately Keep preparation progress at component level within the order. Different completion times should remain visible without fragmenting the customer request. ### Make packing a release check Confirm the assembled order before marking it ready. A finished preparation task does not prove that the bag contains everything. ### Route exceptions to a role Assign delayed or disputed work to the responsible station or shift lead. An alert is useful only when someone can take the next action. ## Evaluation measures These measures define the evaluation criteria for the workflow, its controls and the quality of completed tasks. ### Waiting between stages **Measure:** Compare preparation, assembly and handover intervals by order type and service period. **Success criteria:** The team can identify the stage and cause behind recurring delays. ### Packing corrections **Measure:** Record missing, incorrect and reopened components with their source tasks. **Success criteria:** Corrections inform routing and preparation rules instead of remaining verbal workarounds. ### Readiness message accuracy **Measure:** Compare outgoing ready messages with packing confirmations and subsequent corrections. **Success criteria:** The message reflects an order that staff can actually hand over. ## In practice The order remains one customer commitment even when several teams prepare it. Component tasks make the work visible, packing checks bring it together and the handover record confirms where it went. That sequence gives a busy restaurant a dependable answer to the question that matters at the counter: what is still stopping this order from leaving?