When order numbers repeat across channels or locations, check whether staff can identify each order without relying on the number alone. A workable policy records the original number with its source, location, and order date and time. It also gives staff a reliable way to find the matching transaction in reports and support conversations.
The important question is not whether a guest-facing number ever repeats. It is whether two different orders can be mistaken for one another. Test that question before you change a numbering convention or buy software. Short numbers may be convenient for staff, but they need enough context behind them to support refunds, reports, and investigations.
Map the identifiers each channel supplies
Start with one recent example from every way an order enters the business: direct online ordering, a marketplace, the point of sale, phone orders entered by staff, and any other active source. Include every location. For each source, write down the identifier shown to the guest, the identifier shown to staff, and any reference that appears in reports or payment records.
These identifiers may serve different purposes. A short order number can help a team find a ticket during service. A longer transaction reference may be needed to trace a payment. A marketplace may give an order its own reference while the restaurant system assigns another. Do not assume those values match or that one can replace the other.
For each identifier, ask the channel provider or software vendor:
- Who creates it, and at what point in the order flow?
- Where does it appear: ticket, staff screen, guest confirmation, export, or payment record?
- Is it unique within a location, channel, business account, or another defined scope?
- Can staff search the original reference, including any letters or leading zeros?
- Does the reference change when an order is edited, canceled, refunded, or sent again?
Also record what happens when a channel sends an order to another system. Can the receiving system retain the source reference alongside its own? If a staff member has to copy it manually, note where that happens and who checks it. A field that exists only on a printed ticket will not help much when someone searches an export next week.
If you are reviewing the direct channel as well, the online ordering buying guide covers broader system questions. For numbering, keep the focus on how each order can be traced after it leaves the ordering screen.
Check resets and overlaps before setting a policy
A number can repeat because a counter resets, because different channels use separate counters, or because locations issue numbers independently. Ask when each counter resets and which time zone controls the reset. Check whether a business day runs past midnight for late service. A date without a time zone or business-day rule can make an overnight order harder to place.
Consider this hypothetical: a restaurant has two locations, Harbor and Market. On the same date, Harbor receives direct order 42 and marketplace order 42. Market also receives direct order 42. There are three orders, not three versions of one order. A record labeled only “42” cannot tell a manager which one needs attention.
A practical staff reference might combine location, source, order date and time, and the original number: “Harbor / direct / Nov. 10, 7:15 p.m. / 42.” Keep the original source reference intact as a separate field where possible. If a channel supplies a longer reference, retain that too; adding a readable label should not erase the identifier the channel's support team needs.
Even that combination is only as reliable as its inputs. If a source can issue the same number twice at the same location and time, ask what additional reference distinguishes the orders. Avoid treating a made-up label as a guaranteed unique key. The vendor should explain the actual uniqueness scope and how duplicate submissions are represented.
There is a trade-off. A short number is easy to read during a rush; a longer reference is more useful when researching an order later. You do not necessarily need staff to announce a long code. You do need the complete context available on the staff record and in the places used for reconciliation.
Put location and channel context in staff records
Agree on a minimum record before deciding how the number should look. At a minimum, staff should be able to see the location, originating channel, order date and time, and original order number together. Add the receiving system's reference and the payment or marketplace reference when those are relevant and available.
Check the record at each handoff. Does the kitchen or service team see enough context to distinguish tickets? Can a manager open the same order later? Does an export preserve the source and location in separate, usable fields? Can the person handling a refund connect the order to the right payment without guessing from the amount?
Decide which date staff should use when talking about an order placed before midnight for later fulfillment. Record both the order time and the scheduled fulfillment time when available, and label them clearly. They answer different questions. A guest may remember the pickup date while a channel's support team searches by the order date.
Keep sensitive information out of a general-purpose identifier. A name or phone number can help an authorized employee locate an order, but it should not be the only way to distinguish transactions or be copied into every ticket and report. Set access and retention rules with the people responsible for the restaurant's systems.
If direct orders arrive through a restaurant website, include that path in the map. If you compare direct and marketplace activity, the related buying guide can help with the separate commercial comparison. A numbering policy should make the records traceable regardless of which channel produced them.
Run an order identifier collision test
Use the following sheet as a simulated exercise with fictional records. It tests whether staff can distinguish orders and carry the right references into a support handoff. These rows are assumptions for the exercise, not claims about any vendor's software.
| Scenario | Fictional records | Check | Pass condition |
|---|---|---|---|
| Same number, two channels | Harbor direct 42; Harbor marketplace 42, same date | Search for 42, then narrow by source | Both records appear or can be found, and source clearly separates them |
| Same number, two locations | Harbor direct 42; Market direct 42, same date | Search across locations, then filter | Staff can identify the correct location without opening an unrelated order by mistake |
| Number after a reset | Harbor direct 42 on two different order dates | Search using the number and order date | Both records remain distinguishable with the recorded date and time |
| Support handoff | Harbor marketplace 42 with source reference M-814 and local reference L-265 | Prepare a handoff for the channel and the local system | The handoff identifies the location, source, date, and both relevant references |
The first three rows check different collision boundaries: channel, location, and date. The final row checks whether a person can carry the right identifiers between systems. If a search returns several matches, that can still pass as long as staff can distinguish and select the correct record reliably.
For each row, note the screen or report used, what the staff member searched, and whether the result contained enough context. Also check whether an export preserves the identifiers and whether a canceled or edited order remains traceable. If the system cannot use fictional records, ask the vendor to demonstrate with its own safe test data.
Keep the exercise separate from live service. Use a sandbox or a vendor-provided demonstration that cannot create a real charge, send a guest message, or dispatch a courier. Do not enter a real card or contact a guest for the exercise. A later live pilot is a separate decision: agree on its scope and safeguards with the vendor and staff before any real orders are involved.
If a row fails, document the operational consequence. A missing channel filter may mean staff must open several records. A missing source reference may mean a support case cannot be matched promptly. Ask whether the gap can be addressed through configuration, an export, or a documented staff procedure, and check any quoted setup or ongoing cost before accepting the workaround.
Next, run the sheet against your current setup and take the failed rows to your vendor. If you are evaluating Fleksa's restaurant online ordering, ask which identifier fields and search options are available for your setup and confirm current US availability.
Frequently asked questions
Must every order number be globally unique?
Not necessarily. A repeated short number can work if the full record reliably distinguishes each order and staff can search it. Ask the provider to define the scope in which each identifier is unique.
Should a restaurant replace a marketplace's order reference?
Keep the original reference available even if the restaurant uses another internal number. The source reference may be needed when discussing that order with the channel's support team.
What should staff include in an order support handoff?
Include the location, originating channel, order date and time, original order number, and any relevant source and receiving-system references. Confirm which date and time zone the recipient uses when searching.
