When an online order does not appear in the POS, first determine whether the transfer actually failed or whether its status is simply unknown. Assign one person to investigate, compare the source order with the POS and kitchen records, and prevent automatic and manual recovery from creating two tickets for the same guest.
The distinction matters. A missing acknowledgment can mean the POS never received the order, but it can also mean the order was accepted and the confirmation did not return. Retrying immediately may send a second ticket. Waiting without an alert can leave a paid guest expecting food that nobody is making.
Before buying or changing an integration, agree on the alert, the person responsible, the fallback and the evidence needed to close an exception. Your procedure should cover the actual ordering channels, POS and kitchen workflow at each location.
Trace one order across every system
Start with an identifier that staff can use to follow an order from its source through the integration to the POS. Ask whether the original order ID is visible in the integration record, the POS ticket and any kitchen display or printed ticket. If different systems assign different IDs, record how they are linked.
There are three useful milestones:
- Created: The ordering source has a record of the order, its items, totals and payment status.
- Acknowledged: The receiving service has responded to the transfer. Ask exactly what its acknowledgment means: receipt by the integration is not necessarily acceptance by the POS.
- Accepted by the POS: A corresponding POS order exists with the expected items and status. Check the kitchen result separately; POS acceptance alone does not prove that a ticket reached the right station.
For each milestone, establish where staff can see the status and timestamp. Find out what happens when a response is late, an item or modifier is rejected, the POS is unavailable, or a connection drops after submission. Does the system alert someone, retry automatically, place the order in a queue, or leave a status that requires investigation?
Also ask how quickly an alert appears and where it goes during a busy shift. A dashboard warning is useful only if someone is watching it. Set an escalation time that fits your preparation workflow, and identify a backup when the shift lead is unavailable.
A restaurant POS and the ordering source may display different details. Train staff to compare the order ID, location, items, modifiers, total and payment status rather than relying on a guest name or similar-looking ticket alone. Keep access to order records limited to the people who need it.
Simulate a failed connection without affecting guests
Ask each provider for a test environment or vendor-supported test tools before attempting a failure scenario. Agree in advance on what the test can safely interrupt and how to restore normal settings. A practice scenario must not make a real card charge, send a guest message or dispatch a courier.
Use a unique test identifier and a small order that includes an item, a modifier and a total. Confirm that the test source order matches the POS and kitchen result. Then, using only a vendor-approved method, simulate a supported connection failure and observe what staff would see. Do not unplug production equipment or disable a live connection during service merely to see what happens.
Write acceptance criteria before the simulation:
- The test order can be traced by its unique identifier across the available records.
- The expected alert or exception status appears in the agreed place, within the agreed time.
- The responsible person can tell whether the POS accepted the order or whether the result remains unknown.
- Any supported retry or fallback produces one intended POS order and the correct kitchen result, with modifiers and totals intact.
- The log records who acted and how the exception was resolved.
Include an ambiguous-result scenario, such as a lost response after submission, if the vendor's tools support it. Ask how automatic retries interact with manual entry and whether staff can pause them. If a case is not supported, document the limit and decide whether the remaining fallback is workable for your restaurant.
A simulation is different from a live service pilot. After safe practice, a pilot can assess whether staff notice and handle real exceptions during a controlled service period. It should use normal customer-facing processes, named coverage and vendor support arrangements—not deliberately create a failure or send test orders into live dispatch.
When comparing restaurant integrations, check the connection status and availability for your specific location and setup. Fleksa's directory distinguishes live connections from those available on request. Confirm the actual ordering source and POS combination before making it part of your operating plan.
Use one owner and a defined manual fallback
Choose a primary exception owner for every shift, plus a backup. That person checks alerts, claims the exception in the log and coordinates with the kitchen. Others should know not to enter or retry the same order independently. A shared tablet, paper sheet or staff message can work if it makes ownership and status visible to the whole shift.
Before entering anything manually, the owner should check the source record, integration status, POS order list and kitchen queue. Search using the source ID and linked POS ID where available. If a matching order exists, inspect its status and contents rather than creating another one. If the records conflict or the result is unknown, pause and escalate according to the vendor's instructions.
If the order is confirmed absent and your procedure permits manual entry, first stop or account for any pending automatic retry. Ask the vendor how to do that safely. Enter the order once, including modifiers and fulfillment details, then record the new POS ticket ID against the original source ID. Tell the kitchen which ticket to prepare and whether an earlier ticket should be disregarded.
Keep payment status separate from order-entry status. A source order may already be paid even when it is absent from the POS. Confirm how the POS should represent that payment and who may correct a mismatch. Manual entry must not create a second charge. If payment status cannot be established, escalate rather than guessing.
For a restaurant online ordering workflow, also decide who contacts the guest if a delay or cancellation needs attention. Use the restaurant's normal communication process; do not assume that entering a POS ticket sends an appropriate update. For third-party orders, confirm which party handles guest communication and fulfillment changes.
Reconcile before a retry
Use this response tree whenever an order appears to be missing:
- Is there a matching POS order? If yes, check its status, contents and kitchen result. Correct or escalate any mismatch; do not create a second order just because the source still shows a warning.
- Is absence confirmed, and are retries controlled? If yes, the assigned owner can follow the agreed retry or manual-entry procedure, not both at once.
- Is the outcome unknown, or could an automatic retry still run? Pause manual entry and escalation-sensitive actions. Check with the responsible provider or follow its documented recovery procedure.
- After any action, does one intended order appear in the POS and kitchen workflow? Match the identifiers and details, record the outcome and close the exception only when the owner has verified it.
The table below shows a hypothetical reconciliation log for one order. It is an example of what to record, not a claim about any product's screens or retry behavior. The timestamps show the sequence; the final row records the cross-reference needed to prevent a later retry from being mistaken for a new order.
| Time and owner | Evidence | Decision | Next check |
|---|---|---|---|
| 6:10 p.m., shift lead | Source order D-418 created; transfer status unknown | Claim exception; do not enter a second ticket | Search POS and kitchen records |
| 6:12 p.m., shift lead | No match found; automatic retry may be pending | Pause manual entry and contact support under the agreed procedure | Confirm transfer outcome and retry status |
| 6:16 p.m., shift lead | Provider confirms no POS acceptance and retry stopped | Enter once under the manual fallback | Check items, payment status and kitchen ticket |
| 6:19 p.m., shift lead | POS ticket P-207 matches D-418; kitchen has one ticket | Record both IDs and close the exception | Review any later transfer alert against the log |
Keep unresolved entries visible across shift changes. A later status update may require another check, especially if a queued transfer was not actually stopped. Review recurring exceptions with providers: note the channel, location, time, failure point and resolution. The goal is a usable trail, not a long narrative during a rush.
Before choosing a recovery setup, read the guide to direct POS integration and middleware, then request a demo of Fleksa's integrations. Bring your ordering sources, POS details, alert requirements and safe test cases, including an unknown-status scenario.
Frequently asked questions
Should staff retry an order as soon as it is missing from the POS?
No. First check whether the POS accepted it and whether an automatic retry is pending. If the outcome is unknown, follow the escalation procedure rather than risking a duplicate.
What should a failed-order alert tell the shift lead?
At minimum, ask for an identifiable order, location, failure or unknown status, timestamp and a clear next action. Confirm where the alert appears and who is responsible for watching it.
How can a restaurant practice without affecting a real guest?
Use vendor-supported test tools and a unique test identifier. Agree on a simulation that cannot charge a real card, message a guest or dispatch a courier, and verify the resulting POS and kitchen records.
