Where AI actually works in food delivery (and where it doesn’t)
The app side of food delivery is largely a solved problem. Every platform has a menu, a cart, a payment screen, and a tracking map. No customer chooses one service over another because its checkout flow is marginally better. The real decisions that determine whether a food delivery business makes money or burns it happen in the 30 minutes after someone taps “order.”
Tarun Nagar, CEO of Dev Technosys, has built ordering, dispatch, restaurant-side, and driver systems across multiple markets. His company has been at it since 2010. His take on AI in food delivery is useful precisely because it is unfashionable: he names what works, what does not, and where handing control to a model is a genuine liability.
Dispatch Beats Personalization Every Time
The industry markets AI recommendations heavily. Nagar says that is the wrong place to look.
“Personalised recommendations help conversion a little. The money is in dispatch. Deciding which driver takes which order, whether two orders should be batched, and when to release an order to a driver so the food is ready as they arrive — those decisions happen thousands of times an hour, and a few percentage points of improvement there changes the unit economics of the whole business.”
Recommendations change what someone orders. Dispatch changes whether the business can afford to deliver it. That is the distinction worth anchoring to if you are building or evaluating a food delivery system.
Why Dispatch Is a Hard Problem
Dispatch is a live optimization problem with incomplete information. You are simultaneously predicting food preparation time, driver travel time, and a driver’s likelihood of accepting the job. All three shift with traffic, weather, and how busy the kitchen is at that moment.
The naive version assigns the nearest available driver. It looks fine in a demo. At volume, it produces drivers waiting in restaurants while food cools and delivers cold food two streets away. According to Nagar, the models that actually perform are trained on your own completion data, not on map estimates from a third party.
⏱️ An ETA Is a Promise, Not a Prediction
Technically, a delivery time estimate is a probability distribution. Most likely 28 minutes, possibly 40. What the customer sees is a commitment they will hold you to.
The engineering work is not just making the model more accurate. It is deciding how much buffer to surface and communicating honestly when things slip. Nagar’s framing here is direct: an app that quietly adjusts the ETA three times loses more trust than one that says once, clearly, that the kitchen is behind. The promise mechanic matters as much as the prediction model.
Where Automation Pays Back Fastest
Nagar points to support, specifically refunds, as the fastest payback on automation investment. A large share of support tickets are the same few situations: missing item, late order, wrong order. Those can be resolved with an automated decision against order data, delivery timestamps, and the customer’s history, with a human reviewing edge cases.
Support cost per order is one of the few numbers in this industry you can actually move without touching the kitchen or the road. That is what makes it the right place to start.
Ghost Kitchens Move the Routing Problem Inside
A single physical kitchen running several brands means one preparation queue serving orders arriving under different names, from different platforms, with different packaging rules. If the kitchen management layer treats each brand as a separate stream, the site gets five tickets at once with no shared sequencing and backs up fast.
Nagar says sequencing has to be done across brands, organized by the station that will actually cook the item. The routing problem does not go away with ghost kitchens. It moves indoors.
️ Voice: Skip the App, Fix the Phone Line
Voice ordering inside a consumer app is slower than tapping. That is not where voice matters. The real problem is the restaurant’s own telephone line, which still handles a meaningful share of orders and gets answered badly during a rush because staff are cooking.
An AI voice assistant that takes a phone order, confirms it against the live menu, and pushes it into the point of sale solves an actual operational problem. The hard parts, per Nagar, are barge-in handling, background kitchen noise, and knowing when to hand the call to a human.
️ What AI Cannot Do for the Kitchen
The constraint in a kitchen is the oven, the fryer, and the number of hands. Software does not add capacity to any of those. What AI can do is prevent the kitchen from receiving impossible promises: forecasting the next 90 minutes of order volume to set staffing correctly, and pacing order release so a site does not get handed 20 tickets in four minutes. That is useful. It is not the same as automating the kitchen, and Nagar is direct about the gap between those two claims.
⚠️ Three Decisions No Model Should Own
Nagar names three areas where full automation is the wrong call:
- The delivery promise. A model optimizing for acceptance rate will quote times the kitchen cannot meet. A human-agreed floor has to constrain it.
- Driver deactivation. Someone’s income is involved. The appeal path has to reach a person.
- Allergen information. A model summarizing a menu can get an ingredient wrong. That is a safety incident, not a bad recommendation. Allergen data comes from the restaurant’s own structured record or it does not get shown.
One Piece of Advice Worth Keeping
Nagar’s closing point is the one most teams get backwards. Most companies pick an algorithm before they have a clean record of what actually happened on their last 10,000 orders. The data is the longer job.
“Instrument before you model. Every AI feature in this category needs your own completion data — real preparation times, real travel times, real refund outcomes. Collect that from day one and the AI work becomes much shorter later.”
If you are starting a food delivery build today, that instruction saves months. Set up the logging first. The model choices get easier once you know what actually happened.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
