When traffic varies, promise a delivery window based on completed orders from comparable times, not the quickest drive to the guest. Start the window near a typical elapsed time and set its upper end conservatively enough to cover most orders in that time band. Then review late arrivals and adjust the range when the kitchen or roads behave differently.
The right restaurant delivery time estimate starts when the guest places the order and ends when the food arrives. It needs to account for preparation, handoff, courier availability and travel. A range such as 35–50 minutes can be more useful than a precise arrival time, but only if your own order history supports it.
Measure the whole trip, not just the drive
Start with timestamps your team can consistently capture: order placed, food ready, courier pickup and delivery completed. The full elapsed time from order to arrival is the figure guests care about. The other timestamps help you find the cause when that figure rises.
For example, a slow order might spend extra time waiting for a courier even though the kitchen and drive were both quick. Another might leave promptly but encounter traffic. Treating both as a driving problem could lead you to change the wrong part of the operation.
Ask your ordering provider what timestamps are available and whether they can be exported. Ask whoever handles delivery how arrival times are recorded. If a courier marks an order complete before the handoff to the guest, that timestamp may make delivery appear faster than it was. Agree on a consistent definition before using the data to set a promise.
Group orders by conditions that could change elapsed time. Start with weekday lunch, weekday dinner and weekend dinner, for example. Within each group, consider whether long trips behave differently from nearby ones. You do not need to redraw your delivery boundary to make a better promise inside it.
Keep notes about unusual events, such as a road closure or a kitchen equipment problem. Do not automatically discard a bad evening: if the same rush or delay is likely to happen again, guests need a promise that accounts for it. On the other hand, one exceptional event should not dictate every ordinary day's estimate.
Build a conservative promise window
Use percentiles to describe the spread of completed order times. The 50th percentile is a typical midpoint: about half of observed orders arrived within that elapsed time. The 80th percentile is the time within which about eight in ten arrived. Neither is a guarantee, and a small or inconsistent sample can make either figure unstable.
Calculate these percentiles from each order's total elapsed time. Do not add the 80th-percentile preparation time to the 80th-percentile travel time and call the result the 80th percentile for the whole order. The slowest kitchen orders are not necessarily the same orders as the slowest drives.
The following worksheet is hypothetical. Assume each row represents a different set of completed deliveries, measured from order placement to arrival. The suggested windows are starting decisions, not predictions or a claim about any software's settings.
| Time band | 50th percentile | 80th percentile | Starting promise |
|---|---|---|---|
| Weekday lunch | 28 minutes | 37 minutes | 25–40 minutes |
| Weekday dinner | 36 minutes | 48 minutes | 35–50 minutes |
| Weekend dinner | 43 minutes | 58 minutes | 40–60 minutes |
In the weekday dinner row, a 35–50 minute promise starts near the typical observed time and ends just above the 80th percentile. That leaves a modest cushion above the example's 48-minute figure. It does not mean every order will arrive within 50 minutes, nor does it tell you exactly how many will; you would need the underlying order times to calculate that.
A shorter upper limit can look attractive at checkout, but it creates more opportunities to miss the promise. A much longer window may protect the restaurant while discouraging guests who expect a quicker meal. Choose the trade-off deliberately. If late arrivals are common during weekend dinner, the weekday range is a poor default for that shift.
The lower end matters too. If orders rarely arrive before 40 minutes, a 25-minute lower bound sets the wrong expectation even when the upper bound is reasonable. A window describes the range a guest should plan around, not the fastest order your team has ever delivered.
Before adopting a range, count how many completed orders support each row. If a band has only a handful of observations, combine comparable periods temporarily or keep the estimate conservative while collecting more. Check whether canceled orders and deliveries with missing timestamps are excluded; a record of completed orders alone will not reveal every service problem.
Explain delays without false precision
Put the expected window where guests can see it before they commit to an order. Use plain language such as “Estimated delivery: 35–50 minutes.” Ask your provider whether the estimate can vary by time band, destination or current workload, and whether it appears both before checkout and in the order confirmation. If the answer is no, decide how staff will maintain an honest estimate during a busy shift.
When conditions change, update the promise for new orders as soon as the team can. For an existing order that is likely to miss its upper limit, tell the guest what is known and give a revised range only if someone can make a reasonable estimate. “The courier is delayed; we now expect delivery in about 15–25 minutes” is more useful than an unexplained countdown that keeps moving.
Decide who owns that update. The kitchen may know when food is ready, while the delivery provider may know the courier's status. Give staff a clear contact path and ask the provider whether it can share updates with the restaurant or guest. Do not assume an ordering site and a courier service exchange every status automatically.
Practice the workflow before relying on it. In a simulated check, create a sample order in a test environment or walk through the screens without submitting a live order. Confirm where the estimate appears, who can change it and what staff would say if the order ran late. The simulation must not charge a card, send a guest message or dispatch a courier.
A simulation checks the workflow, not actual travel performance. A live service pilot uses real orders during an agreed period, with staff watching the displayed promise and recording actual arrivals. Tell the team which range is in use and how to escalate a likely late delivery. Review the results before making the range a permanent default.
Review late deliveries by time band
At the end of each review period, compare actual arrival with the upper end of the window shown when each order was placed. Count an order as late for this purpose when arrival is after that upper limit. Keep the original promise with the order record; comparing arrival only with a later revised estimate can hide a missed first promise.
For a separate hypothetical review, suppose 40 Friday dinner orders received a 35–50 minute promise and 10 arrived after 50 minutes. That is 10 out of 40, or 25%, late against the original upper limit. Check those 10 orders before changing the setting: how many were waiting for food, waiting for pickup or already on the road? Also look at orders that arrived just inside the limit, because they leave little room for a busier night.
If pickup waits are the main problem, speak with the delivery provider about availability before adding time to every estimate. If kitchen preparation is consistently slow at the same hour, adjust staffing, order pacing or the promise for that period. If travel varies by destination, ask whether different estimates can be displayed for different areas within your existing coverage.
Track both the count of orders and the count late, not just a percentage. A small group can swing sharply after one delayed delivery. Revisit the range after a meaningful operating change, such as new kitchen hours or a different dispatch arrangement, and keep notes on what changed. The goal is a promise that matches the service you can actually deliver, not a permanently inflated cushion.
To compare the wider ordering setup, use the online ordering buying guide and check where your restaurant website shows delivery expectations. Then take the worksheet and your current late-order counts to your provider. If you are evaluating Fleksa's restaurant online ordering, ask which estimate and update options are available for your setup and confirm current US availability.
Frequently asked questions
Should a delivery estimate include food preparation?
Yes. The guest waits from order placement until arrival, so the promise should account for preparation, pickup and travel. Track each stage separately to diagnose delays.
Is the 80th percentile the right upper limit?
It is a useful starting reference, not a universal target. Consider the sample size, the consequences of late orders and how much longer window guests will accept. Review actual misses before settling on a range.
What if traffic changes after an order is placed?
Keep the original promise for your records, alert the guest if it is likely to be missed and provide a reasonable revised range when possible. Update the estimate for new orders if your setup allows it.
