Mark an order ready only when the complete, checked order is available for pickup. Mark it handed off only when an authorized person actually takes it. Until then, expo should be able to tell the difference between food being prepared, food waiting on the shelf, and an order that has left the restaurant.
That distinction matters when a courier is late, a guest cannot be found, or expo discovers a missing side. If “ready” also removes the order from view as “complete,” the kitchen may lose sight of food that is still its responsibility. Ask vendors to show how their workflow preserves that distinction before choosing a kitchen display system.
Define each handoff point
Start with the physical event, not the button name. Different systems may use different labels, so have the vendor map its actual screen actions to the events your staff need to recognize.
- In preparation: At least one required item is being made or has not yet been prepared. A cook finishing one component does not make the whole order ready.
- Prepared: The individual food items are finished, but they may still need to be brought together, checked, packaged, or matched with drinks and other items.
- Assembled: Expo has gathered the order. It still needs a final check against the ticket before it is offered for pickup.
- Ready: The complete order has passed the check and is available for the intended guest, server, or courier to collect.
- Handed off: The order has been physically transferred to the intended person or an authorized representative.
A handoff to a courier is not proof that the meal was delivered to the guest. If delivery confirmation matters, ask where it comes from and whether the restaurant can see it. Likewise, placing a dine-in order on the pass is not the same as a server taking it to the table.
The intended flow, including a missed-pickup branch, looks like this:
In preparation → Prepared → Assembled → Ready → Handed off
Ready → Pickup overdue → Investigate or hold → Handed off, remade, or canceled under restaurant policy
Ready → Missing item found → Return affected item to preparation → Recheck full order → Ready
These are operating states, not a promise that every KDS has a separate button for each one. A small operation might combine prepared and assembled on screen while retaining the distinction in its checklist. The crucial boundary is that waiting food remains visible until someone takes responsibility for it.
Give each state an owner
Write down who performs the physical action and who records it. On a busy shift, those may be different people. The table below is a starting assignment for a restaurant with cooks, an expo, and a pickup counter; adapt it to your staffing.
| State or event | Physical owner | Verification before marking | Question for the demo |
|---|---|---|---|
| Items prepared | Cook or station lead | Required items and modifiers are made | Can station work be distinguished from the whole order? |
| Order assembled and ready | Expo | Items, quantities, modifiers, packaging, and order identity match | What stays visible after ready is marked? |
| Pickup overdue | Pickup lead or shift manager | Order is still present and the intended recipient has not collected it | Can staff find and identify waiting orders? |
| Handed off | Person releasing the order | Recipient and order match the restaurant’s pickup procedure | Can staff record a separate handoff event? |
For example, a cook can signal that a burger is finished, while expo checks that the requested modification and accompanying side are present. At the counter, the employee releasing the bag verifies the order identifier and marks the handoff. A restaurant may use a name, order number, or another pickup check; choose a method that works for its channels and avoids giving one guest another guest’s food.
Decide who can correct an accidental ready or handoff mark. Ask whether the system records who made a change, whether a manager must approve it, and what staff see after the correction. Do not assume a button labeled “complete” means the same thing as a physical handoff. Have the vendor show its effect on the kitchen view, pickup view, and connected order record.
If different stations contribute to the same meal, a guide to routing kitchen tickets by preparation station can help with the upstream workflow. The handoff decision remains separate: all stations can be finished while the order is still waiting for collection.
Work through a missing item and a missed pickup
Hypothetical scenario: An order contains two sandwiches, one salad, and two drinks. Expo assembles the bag, checks it, and marks it ready. Before pickup, an employee notices that the salad is missing. The two sandwiches and drinks are present.
- Move the order out of the ready queue, or use the vendor’s supported correction process, so the counter does not release an incomplete order.
- Send the missing salad back to the person responsible for preparation. Keep the rest of the order identifiable and associated with the same ticket.
- Follow the restaurant’s holding and quality procedure for the items already made. If they cannot be held, the shift lead decides what needs to be remade.
- When the salad is finished, recheck the whole order, including the sandwiches and drinks. Mark it ready again only after the complete order passes the check.
- Record handoff when the correct recipient takes the order, not when the correction is requested or the bag returns to the shelf.
Ask the vendor to demonstrate how an order can be corrected without obscuring the items already prepared. If the system cannot return one item to preparation, ask what staff must do instead: reopen the whole ticket, create a separate instruction, or use another documented process. Check whether that workaround makes the waiting order easy to find and prevents an accidental release.
Now consider the other branch: the complete order is ready, but nobody arrives. Set a restaurant-specific point at which the pickup lead checks the order, confirms its identity and status, and follows the restaurant’s policy for contacting the appropriate party or handling food that has waited too long. A waiting order should not be marked handed off merely to clear the screen. If the order is ultimately canceled or remade, ask how that outcome is recorded and whether the original waiting time remains visible.
Measure preparation and pickup time separately
Use two measures to answer two different questions. Preparation elapsed time runs from the agreed order start event to the first valid ready event. Ready-to-handoff time runs from the valid ready event to the actual handoff. Define the start event consistently: an order received in advance may be held for a future time, so counting from receipt can tell a different story from counting from release to the kitchen.
In a separate hypothetical example, an order is released to the kitchen at 6:04, verified ready at 6:16, and handed to the guest at 6:21. Preparation elapsed time is 12 minutes; ready-to-handoff time is 5 minutes. Together they account for 17 minutes from kitchen release to handoff. They do not measure delivery after a courier leaves, and they do not establish whether either interval met the restaurant’s target.
Corrections need a rule too. If an order was marked ready by mistake, decide whether reports should use the first mark, the corrected ready time, or both. Ask the vendor what its timestamps actually represent and whether corrections and missed pickups can be distinguished in reports. If not, decide whether a manual exception log is practical before relying on the numbers.
Review the two intervals by order type and shift when the available data supports it. Long preparation time may point to a kitchen bottleneck; long ready-to-handoff time may point to pickup coordination. Neither number alone explains the cause. Look at the ticket and the staff account before changing staffing or targets.
Run one shared demo before you decide
Give each vendor the same workflow and ask staff who will use it to watch. Fleksa offers a kitchen display linked to restaurant orders; its public KDS page describes order types, item names, quantities, modifiers, future held orders, and configurable timing and color indications. Ask to see how the setup you are considering handles the state changes above. Square describes kitchen tickets, timers, station routing, and expeditor functions; Toast also offers a kitchen display product. Confirm the specific correction and handoff workflow with each vendor rather than assuming the labels work alike.
Use a vendor-supported training environment for the missing-salad and overdue-pickup scenarios. A simulation must not take a real card payment, send a guest message, or dispatch a courier. Check what each role sees, what happens after an accidental mark, and which timestamps remain available. Then plan a supervised live service pilot with staff roles, correction procedures, and a way to monitor actual orders. A simulation is useful practice, but it does not show how the workflow holds up during a rush.
For your next step, write the five physical states and the two exception paths on one page. Ask a vendor to demonstrate each transition, then compare the result with your restaurant POS system and counter workflow. Explore Fleksa’s restaurant management software as part of that requirements comparison.
Frequently asked questions
Should expo mark an order complete when it is ready?
Only if “complete” is explicitly your ready state and the order remains visible for pickup. If that action means handed off or removes the order from the working view, use a separate process until someone actually collects it.
Does a courier pickup mean the order was delivered?
No. Pickup establishes that the courier took the order from the restaurant. Delivery to the guest is a later event, and its confirmation may come from a different system or process.
What should staff do if an order was marked ready too early?
Stop the handoff, use the system’s supported correction process, and make the missing item. Expo should recheck the complete order before marking it ready again. Ask the vendor how the correction affects visibility and timestamps.
