How food delivery startup Popchef delivers 1 dish every 5 seconds

Exploring automation & algorithms powering the meal prep industry

Editor’s note: This blog was originally published in French by Francois Vasnier, CTO at Popchef.

At Popchef we love good, homemade dishes. We have revived lost recipes that we long stopped enjoying. These simple and balanced recipes show us that eating healthy everyday is within everyone’s reach. But there remains a big challenge: how do we deliver them? ??

I’m the CTO at Popchef, which means I am responsible for the backend systems and the algorithms that automate the daily activities of running an on-demand food delivery service. The goal of this automation is simple: to minimize human interaction while your order goes from our kitchens to your office. The key issue is the scalability of the Popchef model, that is to say its capacity to receive 10 times more orders without requiring 10 times more human resources. The main objective of our company is to deliver your lunch — hot and on time — and in this article, I’m going to attempt to explain how we do just that.

Routing meals from us to you

Our recipes are cooked every morning in a central kitchen located outside of Paris. Each dish is then carefully routed through our supplementary kitchens in the heart of the capital. It is this choice that allows us to offer you the best prices by centralizing production, and the best delivery service by being closest to your offices.

A diagram showing the path our food takes; from our central kitchen to our various supplementary kitchens across Paris.

When you arrive on the Popchef website, we offer you an option of 30-minute delivery time windows: 11:45–12:15, 12:15–12:45, etc.

We’ve noticed many of our customers choose to order their lunch in advance (on average 1 to 2 hours before the start of your delivery window). This is an advantage for us since it allows us to better organize the routes of our drivers and to regroup the orders which are geographically close.

Once the time slot approaches, we assign the order to a delivery person; usually 10 to 15 minutes before the start of the slot. The order is prepared by the kitchen manager before being placed in the delivery man’s bag shortly before he begins his route. The route generally consists of one to three delivery points and a delivery person will make an average of four trips per day.

The challenge: delivering on time

Our promise is to deliver a hot dish to you in a 30-minute time window, and we know from our data analysis that timeliness matters to you. It seems obvious that if we are late, your perception of our quality of service will be diminished. However, it is this type of intuition that we wish to validate precisely thanks to the study of available data.

Feedback graph according to delivery time

The graphic above shows the importance of a delivery made on time: the average feedback score goes down very quickly in correlation with the delay. Based on this data, we know precisely the impact delays have on your happiness and satisfaction. It’s thanks to our customers that we can calculate this type of indicator because more than 30% of you share your opinions with us every day.

To help you better understand this issue, there are three factors that influence what time your meal will be delivered:

·        How long it takes to prepare your order

·        How quickly your delivery driver can work through all his deliveries

·        Optimization of the delivery driver’s route

We must take into account and optimize each of these three factors to be able to deliver during the time window you have chosen, and allow you to enjoy your lunch in the best possible conditions.

The key: making good use of resources

Optimization of our delivery drivers

The MDMTSP is a rather crude acronym that refers to a well-known mathematical problem: optimization paths in the context of multiple delivery and multiple storage locations. At Popchef, we decided to free ourselves from the multiple storage places by considering each area independently: never will a delivery driver coming from the kitchen in the 15th arrondissement come pick up an order from the kitchen in the 16th. Of course, this decision reduces overall optimization, but in return there are many other advantages: speed of execution, reliability of inventory, and management of equipment, to name a few.

Diagram of MDMTSP

The diagram above shows an example of how we deliver at Popchef. The central green square represents the extra kitchen located in Paris while the other circular points are customer orders. The idea is to succeed in delivering all orders on time with a fixed number of delivery drivers. We must therefore define a set of routes which our delivery driver will follow in a specific order. To be able to draw these routes, we must estimate the time that each part of the journey will take:

The journey of a delivery in our backend system. The manager prepares the orders as the delivery driver returns to the kitchen.

·        Order prep: We estimate the time it takes to prepare an order by taking into account how fast the kitchen managers can work and the size of each of the dishes

·        Distance: In order to quickly calculate distance, we take the distance as the crow flies to which we add 30% (1 km as the crow flies = 1.3 km real). This approximation gives us an accuracy of about 90% and avoids multiple calls to Google Maps.

·        The speed of each delivery driver: We have been studying the average speed of our delivery people since the launch of Popchef, and we optimize our process by assigning a speed parameter to each courier. Turns out, some of our drivers are true athletes!

·        The order duration time: There’s always a slight delay when customers come to meet the delivery person at the door; for Popchef deliveries, it’s on average 1 to 2 minutes per order.

On average, the sum of these approximations works, but we often face edge cases. If, for example, two customers take a little longer to meet their delivery person, and our distance (measured by as crow flies) is distorted by a large, urban park in the middle of the city, we may be seriously fall behind with our deliveries.

