At courier handoff, staff should compare the order’s channel and location, the channel’s order reference, and the pickup name or other identifier shown to the courier. Use at least one distinctive reference that both the restaurant and courier can see. A name alone is a weak check when two orders have similar names or arrive close together.
The buying question is whether those details stay recognizable as an order moves from the ordering channel to the POS, kitchen ticket and pickup area. Ask each vendor to demonstrate your exact channel, POS and location setup. If a reference disappears or changes along the way, decide who will bridge that gap before using the workflow in service.
Start with the identifiers your staff can actually see
List each ordering channel used at each restaurant location. For every combination, identify what the channel sends, what the POS receives and what the courier is expected to present. A busy store using several marketplaces may have different handoff rules for each one.
Look for these details:
- Channel and location: Which service placed the order, and which restaurant should prepare it?
- Channel order reference: The reference assigned by the ordering channel, including any shortened version staff or couriers see.
- Pickup name: The name displayed for pickup, without relying on it as the sole match.
- POS or ticket number: A restaurant-side identifier that may differ from the channel reference.
- Pickup timing and bag count: Useful supporting details, but not substitutes for a shared order identifier.
Do not assume that a number on a kitchen ticket is the same number the courier sees. Ask whether the full channel reference, a shortened reference or a separate POS number appears at each step. If it is shortened, ask how staff can distinguish two active orders with the same visible ending.
Write down unknowns before comparing restaurant integrations. For example, a channel may display a pickup name to the courier while the restaurant sees a reference in its order screen. The practical question is how staff can confidently connect those two views, not how many systems appear on a vendor’s integration list.
Use a two-order handoff test card
The following card is hypothetical. The names and references are invented. It shows what to check, not the behavior of a particular product. Run the equivalent exercise in a vendor-approved simulation or safe test environment configured so that it cannot charge a real card, send a guest message or dispatch a courier. If those safeguards cannot be established, use a walkthrough with mock screens and tickets instead.
Both orders below arrive at the same location within a few minutes. Their names and references are deliberately similar. The expected result is that staff can trace each channel order to its own POS and kitchen record, then select the correct bag using an identifier shared with the courier.
| Check | Order A | Order B | Record during the demo |
|---|---|---|---|
| Channel reference | DE-4821 | DE-4827 | Full or shortened reference visible at each step |
| Pickup name | Sam R. | Sam P. | Whether the name appears on screen, ticket and courier view |
| Kitchen check | One meal; sauce on side | One meal; no sauce | Whether each modifier follows the correct order |
| Handoff check | Courier presents DE-4821 | Courier presents DE-4827 | Which bag staff select and which shared identifier they use |
For each row, record the expected result and what the vendor actually shows. Also compare the order totals in the source and POS views. Totals can help expose a mapping problem, but two different orders can have the same total, so do not use the amount as the handoff identifier.
Ask the vendor to show both orders in the queue at once. Then ask what happens if Order B’s courier arrives first. A workable demonstration lets staff identify B without assuming that the oldest ticket or the first bag on the shelf is the right one.
If the system does not support a simulated courier view, ask the vendor to explain what the courier normally sees and show how staff would connect that information to the restaurant record. Mark that part as unverified until the actual channel workflow can be checked safely. A mock walkthrough is useful for planning, but it is not proof of a live handoff.
Follow each reference from screen to bag
Use the test card to inspect each surface separately. Start with the source order, then move to the POS screen, kitchen display or printed ticket, and finally the label or other information staff use at pickup. The same information does not have to appear everywhere, but staff need a reliable path from the courier’s identifier to the correct prepared order.
For each surface, ask:
- Which channel and location does it show?
- Which order reference and pickup name are visible?
- Can staff distinguish the two test orders without opening another screen?
- If they must open another screen, who does that during a rush?
- Can the kitchen see the modifiers needed to prepare the correct order?
Separate automatic behavior from manual work. For example, if staff must copy a channel reference onto a bag, note who copies it, where they read it and who checks it. Manual steps can work, but they add opportunities for a transposed digit or an unlabeled second bag. Ask how the team will handle a missing or unreadable label.
Also distinguish a connection from the handoff workflow. A restaurant POS system may be one part of the path, while the ordering channel supplies the courier-facing information. Ask which provider is responsible for investigating a mismatch at each boundary. For a specific channel, such as an Uber Eats integration, confirm the fields and workflow available for your restaurant rather than assuming every connection behaves alike.
Set a short handoff rule and a stop rule
A practical handoff takes only a few checks, provided the information is visible. Assign one staff member to the pickup shelf during busy periods, or make the responsibility explicit for whoever hands over a bag.
- Ask the courier for the order reference or other identifier the channel provides.
- Match it to the restaurant’s order record and the prepared bag. Confirm the channel and location if those could be confused.
- Check the pickup name and bag count as supporting details. Give the courier all bags associated with that matched order.
- Complete any handoff confirmation the channel requires, following the restaurant’s procedure.
If the reference, name or bag label conflicts, stop the handoff. Do not resolve the conflict by handing over the closest-looking order. Move the bag out of the pickup flow and ask the shift lead to compare the source order with the POS record. If the courier presents an identifier staff cannot find, use the channel’s available support or escalation process. Do not disclose another guest’s details to settle the question.
Practice exceptions in the same safe simulation or mock walkthrough: a courier presents the other order’s reference, a bag has no label, or an order has multiple bags but only one is on the shelf. Record which actions the system supports and which require a person. If a case is not supported, document the limitation and agree on a manual response; unsupported does not automatically mean the integration is unusable.
Make the buying decision from the gaps
After the demonstration, give every unresolved item an owner and a next decision. The vendor might own a question about which reference appears on a ticket. Your shift lead might own the decision on where bags are labeled. The ordering channel may need to clarify what its couriers present. Set a date to resolve each question before rollout.
For example, suppose the demo shows the full channel reference in the POS but only a pickup name on the bag. If the courier can present that reference, a manual bag-label check may be acceptable for a small operation with a clearly assigned handoff person. If nobody can reliably label and check bags during peak service, ask for another supported workflow or reconsider that setup. Do not treat a connection as ready merely because an order appears on a screen.
Compare alternatives using the same test card for every location and channel. An existing POS connection or another provider may fit your process; what matters is the demonstrated path from source order to correct handoff. The guide to direct POS integration and middleware can help frame the broader connection decision.
Bring your channel list, POS details and two-order test cases to a Fleksa demo. Ask the team to walk through the identifiers and exceptions for your setup, and confirm availability for each restaurant location.
Frequently asked questions
Is a pickup name enough to verify a delivery order?
Not by itself. Similar names can appear at the same time. Match a distinctive identifier shared by the courier and restaurant, then use the name as a supporting check.
What if the POS number differs from the channel reference?
Ask how staff can trace one to the other. Record where both appear and who performs the lookup. If no reliable link is available, establish an acceptable manual process before rollout.
Should we test with a real courier?
Start with a simulation or mock walkthrough that cannot trigger a payment, guest message or dispatch. Treat a later live service pilot as a separate, controlled decision using the channel’s and restaurant’s normal procedures.
