Staff should review phone orders before kitchen release when that review catches problems your team can reliably act on without making guests wait too long. If orders are straightforward and someone can fix exceptions after release, automatic release may be the better fit. The decision depends on who owns the queue, what they check, and what happens when they are busy.
Approval is a specific step between a guest submitting an order and the kitchen receiving it. A screen that merely shows staff the order is not necessarily an approval queue. Ask each vendor to demonstrate whether an order can be held, reviewed and deliberately released, and what the guest sees while that happens.
Map the order from phone to kitchen
Start with the path an ordinary order takes. A guest scans a code, identifies the table if needed, selects items and submits the order. Depending on your setup, payment may happen before or after a staff decision. In an approval workflow, a designated employee then checks the order and releases it to the kitchen. In an automatic workflow, the order goes to the kitchen without that separate decision.
Write down the exact event that counts as kitchen release. Is it an order appearing on a kitchen screen, a ticket printing, or something else in your setup? Also establish whether the kitchen sees held orders at all. Visibility alone does not mean the kitchen should start preparing them.
Use this fictional acceptance test for a small table-service restaurant. The restaurant wants a server to check table identity and item availability before release. A shift lead is the backup reviewer. The owner sets a target of one minute from submission to review and a maximum acceptable delay of two minutes. Those are management choices for this example, not recommended universal limits.
Run the scenarios in a vendor-provided demo or isolated practice environment. Use fictional tables and items. Confirm first that the setup cannot take a real payment, send a guest message or dispatch a courier. If the vendor cannot isolate an action, inspect the relevant screen or ask for a demonstration rather than triggering it.
| Scenario | Expected result | Responsible role | Exception to resolve |
|---|---|---|---|
| Normal order | Order is held until reviewed, then appears at the kitchen destination with the correct table and items. | Assigned server | If it appears before approval, confirm whether holding is supported and configured. |
| Delayed review | Backup takes ownership before the two-minute limit; the order remains held until someone releases it. | Shift lead | If no alert appears, establish another reliable way to notice the delay. |
| Unavailable item | The item is not released for preparation; staff can see what action is needed next. | Assigned server | Confirm whether the whole order or only the item can be rejected or changed. |
| Guest update | The team can identify what the guest would be told and who follows up. | Assigned server | If no automatic notice is available, agree on an in-person update. |
The table describes desired outcomes, not assumed product features. For the normal order, note the submission time, review time and kitchen-release time shown in the practice environment. Check the table number, item choices and any modifiers at each handoff. If a result differs from the expected result, ask whether a setting changes it or whether your team would need a different process.
Compare automatic release and approval during a rush
Automatic release removes the review step from the path to the kitchen. That can help when servers are already moving between tables and the menu is simple enough that most submitted orders need no intervention. It also means a mistake or unavailable item may reach the kitchen before staff notice it. Ask how an employee can stop or correct an order after release, and how the kitchen learns about the change.
An approval queue gives staff a chance to catch a wrong table, an unavailable item or a request that needs clarification. Its cost is another task at precisely the moment staff may be busiest. A queue is only useful if the reviewer has both the authority and the time to make a decision.
For the fictional restaurant, compare the two paths with a short burst of practice orders. Submit six simulated orders close together: four ordinary orders, one with an incorrect table identifier and one containing a fictional unavailable item. In the automatic path, observe what reaches the kitchen destination and how the team would correct the two exceptions. In the approval path, observe whether the assigned server can check all six and whether the shift lead can see work waiting for attention.
Keep the comparison fair. Use the same practice orders and the same kitchen destination for both paths. Record the time until each order is ready for kitchen action, plus any corrections or staff handoffs needed. Do not treat a faster screen transition as a complete result: an order that needs a later correction may still consume staff time.
If the two exception orders are reliably caught before release and the remaining orders meet the two-minute limit, approval fits the fictional restaurant's stated priorities. If ordinary orders repeatedly wait beyond that limit while the reviewer handles other duties, the owner should change the staffing or choose automatic release with a workable correction process. A longer queue is not proof that more review is happening well.
Consider how the decision fits the wider service model, too. The guide to placing QR ordering in table service can help you decide which interactions remain with a server. Review your restaurant POS system handoff separately: the important question is where the order goes and who can act on it, not simply whether two screens display it.
Test delays, rejected items and guest updates
For the delay scenario, leave a simulated order unreviewed while the assigned server is occupied. At one minute, the team should be able to identify the waiting order. Before two minutes, the shift lead should take ownership and either release it or resolve the issue. Ask the vendor what makes a waiting order noticeable: a visual queue, an alert, a shared view, or a manual check. If the only answer is that someone must keep looking at a screen, assign that check explicitly.
Next, submit a simulated order with an unavailable item. Ask the reviewer to stop that item from reaching the kitchen. Then follow the consequences. Can staff reject just the item, change it, or must they reject the entire order? Does the rest of the order remain held? Is a new guest choice required? The acceptance test passes only if the team can explain and carry out the agreed next step without the kitchen preparing the unavailable item.
Payment status matters here, but it is a separate question from kitchen approval. Find out whether the guest would already have paid when staff reject an item, and how an adjustment or refund would be handled in that case. In the practice environment, do not enter a real card or process a real transaction. Inspect the simulated status or ask the vendor to show the relevant workflow.
Finally, check the guest-facing outcome. A rejection on a staff screen does not necessarily tell the guest what happened. Ask what the phone would display at submission, during a hold and after a rejection, and whether any notification is sent. In practice, use a preview or simulation that cannot send a real message. If an automatic update is unavailable or unclear, the server should visit the table, explain the issue and agree on a replacement or other next step.
Fleksa's QR ordering lets guests scan, order and pay at the table in a browser without downloading an app. When assessing any system, distinguish that guest ordering path from the separate question of staff approval. Ask Fleksa to demonstrate the release, exception and notification steps you need in your intended setup.
Set the fallback before choosing a workflow
Name a primary reviewer for each shift and a backup who can actually take over. Give them a shared definition of overdue and a clear action: claim the waiting order, check it, then release it or speak with the guest. Decide who watches the queue during breaks and who handles it when both people are occupied.
Also decide what happens if the approval process is unavailable or the queue grows past your limit. A practical fallback might be for the server to take the order directly and pass it to the kitchen through the restaurant's normal method. Make sure staff can distinguish that order from one already submitted by phone before entering it again. Do not assume a system can automatically switch modes; ask whether switching is supported and how staff would know which mode is active.
Guests who do not want to use a phone need a service path as well. A server can take their order directly, using the same table identification and kitchen handoff rules. Keep a simple escalation route for uncertain orders, including special requests that need a conversation rather than a quick approval.
After the simulated checks, plan a supervised live service pilot only if the workflow is ready. Real guest orders, payments and notifications can occur in that pilot, so brief the team and use your normal service controls. Watch the queue and ask staff to record delays and corrections. Review the result after the shift before making the workflow your default.
For a next step, write down your release rule, reviewer, backup and maximum delay. Then compare those requirements with Fleksa and confirm current availability and setup before choosing a workflow.
Frequently asked questions
Does every QR order need staff approval?
No. Approval is worth considering when staff can prevent meaningful errors and can review orders promptly. Automatic release may suit a simpler menu and a team with a reliable way to correct exceptions.
Is seeing an order the same as approving it?
No. Seeing an order provides visibility. Approval means someone has a defined action that releases a held order to the kitchen. Ask the vendor to show the difference in your intended setup.
What should happen if nobody reviews an order?
A named backup should take ownership before your restaurant's maximum acceptable delay. If the queue cannot be managed, use an agreed fallback, such as direct server ordering, while checking for an existing submission before entering it again.
