Staff should accept or reject a new online order early enough to leave the kitchen its realistic preparation time plus a small handoff buffer before the promised pickup. For many restaurants, that means setting an internal deadline of a few minutes, not waiting until someone happens to check the screen. The right number depends on the promise you make and the way your shift runs.
Work backward from pickup. If an order cannot be ready on time once it is reviewed, staff need a clear next step: offer a later time if the system and guest allow it, or reject the order promptly. An acceptance deadline is an internal operating rule; it is not the pickup time shown to the guest.
Measure the time before staff respond
Start the clock when the guest submits the order. Record when the alert reaches the restaurant, when a person first notices it, and when that person accepts or rejects it. These are different events. A device can display an order without anyone acknowledging it, and a person can see an order without making a decision.
Ask the shift lead to collect a small sample across quiet and busy periods. Use whatever timestamps the ordering system provides, supplemented by a simple written log when needed. Check whether the timestamps use the same clock and whether the pickup promise is measured from submission or another event. If a timestamp is unavailable, record that gap rather than guessing.
For each order, capture:
- Submission time and promised pickup time.
- Alert arrival, first staff acknowledgement, and acceptance or rejection time.
- Estimated preparation time for that order, including the effect of the current queue.
- The time the packed order is ready for handoff.
- Any obvious interruption, such as a muted device or a staff member away from the counter.
The kitchen lead can estimate preparation time; the person watching the ordering screen can explain notification delays; and the manager can check staffing and pickup promises. Look at the slower responses as well as the typical one. A target that works only when the counter is quiet will be missed during the service you most need to protect.
When comparing online ordering systems, ask which timestamps are visible, whether alerts repeat, and how staff can see orders awaiting a decision. Do not assume a notification sound means an order has been accepted.
Work backward to a response target
Use this calculation as a starting point: promised time from submission, minus realistic preparation time, minus handoff buffer, equals the latest decision time. The buffer covers packing and getting the order to the pickup point. It should also leave room for ordinary variation, not just the fastest possible cook time.
Hypothetical example: A restaurant promises pickup 25 minutes after submission. The kitchen estimates 17 minutes to prepare a representative order during a busy shift, and the manager reserves three minutes for packing and handoff. That leaves five minutes to decide: 25 minus 17 minus three equals five. The decision deadline is five minutes after submission, not five minutes after someone notices the alert.
Five minutes is the outer limit under those assumptions. Set the normal response target earlier, such as two minutes, so a missed alert can reach a backup before the deadline. A large order, an unusually full queue, or an item that takes longer than 17 minutes changes the calculation. If the kitchen needs 21 minutes and the same three-minute handoff buffer, only one minute remains for a decision. The restaurant may need to offer a later pickup time rather than rely on staff to beat that clock.
A quick acceptance is useful only if the kitchen can honor it. Give the person responding enough authority and information to check capacity, unavailable items, and special requests. Decide in advance who can change a pickup time, whether the ordering setup permits that change, and how the guest is told. If a later time cannot be offered or agreed, prompt rejection may be the clearer option.
Do not treat the target as a promise that every order will be ready on time. Revisit the pickup settings when menu changes, staffing, or order volume make the preparation estimate unreliable. Your restaurant website and ordering channel should present pickup expectations that staff can actually support.
Assign a backup before an alert is missed
Name a primary person and a backup for each shift. Use roles rather than a vague instruction that “someone” should watch the screen. For example, the counter lead could own the first response, while the shift manager checks the queue when the lead is serving a guest. Make the handoff explicit during breaks and shift changes.
The following matrix applies to the hypothetical 25-minute pickup above. Its two-minute target and five-minute deadline depend on the assumed 17-minute preparation time and three-minute handoff buffer. Times run from order submission.
| Elapsed time | Owner | Action | Decision rule |
|---|---|---|---|
| 0–2 minutes | Counter lead | Notice and review the order; accept or reject it. | Accept only if the kitchen can meet the pickup promise. |
| At 2 minutes | Shift manager | Check any order still awaiting a decision and take ownership if needed. | Check capacity and resolve the decision before the deadline. |
| At 4 minutes | Shift manager | Escalate immediately to the kitchen lead if readiness is uncertain. | Determine whether the original time is still workable. |
| At 5 minutes | Shift manager | Make the decision; do not leave the order pending. | If the original promise cannot be met, offer a later time where possible or reject promptly. |
The matrix is a staff procedure, not a claim that software will automatically alert each person at those moments. Ask your provider whether pending orders can be displayed clearly, whether an alert can repeat or reach another device, and what staff must do manually. If there is no automatic escalation, the backup needs a practical way to check the queue without abandoning other essential work.
Practice the handoff in a simulation using a sample order that cannot reach a guest or the live order queue. Walk through a missed alert, a busy kitchen, and an unavailable item. The practice must not trigger a real card payment, guest message, or courier dispatch. Confirm who notices the sample, who makes the decision, and what each person would do next. A simulation checks the procedure; it does not prove that staff will meet the target during a live rush.
For a separate live service pilot, use normal incoming orders with assigned staff watching the queue. Do not create a real transaction just to test the procedure. Have the manager observe response times and intervene when needed. Tell staff when the pilot starts and ends, then review what happened after service.
Review late decisions and adjust the process
At the end of each pilot shift, compare submission-to-decision times with the target and deadline. Also check ready-for-handoff times against the pickup promises. A fast response and a late handoff point to a different problem than an alert that went unnoticed for six minutes.
Sort delays by cause before changing the target. A notification that arrives late calls for a different fix from a screen that staff cannot hear, an unclear owner, or a kitchen that cannot estimate its queue. Ask whether the backup was available, whether the escalation happened on time, and whether staff had enough information to accept or reject confidently.
Review a few concrete cases with the people who worked the shift. If the counter lead was consistently occupied at the two-minute mark, move primary ownership or give the backup a scheduled queue check. If decisions were quick but orders were repeatedly ready late, revisit preparation estimates and pickup windows. If staff often reject because an item is unavailable, make sure availability is updated promptly and the decision-maker knows who can update it.
Keep the record simple: order time, decision time, promised pickup, ready time, cause, and the action assigned to a named role. Review the next busy shift to see whether that action helped. Avoid judging staff on response speed alone; a rushed acceptance that the kitchen cannot fulfill makes the pickup promise less reliable.
Use the direct-order comparison guide if you are also reviewing how different channels fit your operation. Keep that broader decision separate from the immediate question of who responds to each incoming order.
Next step: Write down your current pickup promise, preparation estimate, buffer, primary owner, and backup. Run a safe simulation, observe a live shift, and revise the deadline based on the results. To discuss your setup, ask Fleksa about restaurant online ordering and verified US availability.
Frequently asked questions
Should the acceptance deadline be the same for every order?
Not necessarily. Longer preparation times or a heavy kitchen queue leave less time before the existing pickup promise. Set a standard response target, but give staff a way to handle orders that need a later time or cannot be fulfilled.
Does seeing an order count as accepting it?
No. Seeing or acknowledging an alert tells you someone noticed it. Acceptance is the separate decision to fulfill it. Track both when possible so you can identify where the delay occurred.
What if the deadline passes before anyone responds?
The assigned backup should take ownership immediately and check whether the original pickup time remains achievable. If it does not, offer a later time where possible or reject promptly rather than accepting an unworkable promise.
