When a delivery request fails after you accept an order, first confirm whether a courier is actually assigned. Then decide quickly whether an authorized alternative can deliver the meal within an acceptable time. If not, contact the guest with realistic options. Keep one person responsible for the order until delivery or another agreed resolution is confirmed.
Do not treat a rejected dispatch as a canceled order. The guest may still expect food, the kitchen may already be cooking, and a payment may have been collected. Each needs a separate decision.
1. Identify the order and dispatch status
Start with the order record, not an assumption based on one notification. The shift lead should find the order number, guest contact details, delivery address, promised time, payment status, and kitchen status. Note who accepted the order and whether preparation has started.
Next, check the delivery request. A rejection, a request still pending, and an accepted request with an assigned courier require different actions. Record the dispatch reference and the latest status shown by the delivery provider. If the ordering screen and provider disagree, contact the provider before sending another request. A second request could result in two couriers being assigned.
Use this decision tree at the point of failure. It separates what staff can verify from what still needs a decision.
| What you find | Immediate action | Next decision |
|---|---|---|
| Dispatch status is unclear | Check the provider record or contact its support; note the reference. | Do not request another courier until the first request is confirmed inactive or your provider gives a safe procedure. |
| Request is rejected and inactive | Check available alternatives, address coverage, expected pickup time, and added cost. | Use an authorized alternative if it meets the guest promise; otherwise contact the guest. |
| Courier is assigned | Confirm the pickup estimate and whether the courier is still coming. | Keep the existing dispatch if workable; escalate a stalled pickup rather than duplicating it. |
| No workable delivery is available | Contact the guest and pause or adjust preparation as appropriate. | Agree on pickup, a revised delivery time, or cancellation and payment resolution. |
Set a time limit for checking an unclear status. A pending screen should not become an indefinite wait while food cools. Your limit should reflect the meal, the promised time, and how quickly your provider can respond. If the limit passes without an answer, escalate to the shift lead and contact the guest with what you know.
Staff also need to know where each answer comes from. The kitchen confirms preparation; the delivery provider confirms dispatch; the payment record or payment provider confirms the transaction; and the guest decides whether an offered alternative works for them. No single status should stand in for all four.
2. Find an allowed alternative or contact the guest
Once the first request is confirmed inactive, check the alternatives your restaurant has authorized. That might mean another delivery provider, a restaurant driver, or guest pickup. Ask whether the alternative covers the address, can collect at the required time, and has capacity for the order. A driver who cannot carry a large order safely is not a workable solution, even if the address is nearby.
Check the operational cost before committing. A replacement dispatch charge may be higher than the original quote, and the original provider may still need to confirm whether its charge was waived or reversed. Decide who has authority to approve the extra expense. If a guest would pay an additional delivery charge, explain it and get their agreement before proceeding.
Contact the guest as soon as the original delivery promise is at risk. Give a clear update without blaming a provider or promising a time you cannot verify. For example: “Your order is accepted, but our delivery request was declined. We are checking another driver. Would you prefer pickup, a later delivery if available, or cancellation?” Confirm the guest's choice and any revised time or charge.
If the guest cannot be reached, follow a written escalation rule. Assign someone to keep trying through the restaurant's approved contact method, and set a deadline for the manager's next decision. Do not mark an order delivered or canceled merely because the guest did not answer. If an alternative requires the guest's agreement, wait for that agreement.
Your restaurant website and ordering process should make it easy for guests to find a working contact number. When reviewing online ordering options, ask how staff can see order details, update a guest, and track exceptions across the ordering and delivery systems they actually use.
3. Control the kitchen and payment separately
The shift lead should tell the kitchen one specific instruction: continue, hold, stop, or remake. Include the order number and the reason. A hold may preserve an unprepared order, but it will not make every finished item suitable for a long delay. Decide which items can wait and which would need to be remade if delivery resumes later.
Use one kitchen ticket or a clearly linked replacement ticket. If a remake is needed, mark the original as superseded and tell the kitchen which items to remake. A new courier request is not, by itself, a new food order.
Hypothetical example: A restaurant accepts an order for two entrées. The kitchen has finished one and has not started the other when the delivery request is rejected. The shift lead confirms that the request is inactive, tells the kitchen to hold the second entrée, and checks a backup driver. The backup can arrive later than promised, so the lead calls the guest. The guest agrees to the new time. The kitchen then remakes the first entrée for quality and prepares the second once; the lead records the replacement dispatch reference.
That sequence works only if the backup is available, the guest accepts the delay, and the restaurant can prepare the food in time. If the guest declines, staff should not send the backup anyway. They should stop the remaining preparation where possible and agree on cancellation and payment resolution.
Payment needs its own check. A payment authorization, a completed charge, a refund request, and a completed refund are different statuses. Do not tell the guest that money has been returned just because an order was canceled. Check the payment record, follow the provider's process, and explain what has actually happened and when the guest should expect another update. If staff cannot verify the outcome, assign the manager to follow up.
4. Record the outcome and escalate recurring failures
Close the loop in a shared shift record or the tools your team already uses. Capture the order number, failure time, provider and dispatch reference, status checks, guest contact attempts, agreed outcome, kitchen instruction, replacement reference if any, and payment follow-up. Record who owns any open task and when it is due. Keep access to guest details limited to staff who need them.
For provider support, send the reference, request time, delivery area, rejection message, and the action already taken. Ask whether the rejection was caused by capacity, address coverage, request information, or another issue; whether the original request is definitively inactive; and whether any dispatch charge applies. Ask for a case number and a response deadline. Avoid sending unnecessary guest or payment information.
Review a small set of incidents at the end of the week. Look for failures at the same time of day, in the same delivery area, or after a particular handoff. Then change one operational rule: perhaps shorten the delivery area, set a clearer escalation deadline, or arrange an approved backup. Compare the written quote for each option, including fixed charges, per-dispatch charges, and exception charges where applicable. A quoted dispatch fee alone is not the full operating cost.
Practice the decision tree before a busy shift. In a simulation, use a fictitious order and a safe training environment or paper records; do not initiate a real payment, guest message, or courier dispatch. Have one person play the provider and another play the guest. Check that staff avoid a duplicate request, give the kitchen one instruction, and distinguish a refund request from a completed refund.
If you later run a live service pilot, use actual orders only under your normal customer, payment, and delivery procedures. Monitor the first exceptions closely and stop to correct the process if staff cannot see who owns the next action. A simulation checks the team's decisions; a live pilot checks the operating setup under real service conditions.
Next, walk one recent failed-dispatch incident through the table with your shift lead. Identify the first unanswered status and write down who can resolve it. Then ask Fleksa about its restaurant online ordering system, relevant delivery workflows, and verified US availability for your location.
Frequently asked questions
Does a rejected delivery request cancel the order?
Not necessarily. Check the order, dispatch, kitchen, and payment statuses separately. The restaurant remains responsible for agreeing on a workable outcome with the guest.
Should staff immediately request another courier?
First confirm that the original request is inactive or obtain the provider's safe procedure. Otherwise, two couriers could be assigned. Then check capacity, timing, cost, and the guest's agreement where needed.
When should staff promise a refund?
Follow your restaurant's cancellation and payment procedures, and confirm what has actually been initiated or completed. If the status is unclear, give the guest a follow-up owner and update time rather than saying the refund is complete.
