Eat.fit was created with one simple promise — provide healthy, tasty and fresh food to you when you need it. We want to do all of this while also ensuring that you have a great experience — right from the menu you see on the app to receiving the food hot, in the fastest time possible.

To fulfil this promise, there is a whole bunch of planning and execution that goes on behind the scenes. To ensure that this happens smoothly, we need to make no mistakes along the way. Automation helps smooth operations and minimize mistakes. And, engineering plays a huge role in making this happen.

Let’s take a look at all the things we plan & do behind the scenes to deliver a great experience

One time activity:

• We need to identify the best location for a kitchen
• Decide the right size of the kitchen, including floor area, layout, equipment and staff
• Identify the areas around the kitchen where we can deliver with reasonable speed

Day to day activities:

• Plan the daily menu in advance (Based on seasonality, nutritional balance, availability etc)
• Predict demand — how much do we expect to sell on a given day based on customers’ demands
• Decide the amount of raw materials to procure, and from which vendors
• Assign the right delivery force (known as Health Crew) to the right areas
• Automate the offers shown to the customer

Real time planning:

• Show only available dishes to customers when they visit the app/website
• Decide whether an order can be delivered to the customer, and in how much time
• Create a plan for the orders placed to minimize delivery times and maximize the number of orders delivered
• React when things do not go according to plan (Traffic, accidents, rain, internet outages in kitchen etc)

In the last few years, many food delivery startups cropped up in India, but only a few managed to sustain because it is a very demanding business. One of the reasons for this is the extremely high cost of delivery and operations — all of which traditionally required heavy manual work..

The key to building a sustainable business is minimizing the delivery cost. This is one of our most important goals, and automation is critical to achieving this.

This article throws light on how engineering helps us achieve a balance between a smooth delivery experience and reduced delivery costs.

Before we go deeper, let’s look at some of the delivery metrics we monitor and may use through the rest of the article.

1. On demand availability: The % of time customers see orders under “Eat now” tab, that can be delivered in less than 1 hour. Having a high availability allows more items to be available to hungry customers as well as good use of our inventory [Objective: Maximize this number]
2. Average On demand promise: The average ETA (mins) we show to customers for “Eat now” orders. [Objective: Minimize this number]
3. Productivity: Number of orders delivered by each health crew member per day. [Objective: Maximize this number]
4. After slot Breaches: Number of orders delivered after the promised ETA. Typically industries track this as orders which are delivered more than 10 minutes late. We track at both 0 minutes and 5 minutes. [Objective: Minimize this number]
5. Before slot breaches: This is specifically for orders placed beforehand where we promise that food will be delivered in a specific time slot. This is the number/percentage of orders delivered before the start of the promised time slot. [Objective: Minimize this number]

Let’s take a look at all the tasks done between you placing an order and us delivering it to you.

Taking an order

Just as you open the app/website and even before you’ve looked at the menu, we do all of the below

• Approximate the customer’s delivery location (if not already selected)
• Identify the right kitchen to serve the customer based on their location
• Check which products are in stock
• Decide whether the delivery is possible. We check if there is a free health crew member who can deliver the order and return to the kitchen in time to pick up his next assigned order
• Use this estimate to give the delivery ETA to the customer.

All this happens in a just a few milliseconds!

This computation helps us give a pretty accurate estimate of delivery ETA especially when health crew members are free/available for delivery. Every incoming order is tentatively assigned to an available health crew member, to ensure there is always an available route plan (This can be changed later if a better plan is found).However, this assignment logic misses the fact that nearby orders can be clubbed and delivered together. This is because a full route computation which can club nearby orders, takes a few minutes and cannot be done real time.

Therefore, when a new order comes and all of our health crew members are busy, we are unable to compute the ETA with the same level of accuracy. In such cases we go ahead and take the order with a default ETA of 45–60 minutes. We allow our offline computation to club this order with an existing nearby order and successfully deliver it within the default ETA. We continue doing this till we find an order which has a chance to overshoot the default ETA, at which point we stop taking orders for that busy duration.

