One of the pillars of Carrefour Spain’s strategy aims at becoming a leader when it comes to food e-commerce. To achieve this goal we are investing in creating new capacity, new processes and new systems, such as the last mile delivery.

To reach a leadership position, we must satisfy customers’ expectations. As the food e-commerce market is fundamentally local, each country has its own specificities, in terms of product assortment and brands, but also in terms of price. On top of that, there are also operational requirements.

Whereas the Drive model is king in France (picking up the order at a delivery point), customers in Spain prefer to receive their e-commerce orders directly at home.

You need a system, let’s talk about a TMS!

When designing an e-commerce system to improve order delivery, it’s natural to follow a line of reasoning such as this one:

Home Delivery -> Transport -> TMS (Transport Management System)

Of course, you want to be the leader, so you think “I need the best TMS on the market”. 

However, is there another side of the coin? The answer is yes. A full-fledged TMS could be a powerful piece of software able to orchestrate from cargo flows around the globe using freighters to trucks moving merchandises across a country. It can be a terrific asset full of features, however, this also means that you have a variety of scenarios to work on. 

This is why you might consider focusing on the Last Mile Delivery System (LMDS) for various reasons that I will develop below.

The last mile delivery problem

There are multiple factors that make the problem of the last mile of Food e-commerce different from traditional logistics management. First, we are talking about B2C logistic, not B2B, but here you have some specific ideas to consider:

• The delivery may well be the only human contact the customer will have with you. If you are an e-commerce service or company, you must take care of this contact. Delivery experience matters.
• You are going to deliver at home (typically in an urban environment). City traffic, parking availability and all the remaining related issues matter too.
• You have to manage a lot of deliveries, usually in short routes (in the kilometers range), in small vehicles, and probably in specific time slots. As the volume increases, the complexity grows and grows.

In this context, as always, two priorities must be addressed:

• The customer wants his/her order to be delivered on time and complete 
• The business wants transport to be cost efficient and fitted to the global model

It may seem surprising that I don’t place delivery speed among top priorities. Of course, clients want the shortest possible delivery time, but there are many factors which determine what can be offered to the client, other than transport management: preparation capacity and processes, activities schedule, distances, and of course cost. That is what I mean when using the expression “fitted to the global model”: delivery speed and transportation expenses, for example, can be reduced at the cost of increasing picking expenses (by having idle teams waiting to immediately prepare customer orders).  Transportation is a part of a global operational model.

The last mile delivery suite

Building a last mile delivery suite

Our approach was based in two main principles:

• Above all, it is business processes that matter. And business processes will evolve over time. Agile works fine when evolving a product, but is not-so-good when launching a new product, so we chose a mixed model.
• We will be pragmatic. We develop, internally, some components from scratch and we rely on third parties where we have no clear competences.

As a result of these principles (and some problems we discovered later the hard way), I personally prefer to call Apollo Last Mile Delivery Suite rather than System. It is not a monolithic system and there is not a unique application, but a set of components and services that work in concert to manage the last mile. Most of them have been built by the eCommerce development team at Carrefour Spain. Others are integrated third-party services. 

–

What Apollo does

For showing what Apollo is, I would like to take a tour on “our” Last Mile Business Processes. 

All the processes are supported by Apollo. Let’s begin …

1/ Configure: Fleet management

You are going to work with a pretty fair number of entities: companies, vehicles, drivers, operational  points, delivery areas. Consider this:

An order (A), made up of 3 boxes (B1, B2, B3) travels in a vehicle (C) of type (C1), driven by the driver (D), which belongs to the company (E), which manages the orders prepared at the operational point (F) to distribute in the area (G), made up of 4 postal codes (G1… G4).

The operations team will need to configure these entities, their types, and moreover the relationships between them in an agile way. This is done using an administrative panel in Apollo.

2/ Slots management

How many orders do you want to (or could) deliver in a certain area in a certain time slot? Remember: transportation is only one factor. Picking capacity and transportation capacity must be coordinated. It’s a working day? Local holiday? Same capacity week around or variable? Available capacity will be shared by all the assigned zip codes?

There are a lot of business rules to manage. So, another kind of administrative panel is needed to manage capacity.

3/ Demand management

Imagine that you have available transport capacity, but delivering a single order to an address far away from the usual routes is extremely expensive. Are you willing to accept that extremely high cost? Perhaps the answer is yes, but our approach is to offer the customer cheaper alternative delivery slots. This is what we call dynamic demand management.

Dynamic Demand Management involves mathematical optimization, of course, but it also involves a fine-tuned balance between cost efficiency and customer service. So, it is a key business decision where the optimization level should be set.

Slots + Demand management combined are the source of slot availability for the customer. 

4/ Route management

Now we have the orders. We know where and when they must be delivered (which is our commitment to the customer). Now we must organize the distribution as efficiently as possible. This is a classic optimization problem, resulting in a set of delivery routes with their associated orders, sorted by delivery order.

• Route 1: (Order a1, Order a2, … , Order aN)
• Route 2: (Order b1, Order b2, … , Order bN)
• Route K: (Order k1, Order b2, … , Order kN)

