The Strawberry’s Journey: From Your Local Farm to Your Table

What to expect from this series?

This series explains how we build a new service to enable our e-commerce platform to support home delivery. It will walk through all steps we take from scoping business requirements, architecting, and implementation.

In this first post, we will start with scoping business requirements. We will elaborate a standard setup of delivery business operation and unique challenges we face in fresh product delivery. Then we will highlight trade-off decisions between project scope and delivery timeline. Like most technical design, there is no right and wrong. Everything is about trade-off so we would explain in details on why we make such decisions. This will be the foundation for the next blog post where we design API and architecture to meet these requirements.

Disclaimer
I Love My Local Farmer is a fictional company inspired by customer interactions with AWS Solutions Architects. Any stories told in this blog are not related to a specific customer. Similarities with any real companies, people, or situations are purely coincidental. Stories in this blog represent the views of the authors and are not endorsed by AWS.

How COVID affected our business

It all started with the first lockdown in France…

I Love My Local Farmer’s mission is to give a direct access to local fresh vegetables and fruits to everyone. Our customers make orders to local farms through our e-commerce platform and went to pick it up at a designated time.

During the COVID period, people were more reluctant to go out to pick up. In some countries, it even became impossible to go out due to lockdown restrictions. We saw a big drop in the number of orders. Our revenue decreased quickly while the fixed operation expense were almost the same. As a result, the senior leadership team called for an emergency meeting.

The outcome of the meeting was the decision to expedite adding a ‘home delivery’ capability into our platform. This enables customers to choose a preferred delivery time slot and we would deliver to their addresses during the selected time slot. This option would cost an extra fee. We would launch this service only in some regions in France to test the water, as soon as possible. Then we would roll it out to other regions and countries.

This home delivery project wasn’t inspired purely by the pandemic. In fact, we had already reviewed the business plan multiple times and talked to a few delivery companies. However, the project required agreements between multiple stakeholders and therefore progressed very slowly. Once the decision was made, priorities were aligned, and we all focused on this project to rollout as soon as possible.

We defined the scope of our MVP (Minimum Viable Product) like this: customers would use almost exactly the same interface as normal pick-up orders. Except that they would see the “home delivery possible” tag on the farms that opt-in to the delivery service model. (See wireframe below).

A wireframe highlighting that the new delivery option is available for some farms

When they go to the checkout page, they would get possible delivery time slots to choose from.

A wireframe shows an additional option for home delivery in the checkout page

The change looks simple from customer perspective, but it requires sweeping changes on our end, from our business operations to our application itself.

Challenge of fresh product delivery

Logistics is a competitive business. Companies compete through price, using economies of scale and all kinds of optimization techniques. After all, who will pay additional 10 EUR for delivery?

Therefore, our first thought was to completely outsource delivery process to a 3PL (3rd Party Logistics) company. This option minimizes cost but delivery time is around 2–5 days, depending on locations. It would have been the best option if we deliver non-food products. However, our value proposition is having fresh products directly from local farms. Ideally, the products should arrive within the same day. Some products must be kept in fridge during transportation. So this option was not feasible.

The other option was to rent spaces in existing warehouses. We could pick products from local farms in an area and temporarily stock them in a warehouse nearby. Each day we could assemble orders at the warehouses and deliver to customers from there. This streamlines delivery process and minimize cost. Again, the drawback of this model is that it would take longer than 24 hours to arrive at customers’ houses. We also had to find warehouses with right locations that could store fresh products.

This brings up another concern that we are not sure how customers will respond to the home delivery option. If there isn’t enough demand, the scale we operate will not be sufficient to justify even the lease cost.

As a result, we decided to deliver directly from farms to customers. We would manage major parts of delivery process ourselves as a trial. Though we would hire drivers through contractors in logistics company to minimize capital investment. Based on what we learn, we would reiterate and tune our operating model once we see that this option could work.

Simplifying business requirements