The last constraint we must respect is the duration of the entire route. In order to guarantee the delivery of a hot dish, we have to limit the duration of our routes — from the time the delivery driver exits the kitchen to his last delivery — to about 30 minutes. This is where we differentiate ourselves from some of our competitors who deliver cold meals and can therefore plan larger, longer routes. On top of this, we are also constrained by the weather and the outside temperature; it is more difficult to keep a hot dish when it is -6 degrees Celsius! We have to adapt the duration of our routes according to this parameter.

Monitoring of slots and zones

Evolution of the “stress” of our delivery slots over time for certain areas.

This page allows us to view in real time the status of each of our delivery zones. For each area, we know exactly how many delivery drivers are available and how many deliveries we need to make. This way, we have a way of estimating delays. We calculate two important indicators on this page:

·        Stress: This indicator is calculated using the following formula: Number of deliveries / delivery drivers available . The calculation is therefore relatively basic but allows us to spread the orders on the different slots.

·        Odometer stress: This indicator is calculated using the following formula: Distances between the kitchen and the points of delivery / delivery drivers available . This allows us to highlight certain differences between zones and manage the geographical distribution of orders, for example.

To the left of this table we have represented each of our zones and at the top each of the available slots. It should be noted that the slots are overlapping and that a single delivery is counted in two slots.

A maximum stress level is defined for each zone. When this level is reached, it becomes impossible for the customer to place an order during this slot unless there already is an order to the same address. We consider that such an additional order is not a problem since it does not entail a new trip.

Time Estimated Delivery Chart

In addition to this stress page, we have set up a system that simulates deliveries. Every minute, a server models all the deliveries for each zone based on the results of the route optimization algorithm. We thus get a precise picture of the time at which we think we can deliver the orders.

Estimated time of delivery versus time

The color code makes it possible to differentiate the status of the command:

·        Yellow: order has been paid but is not yet ready to go

·        Violet: a delivery driver has been assigned to the order

·        Blue: the driver has taken charge of the order and goes to the address

The example above illustrates how an order was paid around 12:05 p.m. At 12:40 p.m., the order is assigned to a delivery driver and the kitchen manager prepares the bag. In this case, the driver even had time to make another delivery before proceeding to this particular customer, outperforming our estimate and improving the delivery time. Finally the driver arrives at 1:01 p.m. and marks the order delivered at 1:04 p.m.

According to this chart, we were able to estimate the exact delivery time down to a three minute window, and this estimate was completed one hour before delivery. Of course, our system isn’t foolproof, and we still have a lot of work to do to ensure that we deliver to every body on time.

Some challenges:

Though we have put in place many systems that allow us to manage and optimize our delivery logistics, we are now experiencing a period of growth. This growth makes it harder for us to accurately estimate the resources we need to guarantee on-time deliveries. To be honest, we can be late — and this leads to unhappy, and hungry customers. Here are some of the challenges we’re currently facing:

Optimize: improve our algorithms

There is a lot of room for improvement when it comes to the in-house algorithms we built.

To enable the implementation of new algorithms, we have developed a simulation system to evaluate the efficiency of each algorithm we design in the test phase. It is thus possible to run simulations to see precisely if it does better based on two key indicators: quality and cost of delivery.

Anticipate: accept or reject an order

When a customer arrives on our website, we must be able to tell him/her whether or not we are able to deliver their food at the time of their choosing.

Today, we are using the stress dashboard I presented above to tackle this issue. Unfortunately, this method only works partially and, in some cases, tends to refuse orders that we can deliver on time while accepting orders that we cannot.

The stress indicator that we calculate is rather simple; it works mainly to spread out the orders and therefore avoids concentrating deliveries between 12:00 and 1:00 p.m., the most popular time window.

Inform: let customers know asap about delays

The system that allows us to simulate delivery does not work perfectly when the order is partially yellow (waiting to be assigned to a deliveryman). On average, we can predict the delivery time of half of the orders with a precision of 5 minutes. We need to do better.

In summary, these are the major challenges we are currently facing:

·        Statistical analysis of all the data we have collected up to today (speed, waiting of the deliverymen, etc).

·        Forecast of operational failures and definition of a certainty threshold for the estimates.

·        Modify the simulator so that it can easily scale up and handle bigger loads.

The ultimate goal is simple: to eliminate all peaks of delays and limit them to 5% of the maximum orders, whatever the conditions in which we operate.

We believe it’s important to share our knowledge about the on-demand food delivery space and thus improve collectively. We can’t wait to get your feedback! ??

Editor’s note: This blog was originally published in French by Francois Vasnier, CTO at Popchef.