One person on each shift should own unresolved online ordering exceptions from the moment they are noticed until they are resolved or formally handed over. In many restaurants, that person is the shift manager. A trained backup should take over when the manager is unavailable. Kitchen, front-counter, and delivery staff still fix issues within their roles, but the owner keeps the order from disappearing between them.
An exception is an order that needs attention because its expected path has stalled or become uncertain. An accepted order that never appears on the kitchen screen is one example. An order marked ready but not collected is another. The owner does not have to perform every fix; they must know the next action, who is doing it, and when to check again.
This is different from routing a guest complaint. A guest may report a problem, but an internal exception can exist before anyone complains. Your team needs a way to find and resolve it without waiting for a call.
Map the states where an order can get stuck
Start with the actual path an order takes at your restaurant. Ask the person who sets up ordering to walk through acceptance, kitchen receipt, preparation, packing, handoff, and completion. Include the tools staff use along the way, whether that is a screen, printer, phone, or delivery dashboard.
At each step, write down what staff expect to see and what would tell them the next step has not happened. Useful exception states include:
- Accepted but not received by the kitchen: The order appears in the ordering system, but staff cannot find it on the usual kitchen device.
- Received but not started: The kitchen has the order, but it has not entered preparation within your chosen window.
- In preparation but blocked: An item is unavailable, details are unclear, or equipment is preventing completion.
- Ready but not handed off: The packed order is waiting for the guest or a delivery driver.
- Status uncertain: Two screens disagree, or staff cannot tell whether an action already happened.
For each state, identify the source of the signal. Is there an alert, a status on a screen, a printed ticket, or a manual check? Ask your provider which alerts exist, who can receive them, whether they repeat, and what happens when a device or connection is unavailable. Do not assume an alert reaches the person best placed to act.
The kitchen lead can explain normal preparation times and bottlenecks. The person managing pickup or delivery can describe handoff delays. Your ordering provider can explain available statuses and alert settings. The shift manager can identify when the team is too busy to watch another screen. Put those answers together before selecting a time limit.
When comparing restaurant online ordering options, ask for a walkthrough of a stalled order, not just a successful checkout. Can staff find the order, see its current status, and tell whether someone has already acted? If your restaurant website sends orders into a separate workflow, include that handoff in the map.
Assign a shift owner and a named backup
Choose the owner by availability and authority, not job title alone. The right person can see the relevant order information, reach the kitchen and handoff staff, and decide when to escalate. If a manager spends most of the rush cooking on the line, a front-counter lead may be better placed to monitor exceptions. The manager can remain the escalation contact.
Assign the backup by name on the shift roster. “Anyone at the counter” leaves an opening when everyone assumes someone else is watching. At the start of service, the owner and backup should know where to find open issues and who has authority to contact the provider or make a guest-facing decision.
The following hypothetical matrix shows how a small restaurant might divide responsibility. Its time windows are operating assumptions, not vendor defaults or promises. The owner keeps the issue moving; the action person handles the immediate work.
| Exception | Owner / backup | First action | Escalate if unresolved |
|---|---|---|---|
| Accepted order missing from kitchen view | Shift manager / counter lead | Counter lead checks the order record and confirms with kitchen before re-entering anything. | After 3 minutes, manager contacts the person responsible for the ordering setup. |
| Order blocked in preparation | Shift manager / counter lead | Kitchen lead explains the blocker and the available options. | After 5 minutes, manager decides the next operational step. |
| Ready order not collected | Counter lead / shift manager | Counter lead checks the pickup details and current handoff status. | After 8 minutes, manager decides whether to contact the guest or delivery provider. |
| Conflicting order statuses | Shift manager / counter lead | Manager checks with kitchen and handoff staff before changing a status. | After 3 minutes, manager contacts the ordering support channel. |
The different windows reflect different risks. A missing kitchen order may never be prepared unless someone intervenes quickly. A ready order may reasonably wait a little longer, depending on the promised pickup time and delivery arrangement. Adjust the windows for your service, and define when the clock starts: for example, when the order is accepted, when a blockage is discovered, or when the order is marked ready.
Keep access and authority separate. Someone may be able to view an order but not cancel it, change a delivery arrangement, or approve a refund. Decide who can make those decisions and how staff reach that person. If the owner cannot act, the exception still needs an owner who follows up.
Set acknowledgment and escalation rules
A time limit is useful only if someone notices it. Set one target for acknowledging an issue and another for escalating an issue that remains unresolved. Acknowledgment means a named person has seen the exception and recorded the next action. It does not mean the order is fixed.
For the hypothetical missing-kitchen-order case above, the team might use this sequence:
- The order is accepted at 6:10 p.m. and is not visible to the kitchen. The counter lead records the issue and tells the shift manager.
- By 6:11 p.m., the manager acknowledges ownership and asks the counter lead to check the order record and confirm whether the kitchen has received it another way.
- At 6:13 p.m., if the issue is still unresolved, the manager contacts the person responsible for the ordering setup. The manager remains the owner while that person investigates.
- Once the team confirms the correct next step, the manager records the outcome and checks that the kitchen and handoff staff have the same understanding.
If the manager has not acknowledged the issue by the one-minute target, the counter lead becomes the temporary owner and contacts the manager or designated escalation contact. A backup needs permission to begin the next step, not merely permission to wait.
Avoid fixing uncertainty by blindly entering the order again. First check whether the kitchen has already received or started it. Duplicate work can create a second problem while staff are trying to solve the first. Likewise, do not mark an order complete simply to clear a screen; confirm the actual handoff under your restaurant's procedure.
Practice the sequence using a simulated order and a paper or isolated practice record. Tell the team in advance that it is a simulation. Do not submit a real card payment, send a guest message, or dispatch a courier. Check whether the owner notices the issue, acknowledges it, and reaches the backup at the intended time. A simulation can expose an unclear role; it cannot prove the live system will behave the same way during service.
For a live service pilot, use normal customer orders and normal permissions. Observe the workflow without deliberately withholding an order, blocking preparation, or triggering a needless guest message or courier dispatch. Review naturally occurring exceptions afterward. If none occur, you have learned about monitoring coverage, not how the team handles a real failure.
Review open exceptions before handover
An unresolved issue should not become ownerless when a shift ends. Build a short handover into the roster, and keep a shared exception record that incoming staff can access. Use only the guest and order details needed for the task, following your restaurant's handling procedures.
For each open exception, record the order reference, current state, time discovered, named owner, actions already taken, next action, and next check time. Include the contact or support reference if someone outside the shift is investigating. Mark the issue closed only when the responsible person has confirmed the outcome, not when the first message has been sent.
The outgoing owner should review each open item with the incoming owner. The incoming person accepts responsibility and repeats the next action and check time. If no one is available to accept the handover, escalate to the manager rather than leaving the record as the only notice.
Review the matrix after a busy shift or a recurring problem. Look for exceptions that waited without acknowledgment, backups who lacked access, and time windows that created unnecessary interruptions. Ask whether the signal was missing or whether the team missed a signal that already existed. Those are different problems and may need different fixes.
Before buying or changing software, use this matrix as a checklist. Ask a provider to show how staff would find and track each relevant state, and ask what remains a manual responsibility. The online ordering buying guide can help with the wider selection. Then ask Fleksa about its ordering setup and verified US availability for your location.
Frequently asked questions
Should the kitchen own every ordering exception?
No. The kitchen should own preparation tasks it can control, but a shift owner should coordinate issues that cross ordering, preparation, and handoff. That person follows up until the issue is resolved or handed over.
What if no alert is available for a stalled order?
Assign a manual check to a named person and set a realistic frequency. Ask the provider whether a suitable status or alert is available, and review whether the manual check can be maintained during a rush.
When should an exception be closed?
Close it when the owner confirms the agreed outcome and records any necessary handoff details. Sending a support request or telling another employee about the problem is not, by itself, resolution.
