The most requested features for online food delivery
My main occupation for the past few years has been building ecommerce platforms for large Food Delivery businesses. Unsurprisingly they usually request very similar functionality. What is surprising, is that there are no ecommerce Systems that offer those features out of the box. Here is a list of them:
Key insights
- Each order has a requested delivery (or pickup) time attached
- The online presence needs to reflect store opening hours
- An order can only be completed if the customer is in a specific region
- The number of orders needs to be throttled per time period
- Support any number of locations that each have their own products, payment methods, delivery methods and promotion codes
- Products that are only available for specific delivery or pickup times
Each order has a requested delivery (or pickup) time attached
As you can probably imagine, food delivery is time critical. For one, because people tend to order because they're hungry. But also because food tends to decay over time. So if you're ordering a meal online you usually expect to receive it within a few hours of when it was cooked. For this reason every food order has an attached time for when the customer plans to receive (and probably consume) the ordered food.
On the store frontend this information usually ends up as some kind of datepicker that shows available dates and times for when an order can be prepared:
And the associated time picker:
There are some details to this implementation, such as verifying the date is not in the past, and that the date has not since become invalid. That can happen if the opening hours were changed, or the date has become unavailable for some other reason (see throttling orders).
The online presence needs to reflect store opening hours
Now that we've established why each order needs to have a time attached, it becomes evident that our online presence needs to support some kind of opening hours.
Since the time between cooking and consumption is relevant, we need to ensure that orders can only be made for a time when there is someone ready to cook in the kitchen.
This brings with it a whole bunch of complexity we need to be able to support in the backend:
- Standard opening hours when the kitchen is available
- Special opening hours for bank holidays or other temporary variances in availability
- Availability of delivery network (it's expensive to have someone ready all day)
- Minimum time required to prepare and deliver an order
Additionally these variables might be different for orders in the restaurant, delivery, takeaway, and individual physical kitchens. As such there is usually no such thing as "the opening hours". There are a multitude of opening hours, depending on a number of variables.
An order can only be completed if the customer is in a specific region
Contrary to more traditional ecommerce stores, there are scenarios in food delivery where a customer must be prevented from ordering in the first place.
This adds to the previous point of food decaying. Since the time between cooking and consumption needs to be short, food deliveries are most often picked up or delivered via some sort of local delivery network. Many local restaurants manage their own delivery by simply driving their orders around in a car. Of course there are also platforms that offer to manage the logistics for you. Some of these are Uber Eats and Doordash for the USA, but there are a large number of regional logistics & delivery companies.
Regardless of what solution you choose, there will be some kind of limit where the cost of the delivery outweighs the price of the order. For that reason it is vital that your online store can support this scenario.
The correct way to validate this is a topic of debate. Some stores require you to enter your location before you see any products. Others validate your order at the end of the checkout process. It all comes down to weighing the ease of use and accessibility versus when to validate that the order can actually be fulfilled.
An example of how Uber Eats handles locations that can't be delivered to:
They simply don't display any products at all.
Doordash handles this case a little better:
Number of orders need to be throttled per time period
Let's assume you are a thriving online food delivery business. Each Friday hundreds of orders come in. You've made it!
Except now you have probably a new problem: 90% of the orders gravitate to two points of the day: noon and evening. The reason why is obvious, it's when people usually eat their meals.
Dealing with these kinds of peaks is hard, because it will be hard to scale your kitchen and staff to perfectly match the number of incoming orders. This is where your online shop can help out.
Instead of just letting everyone order at the same time, we can restrict the number of orders for specific time periods. So instead of having everyone order their lunch for 12:00, we can restrict that slot to 15 orders (for example). Everyone else needs to decide if they want their lunch at 11:45 or 12:15.
Support any number of locations that each have their own configuration
In the point about opening hours we touched on the fact that there might be multiple kitchens your online store delivers to. Since they are different physical locations they can differ in basically every way possible:
- Opening hours
- Available products
- Payment methods
- Delivery Times
- Delivery Regions
- Availability of Pickup or Delivery
- Promotions codes
- Marketing materials
Another way of thinking about it is that each of your kitchens might be their very own store and online shop. That's a lot to ask of typical ecommerce solutions.
Most of this complexity can be hidden from the customer by simply asking them to choose at location at the beginning of the order process:
This deceptively simple widget carries with it a lot of work for many of your backend systems (Webshop, CRM, PIM, etc).
Products that are only available for specific delivery or pickup times
An first glance this point may be the same as previous. It is, but I want to bring special attention to it because lots of restaurants offer some sort of Lunch Menus. Incase you're somehow not aware: Lunch menus are special deals that are prepared specifically for lunch time. Usually these meals are prepared in bulk and are cheaper because of it.
This concept brings a few interesting requirements to it for our online shop: These products are only available for a specific delivery time (not order time), and they probably change every day.
Most merchants I've worked with couldn't muster the internal organisation to produce a whole product with nutrients, images, and descriptions for each daily lunch meal. So most of the time it ends up being a placeholder product with a link to a PDF (or similar).
Nonetheless, the requirement for the specific delivery time still exists. In order to support this, the customer needs to select a delivery time before they see the list of products. That's something our two examples (Uber Eats and Doordash) don't support yet.
In Summary
Bringing a restaurant online with a sufficient food delivery solution is not easy. Especially since there are no platforms or ecommerce systems that support these requirements out of the box. There are easy ways around this by skipping some of the features and making due. Fully supporting a real food delivery chain is still difficult though.
Thank you for reading
I hope you enjoyed the article and maybe even learned something. If you would like to stay in contact I have a mailing list or you can reach out to me via social media.