Once the routes have been calculated, it is simple to assign a vehicle and a driver to each route using another administrative panel.

It is important to understand the route as the fundamental unit of delivery work. It has all the necessary elements:

• A person in charge: the driver
• A resource: the vehicle
• A well-defined sequence of actions: the delivery of orders in the specified order
• A starting point: loading of the vehicle
• An end point: the delivery of the last order

Of course, nothing is that perfect in the real world. There can be some difficulties like routes that start too late, drivers that need to be replaced at the last minute, vehicles that break down, customers that are not available to pick up the order, etc. You have to leave room for the unforeseen in the model.

5/ Loading & Shipping

Let’s talk about vehicle loading. There are four important elements to consider:

1. When orders are prepared, they must be positioned in a specific and well-identified place, which is associated with a route.
2. The vehicle must be positioned on the correct dock to facilitate loading.
3. Orders must be loaded in the reverse order of delivery (LIFO) for efficient unloading.
4. The whole order must be loaded. No box should be left unloaded by mistake.

Item 1 is a shared responsibility between the LMDS and the WMS. The last mile delivery suite must provide the route assigned to each order, and WMS uses it to indicate to the picking team where it should be deposited.

Points 2 to 4 are the responsibility of a new facet of the last mile delivery suite: the Driver’s App.

6/ Guided delivery and tracking

When making the delivery, the driver needs to know two things:

• The list of orders to deliver, and your order (what is the next order)
• The route to follow to reach the next delivery address

In both cases we use the Driver’s App to provide the necessary information and guide the process. Remember: the route has been calculated to optimize delivery time and cost. When the driver decides not to use the calculated route (sometimes for good reasons), the optimization is lost. In addition, since each delivery is registered through the App, we have real-time visibility of the delivery status of each order. This is essential to be able to intervene if there are problems on a route and try to minimize the impact for the customer.

Through the App we also obtain two key data:

• Where the vehicle is
• The time spent in traffic

We use these two data to continually re-estimate the delivery time for subsequent orders. With this information, we inform the customer if their order will be delivered on time or, unfortunately, there will be a delay.

Of course, the customer expects his order to be delivered on time, but above all, the customer hates when a delay is not previously communicated upon. This is a clear pain point that we strive to avoid.

7/ The actual delivery

When delivering an order to the customer, there are three processes supported by the App:

• Unload control: the order must be complete. Do you remember “An order (A), made up of 3 boxes (B1, B2, B3)”? Two of the most common mistakes when delivering an order are: (I) forgetting a box in the vehicle and (II) delivering a box that belongs to a different order. By controlling the loading through the App and capturing the code from the box, these errors disappear.
• Customer signature: the customer confirms his order’s reception, signing in the App.
• Incident Management. Unfortunately, incidents can still occur. They can be diverse and we haven’t found a process model that supports everything. The solution we have adopted is that the customer can speak to Customer Service from the driver’s App.

8/Analytics for the last mile delivery suite

In our case, we identified two sorts of analytics we needed. I will try to illustrate with examples the sort questions that every one of them should give an answer:

Control Tower (Real time analytics)

• Is there a problem with a route / driver now? ? Real time visibility of route state.
• Are we sure that driver “X” has been at customer “Y” home’s doors at 12:30h to deliver the order? ? Geolocation history
• Where is now vehicle Z? ? Real location

Business Control analytics

• Who are the best / worst drivers related to the number of incidents, on time delivery, etc?
• What is our “perfect order” (on time, complete) rate?
• Is there some operational point that usually ships the orders later than expected?

All these questions and much more are really usual when dealing with this messy activity that ends here.

You haven’t seen any images of Apollo. Apollo is not a pretty thing to show. It is not developed for the end user (except the signature of the order’s receipt), but for professionals managing a difficult activity. When needed, some UX effort was involved, but much of Apollo work is done in the deep back office, behind the scenes.

A side note: why did me name it “Apollo”?

You are probably wondering what a Greek god like Apollo has to do with all this. When we started the work of rebuilding the eCommerce operations systems, I told our teams that they could choose the names of the different components. To keep consistency to a minimum, I asked that ALL components should have names related to mythology (any mythology).

I was hoping to find a tour by Tolkien’s or Lovecraft’s characters, unknown Inuit gods, terrible giants of Norse mythology, or perhaps a show about the Hindu pantheon.

It turned out that they were a bunch of people far more conservative than I thought. The team chose some of the Olympic gods. It’s embarrassing, because Apollo isn’t exactly the patron of commerce. This honor belongs to Hermes, but Hermes was already assigned to another set of components.

It doesn’t matter: it’s a nice name, the team chose it, and Apollo WORKS.

Credits

Many people deserve credit for Apollo. Let me name some of them:

• Above all, the development team and specially Patricia Morente
• Oscar Gonzalez and Ignacio Martín, Business Owners of Transport initiative
• David Morales, Last Mile Manager in food e-commerce
• David Costa, founder of Nektria
• Emmanuel Remy, the first person that used the expression “Last mile delivery suite” (LMDS)

You can also check our other tech projects on Horizons.