To trace a delivery order, collect the reference shown by the ordering channel, the aggregator’s order ID, the POS order or check number, and any kitchen ticket reference. Add the restaurant location and order time. Those details give staff and support a way to find the same transaction even when each screen uses a different number.
Do not assume those identifiers match, appear everywhere, or can all be searched. Before buying or changing an integration, ask each provider to show how an order moves through your actual channel, location, and POS combination. The important result is a reliable path from one record to the next, including when something goes wrong.
Start with a safe order-tracing scenario
List the systems an order passes through at each location: the ordering channel, any aggregator or middleware, the POS, and the kitchen screen or printer. Some restaurants may have fewer steps. Others may use different connections for different channels. Draw the path that applies to the order you need to find, rather than treating the whole business as one setup.
Next, ask providers for a simulated or sandbox order that produces records in the relevant systems. Confirm the boundaries before starting: the simulation must not charge a real card, send a guest message, or dispatch a courier. If a provider cannot create records in one system without those effects, leave that step untested in the simulation and ask how it can be checked safely.
A live service pilot is different. It involves an actual operating order and should be arranged separately with the providers and staff, using their approved procedures. Do not describe a simulation as proof that a live delivery or payment succeeded.
For the scenario, use a distinctive test marker if the systems allow one, a location, an order time, and a simple item with a modifier. Record the expected item, modifier, and total. The marker helps you recognize the test; it is not necessarily an order ID or a field support can search. Avoid using a real guest’s name, phone number, address, or payment details.
Before the demonstration, write down what you need to see: the source order, the corresponding aggregator record, the POS result, and the kitchen result where applicable. Also identify what remains unknown. For example, can a staff member search the channel reference in the POS, or must support use an internal lookup? A screen that displays a number does not necessarily make it searchable.
Build a cross-system identifier map
The following is a hypothetical order map. The references are invented and do not describe any particular provider’s fields. They illustrate what to collect, not a promise that a system will display or search each value.
| System | Example reference | What it identifies | Question to resolve |
|---|---|---|---|
| Ordering channel | CH-4816 | The order as shown at its source | Can staff copy the full reference? |
| Aggregator | AG-9027 | The aggregator’s record of that order | Does it display CH-4816, and can either ID be searched? |
| POS | POS-3174 | The corresponding POS order or check | Which source or aggregator reference, if any, appears here? |
| Kitchen ticket | KT-063 | The kitchen-facing ticket, if one is created | Can staff connect it back to POS-3174? |
Read the table as a chain, not a list of interchangeable numbers. The useful evidence is the link between neighboring records: CH-4816 to AG-9027, then AG-9027 to POS-3174, then POS-3174 to KT-063. If a link is missing, note who can bridge it and what information they need.
A short ticket number may be convenient at the pass but insufficient on its own for support. Ask whether it is unique across locations and dates, whether it is reused, and whether it changes after a reprint or update. Keep the full reference exactly as displayed, including letters and leading zeros. Do not substitute a menu item identifier for an order identifier: an item code identifies what was ordered, not the individual transaction.
The location and timestamp narrow a search, but they are supporting details rather than proof of a match. Confirm the time zone and whether the displayed time means order placement, acceptance, or another event. If two orders look similar, use the linked references and order contents to distinguish them.
For each connection, ask the vendor to demonstrate the exact route your restaurant plans to use. Fleksa’s restaurant integrations directory distinguishes live connections from those available on request. For a particular channel, review the relevant page, such as the Uber Eats integration, then confirm availability and setup for your location and POS. A listing alone does not establish which identifiers flow through your setup.
Check searches, handoffs, and exceptions
Run the simulated scenario with the people who would handle it during service. Give one person the channel reference and ask them to locate the matching aggregator record. Give another the aggregator reference and ask them to find the POS order. Finally, ask the kitchen lead how they would connect the ticket to the POS record. Keep the scenario in a safe simulation; no real payment, guest message, or courier dispatch should result.
For each step, record both the expected result and what was actually observed. For example, the expectation might be: “Searching the aggregator for CH-4816 returns AG-9027.” The observation might be a matching record, no result, or a lookup that only support can perform. If a step was not run, mark it as not tested rather than treating it as a failure or a pass.
Check the order content as well as the references. Does the matching POS or kitchen result contain the expected item and modifier? Does the displayed total match the simulated source order? If not, preserve the identifiers and describe the difference. A correct ID match does not prove that the order details arrived correctly.
Then ask how the proposed setup handles exceptions it claims to support. Examples include an order that is not accepted, an update, a cancellation, or a record that appears in the aggregator but not the POS. Ask where staff would see the status, which identifier they should provide, and who owns the next action. An intentionally unsupported case is a limitation to document, not an automatic failure. Decide whether the resulting manual work is acceptable for your operation.
Separate actions a shift lead can perform from those requiring vendor support. A workable process might let staff search a channel ID directly; another might require them to copy it into a support request. Either can be usable if the steps and response expectations fit your service. Ask for a demonstration rather than assuming a restaurant POS system can search every upstream reference.
Make a support record and a buying decision
Create a short handoff template that staff can complete while the order is still current. It should travel with the issue across teams without becoming a copy of the guest record. Include:
- Restaurant location, channel, date, approximate time, and time zone.
- The full channel, aggregator, POS, and ticket references available, each labeled by system.
- The last confirmed match and the point where the trail stops.
- Expected versus observed status or order details, without unnecessary guest information.
- The action already taken, the person responsible, and the next decision or response needed.
For the hypothetical map above, a useful handoff could say: “Location A; channel order CH-4816 matches aggregator AG-9027; POS match not yet confirmed. Shift lead to ask aggregator support for the POS reference.” If the POS record is later found, add POS-3174 and the evidence linking it. Avoid sending a guest name, address, phone number, or payment information unless a provider establishes that a specific detail is needed through an appropriate support channel.
Use the completed map to compare your options. Suppose one setup lets staff search the channel reference in the aggregator, while another requires a support lookup. If both otherwise meet your needs, the first may be easier during a busy shift. If the searchable route is unavailable for your POS or location, weigh the support handoff against the staff time and delay your restaurant can tolerate. Ask for written operating and support terms rather than assuming either route is faster in practice.
Assign each open question to a named role: for example, the POS provider confirms what appears on its order screen; the aggregator confirms cross-reference searches; the restaurant manager decides whether a manual lookup is acceptable. Set a date for each answer and a decision point. If a critical link cannot be demonstrated or assigned a practical workaround, keep it open before committing to the setup.
For a broader comparison of connection approaches, see the related buying guide. To take the next step, bring your channel list, locations, POS details, and safe test cases to a Fleksa demo. Ask which connections are available for your location and have the team walk through the identifier map.
Frequently asked questions
Is the channel order number the same as the POS number?
Not necessarily. Each system may assign its own reference. Record both and ask how staff or support can verify the link between them.
What if the kitchen ticket has only a short number?
Record it with the location, date, time, and POS reference where available. Ask whether the short number is reused and how to trace it back to the full order.
Can we check an integration without placing a live delivery order?
Ask for a sandbox or simulation that avoids real card charges, guest messages, and courier dispatch. Record any steps it cannot cover, and arrange a separate live service pilot if needed.
