For a direct delivery order, the restaurant should own the guest relationship and make sure a delay message is sent. The fulfillment partner may be the better sender when it has the most current courier information and can contact the guest reliably. Choose one sender for each type of delay, name a backup, and agree on when responsibility changes.
That decision is separate from the original delivery estimate. A guest may accept an estimate at checkout but still need an update when the order is running late. Before choosing software or a courier partner, map who can see the problem, who can explain it, and who can act if the first message does not go out.
Map who can see the delivery status
A useful delay message depends on more than a clock. Your team needs the order identifier, the promised delivery window, the food’s preparation status, the courier’s pickup status, and a way to tell whether a guest has already received an update. The partner may have the best view of the courier; the restaurant usually has the best view of the kitchen.
Walk through the handoffs for an order placed on your restaurant website. Ask each provider what your staff can actually see and how quickly a status change reaches them. A screen that says “in progress” may not tell a manager whether food is still cooking, waiting for pickup, or already on the road.
- Order and promise: Where can staff find the order number, guest contact details, and delivery window shown at checkout?
- Kitchen: Who records that the food is ready, and can the fulfillment partner see that status?
- Pickup and travel: Who can see courier assignment, pickup, and a revised arrival estimate?
- Messages: Can both parties see whether a delay notice was sent, when it went out, and what it said?
- Exceptions: How does a manager reach a person when the status is stale, the courier cannot be reached, or the guest calls?
Access matters as much as the data itself. If only a partner’s support desk can see a courier’s location, find out how staff reach that desk during a busy dinner shift. If the restaurant cannot see a partner’s message history, agree on another way to confirm that an update was sent.
Set triggers and name one message owner
Use the restaurant as sender when the delay starts in the kitchen and staff can give a credible update. Use the fulfillment partner when the food has left the restaurant and the partner has the clearest delivery status, provided it can reach the guest and report back. If that reporting is unreliable, the restaurant may need to send the message using an update obtained from the partner.
Put the decision in writing before service. The matrix below is a starting agreement, not a description of any particular provider’s features. Adapt the trigger and backup to the tools and staffing each party actually has.
| Situation | Primary guest message owner | Information needed | Backup or escalation |
|---|---|---|---|
| Kitchen expects to miss the delivery window | Restaurant | Preparation status and a realistic revised estimate | Manager contacts partner if pickup timing must change |
| Food is ready but pickup is late | Restaurant, using partner status | Ready time, courier assignment, and pickup estimate | Partner support investigates an unassigned or delayed courier |
| Courier has picked up but delivery is delayed | Partner, if it can send and confirm the update | Pickup status, revised arrival estimate, and message confirmation | Restaurant sends an update if confirmation is not received by the agreed deadline |
| Status is unclear or guest reports no delivery | Restaurant acknowledges the issue | Last reliable status and partner support contact | Partner investigates; restaurant follows up with the guest |
The matrix separates the person who sends the message from the person who investigates. A restaurant can remain accountable to its guest without pretending it knows where a courier is. Conversely, a partner can send a delivery update without taking over decisions about a restaurant’s refund or replacement policy.
Define triggers in terms your team can observe. For example, agree that a kitchen delay is flagged when the manager expects the order to miss the promised window, not only after the window has passed. For an in-transit delay, agree on who determines that the estimate has slipped and how that information reaches the sender. Set a specific confirmation deadline and backup path in your own agreement.
Prevent conflicting updates
Two messages are not necessarily better than one. A guest who receives “your driver is nearby” from a partner and “we are still looking for a courier” from the restaurant has no reliable next step. The fix is a shared handoff, not silence.
Use a common order identifier and record four things: the latest reliable status, who owns the next guest update, when that update is due, and whether it was sent. If your systems cannot share a message log, decide how the partner will provide confirmation. Also agree which contact details each party may use and how staff should handle a guest who opts out of a message channel.
Hypothetical example: A restaurant promises delivery between 6:20 and 6:30. At 6:15, the food is ready, but no courier has been assigned. The restaurant asks the partner for a pickup estimate and sends the guest a kitchen-to-pickup update if the agreed trigger has been met. It does not say the food is on the way.
At 6:25, a courier is assigned. The restaurant records that status and hands ownership of any later in-transit delay message to the partner, if the partner can confirm delivery of the notice. If that confirmation does not arrive by the agreed deadline, the restaurant contacts the partner and sends the guest a factual update. A useful message can say what is known, what is still being checked, and when the guest should expect another update. It should not invent a new arrival time.
This example depends on timely status and message confirmation. If either is unavailable, use a simpler arrangement: the partner supplies updates to the restaurant, and the restaurant remains the guest-facing sender. That adds work for staff but reduces the chance of competing promises.
Practice the handoff before a live service pilot
First, run a simulation with a fictitious order and staff acting as the guest. Use a training environment or a paper record. Disable or substitute any real guest messaging, payment, and courier dispatch; a practice scenario must not send a real message, charge a card, or summon a driver.
Give the team a sequence: food ready, courier unassigned, courier assigned, then an in-transit delay. Ask the kitchen lead, manager, and partner contact to identify the sender and next action at each step. Check whether they can find the promised window, whether the message reflects the last reliable status, and whether the backup knows when to take over.
Then decide whether to run a live service pilot with actual orders under your normal operating procedures. A live pilot is not a simulation: real guests and deliveries are involved. Brief staff and the partner beforehand, assign a manager to monitor exceptions, and agree on how to pause or change the process if handoffs fail. Review the results afterward rather than assuming the practice run proves the live workflow will work.
Review unresolved incidents with the partner
Hold a short review after a delay that required more than the normal handoff. Start with the timeline, not blame: when the risk became visible, when each party learned about it, who was responsible for the guest update, and what happened next. Compare that timeline with the matrix.
For each unresolved incident, ask:
- Was the promised window visible to the people making decisions?
- Did the partner supply a usable status, or did the restaurant have to guess?
- Was one party clearly responsible for the message at each stage?
- Can the sender confirm whether the update went out?
- Did the backup act when the agreed deadline passed?
- Who owns the follow-up if the guest asks for a refund, replacement, or further explanation?
Turn the answers into a specific change: a different trigger, a named support contact, a shorter confirmation deadline, or a restaurant-owned message when partner visibility is weak. Keep the matrix accessible to shift managers and revisit it when you change fulfillment partners or ordering workflows.
Use this checklist to evaluate your current restaurant online ordering setup, then ask Fleksa about verified US availability and how your chosen fulfillment arrangement would support delay handoffs. For broader buying questions, see the online ordering buying guide.
Frequently asked questions
Should the restaurant always send the delay message?
No. A fulfillment partner may be better placed to send an in-transit update if it has current courier information and can confirm the message was sent. The restaurant should still have a backup and a way to help the guest.
What should a delay notification include?
Identify the order, explain the latest reliable status, and give a revised estimate only if it is credible. If the timing is unknown, say what is being checked and when the guest can expect another update.
What if the partner cannot confirm its message was sent?
Agree on a deadline for confirmation and make the restaurant the backup sender. The restaurant should obtain the latest reliable status before contacting the guest and avoid repeating an unverified arrival estimate.
