You order biryani. Zomato says 28 minutes. You set a mental timer.
At minute 32, the app still says 4 minutes away. At minute 38, the delivery partner is 900 meters out and hasn’t moved in six minutes. The estimate keeps shifting. You’re refreshing the map. The food arrives at minute 41, lukewarm.
You didn’t get a wrong estimate once. You got a cascade of wrong estimates, each one quietly replacing the last.
The first estimate is assembled before a delivery partner is even assigned. Zomato’s model pulls restaurant prep time — not a fixed number, but a live average weighted by that kitchen’s recent performance, time of day, and current order queue depth.
It layers in historical route data between that restaurant and your pin. Then it adds a pickup buffer. The number you see is a percentile prediction, not an average. They’re not telling you when most orders arrive. They’re telling you when yours probably will.
When it breaks, it breaks silently. The restaurant runs slow during a Sunday rush. The delivery partner takes a route the model didn’t weight for. A train crossing adds four minutes nobody accounted for. Each deviation reprices the ETA — but the model is smoothing, not alarming.
It nudges the number forward in small increments to avoid shocking you. That’s an intentional product decision. It costs accuracy to preserve calm.
For users, the damage is trust. A 10-minute slip on a 28-minute promise feels like a broken contract, not a statistical variance. Repeat that enough times and people stop ordering.
For the engineering team, the problem is that every input to the model is a live feed that can drift — restaurant prep times, partner GPS accuracy, traffic polygons, even weather. The ETA isn’t a calculation. It’s a pipeline. And pipelines degrade quietly.
Own the estimate end-to-end, or the estimate owns you.