A server can notice a new QR order through an alert on a staff device, a shared order queue checked by the team, or a scheduled check by a named employee. The right choice depends on who is responsible for acting, how quickly the guest needs attention, and what happens if the first notification is missed. None of these methods requires the server to watch the kitchen screen continuously.
Start by asking vendors to demonstrate the first notification, not just the order’s later status. A screen that shows an order being prepared may be useful, but it does not prove that a server will notice the order when it arrives.
Decide who needs to notice the order
First, define what the server must do after a guest submits an order. Does someone need to check payment, bring drinks, answer a request, or simply know that the table has ordered? The answer determines who should receive or check the notification and how quickly they must act.
Assign a primary owner for each service period or dining area. Then name a backup who can act when that person is carrying plates, helping a guest, or away from the device. “The team will see it” is not an assignment. A manager should also own the handoff when sections or shifts change.
Set an acknowledgment target that fits the room. A counter-service dining area may have a different target from a full-service section where a guest expects a server to respond. Acknowledgment means a staff member has noticed and accepted responsibility for the order; it does not necessarily mean the order has been prepared or delivered.
Table identity matters at this point. Ask how the notification identifies the physical table and what staff should do if the table number is missing or wrong. Your setup for table QR codes should make it practical to connect an order with the right location. Also decide how a guest who cannot or does not want to use a phone can order.
Map three ways to catch a new order
Device alert: A phone, tablet, or other staff device signals that an order has arrived. The assigned server notices it, checks the table and order details, and acknowledges it using the available process. The backup takes over if the server does not respond. Ask whether the signal is audible, visible, or both, and whether acknowledgment and escalation are supported or need a separate procedure.
Shared queue: New orders appear in a place the dining-room team can check. A designated person checks it at an agreed interval and claims or communicates each new order. The backup covers breaks and busy periods. A queue can work without individual alerts, but it only helps if someone actually checks it. Ask whether the queue can be accessed away from the kitchen and whether staff can tell which orders have already been noticed.
Named staff check: One employee checks for new orders on a schedule and tells the assigned server what needs attention. This can be a useful manual fallback when devices or alert options are limited. The checker owns the initial review; the server owns the table action. The manager assigns coverage whenever the checker leaves the post. Agree on the check interval rather than relying on memory.
These approaches can be combined. For example, an alert can prompt the primary server while a backup checks a queue. Confirm how duplicate notices are handled: two employees should not both assume the other person has taken the order, or both begin the same task without realizing it.
Use a selection worksheet
The table compares operating choices rather than claiming that a particular product offers them. Use the final column as a question for each vendor demonstration and written quote.
| Approach | Staff effort | Guest impact | Cost and vendor questions |
|---|---|---|---|
| Device alert | Carry or monitor a device; acknowledge and cover missed alerts. | Can prompt a quick response if noticed; a silent or unattended device creates a gap. | Quote devices, setup, support and any alert charges. Can alerts reach the assigned person and be acknowledged? |
| Shared queue | Check at a set interval and identify an owner for each order. | Wait depends partly on check frequency and whether someone is covering the queue. | Quote the display or device and access costs. Can dining-room staff see new orders and tell which are claimed? |
| Named staff check | One person checks and relays orders; coverage is needed during absences. | Wait depends on the check interval and handoff to the server. | Estimate staff time and any required device. Can the existing order view show a clear table identifier? |
Compare complete operating quotes, not just a software line. Include any fixed software or device charges, variable charges, and the cost of handling exceptions where those apply. Staff time is an operating consideration even when it does not appear on a vendor invoice. Ask whether a proposed device works with the actual configuration and whether the notification still reaches staff when the screen is locked or the app is not in the foreground.
Hypothetical decision: A small dining room has one server covering tables and a host near the entrance. The owner wants a new order acknowledged within two minutes during the dinner shift. The server cannot reliably carry a device, but the host can check a shared queue once per minute. A manager covers the host’s breaks.
The owner chooses the shared queue, provided a demonstration shows that new orders and table identifiers are visible there and that staff can mark or otherwise clearly communicate who has taken each order. The one-minute check interval leaves time within the two-minute target for the host to alert the server, although busy periods could still cause a miss. If the queue cannot support that handoff, the owner uses a named check with a written relay procedure until another workable option is available.
For this decision, the owner compares a hypothetical monthly device charge of $20 and fixed software charge of $30, plus $5 in variable charges and $10 for exception handling: $65 total. Those figures include the listed fixed, variable and exception costs, but exclude staff time and other restaurant operating costs. They are not a Fleksa quote. The owner should obtain actual quotes and decide whether the staff time needed for each method changes the choice.
Test the first notification and the fallback
Before selection, ask for a controlled demonstration using a simulated order in a test environment. The simulation must not charge a card, send a guest message, or dispatch a courier. Use a test table identifier and make sure everyone knows the order is not for a real guest. If the vendor cannot provide a safe simulation, review the workflow with sample screens and staff role-play rather than triggering a real transaction.
- Set the expectation. Write down the primary owner, backup, acknowledgment target, and where a new order should appear or sound. Record the expected table identifier and the action that counts as acknowledgment.
- Leave the primary device unattended. Place it where a server might realistically leave it during service. Submit the simulated order. Do not have a participant watch the device solely to make the alert easier to notice.
- Check escalation. If nobody acknowledges by the target, the backup checks the agreed source and takes responsibility. Ask the vendor to show any automatic escalation being considered; otherwise, the backup needs a scheduled manual check.
- Record the result. Note when the simulated order appeared, when someone noticed and acknowledged it, who acted, and whether the correct table was shown. Record missed signals and unclear handoffs as well as successful ones.
Pass the workflow only if the order is noticed and assigned within the restaurant’s target, the table can be identified, and the backup can take over when the primary owner does not acknowledge. A visible order that nobody notices by the deadline fails the notification test. So does an alert that reaches someone who cannot tell which table needs attention.
Repeat the simulation with a locked or muted device, a busy primary server, and a shift handoff. Do not assume a device setting or backup alert will work until it is demonstrated. If the method fails, adjust the assignment, check interval, device placement, or escalation procedure and repeat the simulation.
Separately, a live service pilot uses the agreed process for real guest orders after staff have been trained. Assign a manager to watch for missed handoffs and keep the manual fallback available. Review delays with the team afterward; a successful simulation alone does not establish how the workflow will perform during a rush.
Make the next vendor conversation specific
Fleksa’s QR ordering lets guests scan, order, and pay at the table in a browser without downloading an app. Ask how a new order would reach the dining-room employee in your proposed setup, and how the table and payment status would be shown. If you also use or are considering a restaurant POS system, ask to see the handoff across the actual configuration rather than assuming every device or notification method is supported.
Compare the demonstrated workflow with your current process. Ask Fleksa to show the applicable capabilities, then run the unattended-device and backup-owner scenario against your acknowledgment target before deciding.
Frequently asked questions
Does a QR order automatically alert the server?
Do not assume it does. Ask where a new-order signal appears, who receives it, and whether the system supports acknowledgment or escalation. If it does not, assign a staff check and backup.
Can a shared queue replace a device alert?
It can be a workable alternative if someone owns the check, the interval fits your service target, and the queue provides enough information to identify and assign the order. Test coverage during breaks and busy periods.
What should staff do if no one acknowledges an order?
The named backup should check the agreed order source and take responsibility once the acknowledgment target is missed. If that source is unavailable, use the restaurant’s manual procedure to identify and help the guest.