We had to trade off complexity for fast launch. These are the requirements established by the business team:

  1. We do not support a single order from multiple farms, even if they are close to each other. This decision is based on the fact that customers are already familiar with ordering and picking up from a single farm. If we allow a single order from multiple farms, we will have to (1) rewrite our e-commerce platform (2) have drivers pick products up from multiple farms and combine them into a single order before delivery. We find this too complicated for our first try.
  2. Customers will pick a time slot from established delivery time slots, and must be home to receive their products. We want to have orders from a single farm delivered in least numbers of drive. Thus, customers will have to choose a time slot from established choices. The slot will be either in the morning (8:00–12:00) or afternoon (13:00–17:00). Some farms with low volume might have only one slot per week. This is not very convenient for customers as they might have to order up to one week in advance, but it allows us to optimize to acceptable delivery cost.
  3. For home deliveries, we will expect a minimum order value. This is in order to compensate for delivery expenses.
  4. Farmers have to opt-in to this delivery option. We do not onboard every farm with this option by default. For home delivery orders, farmers need to pack items in standardized boxes/crates provided by us (more details on this later). They also get charged at higher fee than normal pickup order.
  5. For the MVP, the process will be controlled by human schedulers. We will eventually switch to an automated scheduler to optimize the delivery automatically based on the knowledge acquired during the MVP period.

These scoped down requirements are not permanent. It will be only for the trial period and we will reiterate based on what we learn. The crucial factor is whether we could optimize the cost to the level that we could at least break-even with the delivery fee we charge customers and farmers. Using what we learn from the launch in the first region, we might decide to abandon this idea, or expand to other regions.

The strawberry’s journey

Now that we have understood the challenges and our business requirements. Let’s embark on a journey of our favorite fruits, strawberry. We will start from placing an order to arriving at a customer’s home. This journey will influence how we design our service API and architecture later.

When a user clicks on “Find nearby farm” button to locate local farms. We use user’s address to get the list of farms in close proximity. Each farm that opts in to our delivery option will be linked to a list of post codes that is within delivery range. If the user’s post code is in the list, they will see a bright tag of “home delivery available”.

A diagram visualize the steps for customers to place a home delivery order

In the first step, the user clicks on a farm, adds strawberries and other products to user’s cart. Then the user goes to the checkout page in step 2, where delivery time slots are presented.

The slot data is owned by new delivery service, so the existing e-commerce platform has to call delivery service API to get available slots for that farm. The user selects the preferred slot and goes to the payment page.

A diagram visualize the steps for farmers from receiving an order, packing item, to handling products over to drivers

Once the user has successfully paid, the order will be propagated to delivery service. We notify our farmers 2 days in advance so they have time to prepare the order. They also receive the printable labels for all orders. They pack each order in a separate bag/box and put an order label on it. This is something they are familiar with as it’s the same when customers come to pick up items themselves.

The additional step for the farmer is to put the bags in the standard crates that we gave them. Then they put a “crate label” associated with orders. The standardized crates allow drivers to stack products without crushing them. The crate labels have sorting numbers for the houses that they will be delivered to.

Our scheduler assigns delivery slots to farms in the way that all orders from a single farm are usually delivered on the same date. This is to optimize delivery cost and prevent overbooking. Each time slot has a maximum number of orders it could fulfill. Assuming that drivers could take 15 minutes per order, they could deliver approximately 16 orders in half a day (4 hours x 4 orders per hour). (Note that the number is different for each area)

Based on historical data, the scheduler can estimate that the farm will have approximately 50 orders per week. Thus, the scheduler allocates 1 driver for all of Tuesday (~2x16 orders) and another driver on Thursday (~16 orders)

If there aren’t sufficient orders (e.g. only 10 our of expected 32), schedulers might route the van to a nearby farm for additional orders.

As June is coming, the scheduler knows from historical data that the farms selling strawberries will get more orders as they are in season. The scheduler would adjust the number of slots and make sure that we have enough contracted drivers.

Now that the strawberries are safe in the van, the driver will go to each address planned by schedulers, unloading crates. With this process, the strawberries will arrive within 8 hours after leaving the farm.

What’s next?

Now that we have covered the business requirements, we are going to dive deeper into technical details in the next blog post. We will create API specification and architect our backend to connect with existing e-commerce system to make our strawberries journey as smooth as possible.

--

--

Chadchapol (Jemmy) Vittavutkarnvej
My Local Farmer Engineering

Specialist Solutions Architect, Builder at AWS. Opinions are my own. I also write Thai technical blogs at notaboutcode.com