Over and above this, we also do some real time order clubbing while taking the order itself. Any order which is yet to be dispatched from the kitchen can still potentially be clubbed with a newly placed nearby order. Of course, we do this only as long as we are able to deliver the original order well before the promised delivery ETA. We keep a list of all such orders, and anyone from a nearby location is then allowed to place an order even if all our health crew members are busy.

Route planning

Once an order is taken, we evaluate millions of different plans to find the best possible way to deliver all the orders on time, with the least possible number of Health Crew members.

We use Open Street Maps to get all the possible travel routes. We then use our own travel time estimator to convert this into a variant of Travelling Salesman Problem — specifically known as a capacitated vehicle routing problem with time windows. This is further solved using an augmented version of JSprit.

This forms the core of our delivery systems, and helps make the food delivery business cost effective.

These route evaluations are done continuously to adapt to new incoming orders. Based on our current Health Crew availability and the promised delivery time, we dynamically decide if the order can be sent to be cooked immediately, or if we should wait for another nearby order to be taken.

Estimating on-road time

We use past data from our health crew members to predict the travel times for a given area (taking into account day of the week, time of day, holidays etc) to get an initial Delivery time estimate. We then augment this data from real time traffic providers to achieve a balance between cost and accuracy (using an external service at all times is extremely expensive, both in terms of money and time). We use this data to continuously run simulations and dynamically adapt to incoming orders to ensure the best possible route plan.

Delivery windows

For our route planning, we started off with very strict time windows for delivery. If we are not able to deliver an order within the promised time window, we prioritize it heavily, and push it to the front of the delivery queue. This works well for occasional breaches, but if there are a large number of such occurrences (rains, kitchen delays, delivery delays due to road blocks/traffic etc) this effect starts cascading and makes the situation worse.

To fix this, in such cases, we relax the delivery time window by a few minutes. This allows the planning framework to find a better globally optimal solution, without drastically affecting customers.( Of course, there is a penalty for the planning algorithm when this buffer is used) This gives the system better leeway to recover gracefully from such scenarios.

Simply put, in the case of severe delays, we would rather delay many orders by a few minutes than delay a few by a significant margin.

Using external partners intelligently

We manage our own delivery fleet (Health crew), but there are times when either the demand outstrips our capacity, or there are unexpected peaks in orders (during big sales). In such cases we use external delivery partners.

Our algorithms dynamically decide whether to use our own health crew or an external delivery partner based on

• Current utilization of our crew
• The distance of the order from our kitchen

Far away orders are easier for our delivery partners since there they do not need to return back to our kitchen once the order is delivered.

Our operations team closely tracks the utilization of our health crew and that of delivery partners to ensure things go according to plan.

Validating algorithm changes

Any enhancements to our algorithms are first tested extensively on our Delivery Simulation Framework. We developed this system in-house so that we can measure the potential impact of any changes done, without having to test it out on actual customers.

This framework simulates the full lifecycle of orders across a time period, using an intelligent combination of parameters and historical trends. It takes in a target number of orders to simulate and the number of health crew members to estimate the productivity and on demand availability exactly as if this had happened in reality. It can also run in a mode where it takes inputs for expected demand in an area and estimates the minimum number of health crew members required to service it. All this, while ensuring a threshold for on demand availability is maintained. This allows better manpower distribution for kitchens, and shows us where hiring is needed.

An example where the simulation framework was critical was when we decided to try Health crew utilization based delivery ETA calculation. As we run out of free health crew members , we tried to slowly add buffers to the ETA (Upto a max of 60 minutes ETA). This would theoretically allow the planning system to wait and club these orders better as the delivery time window is now larger. This enables us to service more customers with the same number of health crew members. Simulations did show a good increase in the number of orders we could serve, but the measured trade-off (longer delivery times) was deemed an undesirable customer experience. We thus decided to shelve the feature. We were able to do this completely offline without needing to try it out on actual customers.

Conclusion

Our delivery systems are designed to work as efficiently as possible. They balance quick deliveries for customers in normal situations while minimizing breaches in times of stress.

Written by Vikramaditya M

Edited by Esha Savla