When online ordering fails, switch only to a channel your team can monitor and fulfill. If the public page or checkout is broken, pause online orders if possible and direct guests to a staffed phone line. If orders are still going through but notifications fail, assign someone to monitor the order dashboard or pause ordering until staff can see incoming orders reliably.
In either case, one person should own the decision, staff should record every fallback order, and the manager should reconcile orders and payment status before normal service resumes. A phone is not a safe fallback if nobody can answer it or the kitchen is already at capacity.
Identify what failed and assign an owner
The shift manager should take charge as soon as someone reports a problem. Give that person authority to pause a channel, limit the menu, contact the provider, and tell the team when the procedure changes. If the manager is unavailable, name a backup before the shift starts.
First check whether the problem affects the guest, the restaurant, or both. Use the following decision tree to choose an immediate response. The checks should not involve placing a real order or charging a card.
| What staff can observe | Immediate response | Owner's next check |
|---|---|---|
| The public ordering page will not load | Pause online ordering if possible; offer a staffed alternative. | Check the page from another device or connection and contact the provider. |
| The menu loads, but checkout fails | Stop directing guests to checkout; take new orders by an available fallback. | Ask affected guests whether they received confirmation or a payment notice before taking another order. |
| Guests can order, but alerts are missing | Monitor the order dashboard continuously if it is accessible; otherwise pause the channel. | Compare visible incoming orders with the kitchen queue and investigate the notification failure. |
| Staff cannot tell what succeeded | Pause the affected channel and record uncertain orders for review. | Check the order and payment records before promising a replacement or collecting payment again. |
A page loading on one staff phone does not prove that checkout or notifications work. Likewise, a quiet printer does not prove there are no incoming orders. Check the actual order view, if available, rather than waiting for an alert. Record the time the problem was reported and the time each action was taken; that gives the team a starting point for recovery.
Contact the provider with the page address, the affected location, the approximate start time, and a description of the failure. Avoid sharing full card details or other sensitive payment information in an email or support chat. The manager should also decide how often staff will check for updates rather than having several people contact support independently.
Choose a fallback the team can actually run
A staffed phone line is a useful default for pickup when the ordering page is unavailable. Write down the phone number, who answers it, and where orders go next. If the line is busy or unattended, do not advertise it as an ordering option. Walk-in ordering may be an alternative, but only if the team can handle the extra counter traffic.
For delivery, accept an order only when you have a workable way to arrange delivery and can give the guest a realistic estimate. A restaurant's direct ordering channel and its delivery arrangements are separate decisions. If dispatch is unavailable, offer pickup instead of promising a driver you cannot arrange.
Set limits before calls pile up. The manager might restrict the fallback to a smaller menu, stop taking orders for a busy pickup window, or decline delivery beyond the area the available driver can cover. Tell the kitchen about those limits immediately. A fallback channel should reduce confusion, not create a second queue that nobody owns.
Post a short notice wherever staff can update guest-facing information, such as the restaurant website or a recorded phone greeting. Include the affected service, the available alternative, its hours, and any limits. For example: Online ordering is temporarily unavailable. Please call our restaurant during service hours for pickup orders. Delivery is temporarily unavailable. Remove or update the notice when the situation changes.
Give staff one instruction for guests who say they already ordered: do not automatically enter a replacement. Take the guest's name, approximate order time, and a safe callback number, then check the order and payment records. If the status cannot be verified promptly, explain that uncertainty and agree on a next step rather than suggesting the original definitely failed.
Keep a manual order log
Use one shared paper log or a single controlled document, with one person responsible for maintaining it on each shift. Separate scraps of paper make it difficult to see whether an order is new, being prepared, or already handed over. If staff use a document, make sure they can access it during the outage; keep a paper version available if connectivity is the problem.
For each order, record:
- A unique log number, time received, staff member, guest name, and callback number.
- Items, modifiers, quoted total, promised pickup time or delivery details, and any fulfillment limits agreed with the guest.
- Order source and status: awaiting verification, accepted, sent to kitchen, ready, fulfilled, or canceled.
- Payment status using clear labels such as unpaid, paid and verified, or payment uncertain. Record a transaction reference if available, not full card details.
Mark changes with a time and initials. When an order goes to the kitchen, use the log number on the kitchen ticket and mark it sent. When it is collected or delivered, mark it fulfilled. If an order is canceled, record who confirmed the cancellation and whether payment still needs review. Keep the log away from public view and handle guest details under the restaurant's normal data practices.
Consider this hypothetical outage: a guest calls at 6:10 p.m. after checkout appeared to freeze. The manager records the request as awaiting verification, rather than sending it to the kitchen. At 6:15, the manager finds a matching order and a verified payment in the available records. Staff then prepare that existing order and tell the guest its expected pickup time. They do not enter a second order or collect payment again.
If no matching record is visible, that alone may not settle the payment question. Check the payment view or provider guidance available to the restaurant. If the status remains uncertain, keep the order flagged and agree with the guest on whether to wait or use another arrangement. A payment notice, an accepted order, and a completed meal are different events; the log should not treat them as interchangeable.
Reconcile before reopening normal ordering
When the page or notification service appears to recover, the shift manager should keep the fallback log open while checking the affected period. A working page is a reason to investigate, not proof that every order reached the kitchen.
- Collect the records. Gather the manual log, available online order records, kitchen tickets, cancellation notes, and payment records for the outage window. Include the period just before the reported failure in case detection was delayed.
- Match each order. Compare guest name, time, items, amount, and any order or transaction reference. Mark whether it was accepted, prepared, fulfilled, canceled, or still uncertain. Investigate possible duplicates before sending anything else to the kitchen.
- Resolve exceptions. Assign an owner to each unmatched order or uncertain payment. Contact a guest when needed to confirm the order's status. Follow the restaurant's payment-provider procedures for any correction; do not promise a refund or reversal until its status is known.
- Confirm capacity and hand over. Make sure the kitchen and the person monitoring incoming orders know which channel is active. Remove the outage notice, close or transfer the fallback queue, and brief the next shift on unresolved items.
Reopen normal ordering only when staff can reliably see and act on new orders. If the page works but alerts still fail, the manager can keep a staffed dashboard watch only if that is practical for the whole service period. Otherwise, keep the affected channel paused while the issue is resolved. Continue logging exceptions until the team has accounted for them.
Prepare the fallback before service
Put the decision tree, provider contact details, notice wording, manual log, and manager backup in one place staff can reach without relying on the ordering page. During training, walk through a simulated page failure, a frozen checkout, and a missing notification. Use fictional guest and payment details. The practice must not place an order, charge a card, send a guest message, or dispatch a courier.
After the simulation, ask staff where they would check an uncertain payment, who can pause ordering, and how the kitchen receives a fallback ticket. If you later run a live service pilot of a fallback process, set its scope and ownership separately; do not treat a simulation as proof that live systems, payments, or delivery arrangements work.
When evaluating restaurant online ordering, ask the provider how staff pause orders, view incoming orders when alerts fail, access payment status, and contact support during service. Also ask how a restaurant website notice can be updated during an interruption. The online ordering guide can help with the broader buying decision.
For budget context, Fleksa's Fix plan is listed at $199 per month per location, with 0% Fleksa commission on direct online orders. Processing, delivery or dispatch, hardware and add-ons, and applicable sales tax are extra. See Fleksa plans for pricing checked in November 2026, and request a current quote for the setup you need.
Next step: Review Fleksa's ordering system and, if it fits your restaurant, request a demonstration of the outage and recovery steps your staff would use.
Frequently asked questions
Should we keep online ordering open if notifications fail?
Only if someone can reliably monitor incoming orders through another available view and the kitchen can act on them. Otherwise, pause the affected channel and offer a fallback the team can manage.
What if a guest says they paid but staff cannot find the order?
Record the details and flag the order and payment as uncertain. Check available order and payment records before creating a replacement or collecting payment again. Agree on a next step with the guest if verification takes time.
When can we return to normal ordering?
Return when staff can reliably receive and fulfill new orders, the team knows which channel is active, and unresolved outage orders have assigned owners. Keep tracking exceptions until they are resolved.
