A delivery time estimate is a promise, and customers judge you on whether you kept it more than on whether it was fast. A 45-minute delivery that was promised at 40 feels late; the same delivery promised at 50 feels early. The estimate you give should be built from four measurable parts: confirmation, preparation, rider pickup and travel, with a buffer that reflects the hour and the weather.
This post shows how to measure each part from your own orders, how to turn them into a promised range per delivery zone, how to adjust at peak, and what to send the customer when the promise is going to slip. None of it needs software beyond a clock and your order history, though a system that stamps each status makes it much easier.
What an ETA is made of
Every delivery has the same four segments. Write down last week's times for each and you have the raw material for an honest estimate.
| Segment | Starts | Ends | Typical range for a small kitchen | Who controls it |
|---|---|---|---|---|
| Confirmation | Order placed | Kitchen accepts it | 0 to 5 minutes; longer if a phone has to be checked | You |
| Preparation | Accepted | Packed and ready | 10 to 25 minutes depending on the dish and the queue | Kitchen |
| Pickup | Ready | Rider leaves with it | 0 minutes with a rider on site; 10 to 20 with an on-demand courier | You, or the courier |
| Travel | Rider leaves | Handed over | 8 to 25 minutes by distance and traffic | Distance, traffic |
Add them up for a 3 km order on a normal evening: 2 + 15 + 5 + 12 is 34 minutes. For a 6 km order at Saturday dinner with a courier booking: 3 + 22 + 15 + 25 is 65 minutes. The first customer should be told 35 to 45; the second 60 to 75. One number for both would be wrong for both.
Measure before you promise
Pull 50 to 100 recent orders and note the time at each step. If your ordering system stamps status changes, this is an export; if it does not, a week of a staff member writing times on the KOT does the job.
Look at the median, which is the middle value, and at the slow end, around the 80th or 90th percentile. The median is what usually happens; the slow end is what happens on a bad Saturday. Build the promise so that roughly nine orders in ten arrive inside it. If your median 3 km delivery is 34 minutes and the slow end is 48, promise 35 to 50, and feel free to arrive early.
Two patterns show up in almost every kitchen's data. Preparation time balloons when more than a handful of orders are in the queue at once, and pickup time is the segment that varies most when you depend on an on-demand courier. Those two are where your buffer should go.
Set the estimate by delivery zone
Since travel time is a function of distance, your ETA should follow your delivery zones. If you have not drawn zones yet, how to set delivery zones and charges by distance covers it; the same rings that set the charge can set the promise.
- 0 to 3 km: promise 30 to 45 minutes off-peak, 40 to 55 at peak.
- 3 to 5 km: promise 40 to 55 off-peak, 50 to 70 at peak.
- 5 to 7 km: promise 55 to 75 off-peak, and consider offering only scheduled slots at peak.
Quote a range rather than a single number. "40 to 55 minutes" gives you room; "45 minutes" is a stopwatch. And quote the range at the moment the customer is deciding, on the menu or in the ordering chat, so there is no surprise after payment.
Adjust for peak, rain and the queue
A static estimate is wrong at exactly the times it matters. Three adjustments are worth building into the routine.
Queue depth
Agree a rule with the kitchen: if more than, say, eight orders are in preparation, add 10 minutes to every new promise until the queue clears. The person taking orders needs to see the queue to apply this, which is one reason a shared order screen beats a notebook. Handling the rush itself is covered in peak hour management: handling 100 orders in 60 minutes.
Weather
Rain adds 10 to 15 minutes to travel and makes couriers scarce. Switch to the peak range the moment it starts, and tell customers why; nobody argues with rain.
Courier availability
If you book on-demand riders, the pickup segment can stretch from 10 to 30 minutes on a festival evening. Book the rider when the order is accepted rather than when it is ready, so the wait overlaps preparation instead of adding to it.
Keep the customer informed, before they ask
A customer who knows the order is running late is mildly annoyed. A customer who has to call to find out is angry. The difference is one message, sent before the promised window ends.
The minimum set of updates is: confirmed with the ETA, out for delivery with a fresh ETA, and delivered. Add a fourth, "running about 10 minutes late, sorry", whenever the promise is going to slip, sent as soon as you know rather than at the deadline. Wording for each is in order status message templates, and the mechanics of sending them on WhatsApp are in delivery tracking on WhatsApp.
These messages do more than calm one customer. The "out for delivery" message, in particular, makes people check their phone and come to the door, which shortens the handover and gets the rider back faster.
Review the promise every month
Once a month, compare promised windows to actual delivery times by zone and by hour. Three outcomes are possible for each zone.
- Nine in ten inside the window: leave it, or trim the top of the range by five minutes if you are consistently early.
- Fewer than eight in ten: widen the range, then find which segment is slipping. It is usually preparation at peak or courier pickup.
- Everything inside but complaints continue: the window is too wide to be useful. Split peak and off-peak promises instead of one broad range.
The larger context of choosing riders and zones, which drives most of these numbers, is in the hyperlocal delivery guide. A WhatsApp ordering platform such as Tezzu makes the measuring part easier: each order carries its delivery zone, moves through statuses in the live dashboard and staff app, and the customer is updated on WhatsApp as the status changes, so the times you need are recorded without anyone writing them down.
See the status flow on a real order
Book a short demo and we will walk through how an order moves from confirmed to delivered on Tezzu, with the customer updated at each step.
Book a demoFrequently asked questions
What is a reasonable delivery time for a restaurant?
For hot food within 3 km, 30 to 45 minutes from order to door is a normal promise for a small kitchen, stretching to 50 or 55 at peak. Beyond 5 km, an hour or more is realistic. The right number comes from your own measured preparation, pickup and travel times, with a buffer so that about nine orders in ten arrive inside the window.
How do restaurants calculate estimated delivery time?
By adding four segments: time to confirm the order, time to prepare it, time for a rider to collect it, and travel time to the address. Each is measured from recent orders, the travel part is set by distance zone, and a buffer is added for queue depth, peak hours and weather. The total is quoted as a range rather than a single figure.
Should I give customers a specific time or a range?
A range. "40 to 55 minutes" covers normal variation in preparation and traffic and still feels precise. A single number becomes a stopwatch the customer watches, and any overrun feels like a failure. If the order is going to miss even the top of the range, send a message before the window ends rather than after.
Why are my food deliveries always late at dinner time?
Usually because the promise does not change with the queue. Preparation time rises sharply when many orders are cooking at once, and on-demand couriers take longer to arrive when every kitchen is booking. Measure your peak times separately, quote a longer range during those hours, and book the rider at acceptance rather than when the food is ready.