Before signing for a restaurant integration, ask for two answers in writing: how long does it keep retrying a failed order, and how will your restaurant know when it stops? Then ask who owns the next step. A retry limit is only useful if someone can see the failure and act before the guest is left waiting.
There is no single retry period to assume across providers. The answer may also vary by ordering channel, POS, failure type and location. Bring the vendor a list of the systems you actually use, and ask it to describe the path from the source order to the POS and kitchen.
Ask what triggers a retry
Start with a simple distinction: an order may be delayed because the receiving system has not acknowledged it, or it may have been rejected with an explicit error. Those situations need different responses.
For example, an integration sends an order to a POS but does not receive an acknowledgement. The order might not have arrived, or it might have arrived while the response was lost. Sending it again without a way to identify the original can create a duplicate. Ask how the integration checks the outcome before another attempt and what identifier staff can use to trace the order.
A rejection is different. The receiving system may respond that it cannot accept an item, modifier or other part of the order. Waiting and sending the same information again may not fix that problem. Ask which rejections can be retried, which stop immediately, and what information the restaurant receives about the reason.
Use these questions in the vendor conversation:
- What events start a retry: a timeout, an unavailable connection, an error response, or something else?
- How do you distinguish a missing acknowledgement from a confirmed rejection?
- What happens if the POS accepted the order but the acknowledgement never came back?
- Which errors need a correction rather than another automatic attempt?
- Can an order be accepted by the source channel while still absent from the POS or kitchen? How would staff see that state?
Ask for the answer for each connection you plan to use. A diagram is helpful if it names the source, any intermediary, the POS and the final kitchen destination. The related buying guide can help you decide where an intermediary belongs in that path.
Compare retry limits and queue visibility
A retry policy has more than one limit. A vendor might stop after a period of time, after a number of attempts, or when a particular error appears. Ask which limit takes precedence and when the clock starts. Also ask whether a pause or outage changes the timer, and whether the schedule differs during a busy service.
Get a clear definition of the states your team will see. “Pending,” “retrying,” “delivered” and “failed” can mean different things in different systems. In particular, ask whether “delivered” means the POS acknowledged receipt or whether it also confirms a kitchen ticket. Do not treat those as the same milestone without an explanation.
Use the worksheet below to record answers for each connection. The entries describe what to request, not standard vendor settings.
| Question | Record for each connection | Why it matters |
|---|---|---|
| When do retries stop? | Maximum duration, attempt ceiling, and any immediate-stop errors | Shows when automatic recovery ends |
| What can staff see? | Order ID, current state, last error, attempt history and age, if available | Helps staff find an order before it is overlooked |
| How is give-up reported? | Channel, recipient, timing and what the alert contains | Shows whether the alert reaches someone on shift |
| Who resolves it? | Restaurant role, vendor support contact and reconciliation steps | Prevents two teams from each assuming the other owns it |
Ask where the queue is visible: on a restaurant-facing screen, in a support tool, or only through a notification. Can a shift lead filter by location and see orders that have waited longer than expected? Can staff tell whether an order is still retrying or has permanently failed? If details are restricted to support staff, agree on how quickly the restaurant can obtain them.
Visibility should extend beyond the final failure. An alert after retries end may be too late for a time-sensitive order. Ask whether the system can flag an order that is aging in the queue and whether the restaurant can set or request a useful threshold. A vendor may offer a different method; the buying question is whether staff can identify and act on a stuck order in time.
Finally, ask what happens after a connection returns. Does the queue resume automatically? Can old orders still be sent after their intended preparation time? Who decides whether to resume, cancel or handle an order manually? The right answer must fit your kitchen’s workflow, not just the integration’s technical recovery process.
Define who responds when retries end
A give-up notification needs an owner. Ask the vendor to name the notification channel, recipient and support route for each location. An email to an unattended office inbox may be technically delivered but still miss the person running dinner service. If the alert goes to a dashboard, decide who watches it and how often.
Request an example alert. It should let the recipient find the source order and understand what to check next. Ask whether it includes the location, source channel, order identifier, time, failure state and a useful error description. Also ask whether an alert is sent only once, whether unresolved failures remain visible, and how staff can tell that someone has taken ownership.
Divide the response into named jobs:
- Find the order. A designated restaurant employee checks the source order and its status.
- Check the destination. Before entering or sending anything again, that employee checks the POS and kitchen for the same order identifier and details.
- Choose the next action. Follow the agreed procedure for manual entry, cancellation or escalation. Confirm who is authorized to make that choice.
- Reconcile the result. Record what happened in the relevant systems and make sure the source order is not left in an unresolved state.
Ask who contacts the guest or ordering channel when a problem affects fulfillment. That responsibility may depend on the source and the restaurant’s agreement with it. Do not assume the integration vendor, channel or restaurant will do it automatically. Similarly, establish who contacts support, which support team takes the first call and what information to provide.
For a multi-location operator, make the assignment by location and shift. A central manager can own the vendor relationship, but the person who notices a failure during service may be a local shift lead. Write down a backup for breaks, shift changes and overnight orders.
Test permanent failures before signing
Ask the vendor to demonstrate the retry and give-up path for the exact combination of channel, integration and POS you are considering. Agree on the expected states and notifications first. A simulation should use a safe test environment or an explicitly controlled test mode. It must not charge a real card, send a guest message or dispatch a courier.
Hypothetical example: A test order has a unique identifier, one sandwich and a modifier. The vendor simulates a destination that cannot accept the order. Before the demonstration, agree that staff should be able to identify the order, see whether it is retrying or has stopped, and find the designated give-up notice. If a particular error is supposed to stop immediately rather than retry, record that as the expected behavior.
Walk through the event in order. First, find the test identifier at the source. Next, inspect the integration status and any available attempt history. When the simulated failure reaches its stated limit, check the alert recipient and the information shown. Then walk through the restaurant’s reconciliation procedure without creating a live order. Compare the source details with the simulated POS or kitchen result, including the modifier and total.
For a separate delayed-acknowledgement simulation, ask the vendor to show how staff determine whether the order already reached the destination before any repeat submission. Match the same unique identifier across the source and destination. This is a practical check against duplicate preparation; it is not proof that every possible failure will be prevented.
Close the demonstration with these questions:
- What exact event ended the retries, and did it match the written policy?
- Could the intended person find the order and understand what to do next?
- Where was the final status recorded, and could another shift see it?
- If staff cannot resolve the issue, what is the support escalation path?
- Which scenarios are unsupported, and what manual fallback should the restaurant use?
A simulated check is not a live service pilot. If you later run a live pilot, agree on its scope, staffing, monitoring and fallback with the vendor first. A real order can involve a guest and payment or delivery arrangements, so do not use an uncontrolled failure as a practice exercise.
Before your next vendor meeting, choose one actual order path and take the worksheet with you. Discuss its retry limits, alerts and responsibilities with your POS provider; you can also review Fleksa’s restaurant integrations and integration questions as you prepare.
Frequently asked questions
How long should an integration retry a failed order?
There is no universal duration to assume. Ask for the time limit, attempt ceiling and any errors that stop retries immediately, then decide whether that policy fits the timing of your service.
Does a retry mean the original order never reached the POS?
No. A missing acknowledgement can leave the outcome uncertain. Check the source identifier against the POS and kitchen before submitting or entering the order again.
What should a give-up alert tell the restaurant?
Ask for the location, source, order identifier, failure state and next action, along with a clear recipient and support route. Confirm that someone on the relevant shift will see it.
