Skip to main content

Planning for Cloud Kitchens - Solution

MyFoodPlace, the use-case provider, is the largest Central European Kitchen-as-a-Service KaaS provider reaching a yearly revenue of millions of euros. Filuta AI, the Technology Specific Bridge Developer, is the decision-making partner, providing MyFoodPlace with prediction and decision-making services. This is a solution page to the… case study


Developed by
Business Category
Technical Category
Planning and scheduling

What is the challenge that is being addressed?

A cloud kitchen runs a commercial kitchen operation for the purpose of preparing food for delivery and takeout. Cloud kitchens enable restaurateurs to expand existing restaurants or start virtual-only brands at a minimal cost. The provider of the cloud kitchen operates a Kitchen-as-a-Service (KaaS) business deriving value from efficiently aggregating shared resources both in the physical space and in the decision making. Physical space aggregation includes resource sharing at different stages of meal preparation, such as those needed for cooking, processing, storing and freezing ingredients. It further includes coordinated restocking of ingredients, delivery services for the prepared meals and inter-kitchen logistics. On the decision-making side, a KaaS provider helps the restaurateurs manage their recipes (as unique differentiating processes of meal preparation), find optimal assignments of recipes to kitchen resources, estimate ingredients consumption and demand, minimize food waste due to expirations of ingredients and market the meals to the consumers.

What is the AI solution the project implements?

Filuta AI developed the Cloud Kitchen Simulator (CKS) to efficiently validate hypotheses during the TSB development. It is built on top of a process-based discrete event simulation framework named SimPy. The framework provides a linear dimension-less timeline and allows for scheduling events to be executed at a specific time on this timeline. Events can then be processed, chained, or simply observed. One simulator tick represents one minute of real time in the CKS implementation.

Based on the learnings we found during evaluation phase and during consultations with the Partner (My Food Place), we identified the orders dispatching as their main pain point. We identified 4 different algorithms to test out using the simulator with a few configuration options for some of them. The historical test data contained 14k+ orders and we run 1500 simulations measuring following KPIs:

  • drive time [minutes] – number of minutes all the drivers drove collectively in a day
  • mileage [meters] – total meters all the drivers rode collectively in a day
  • orders past deadline – number of orders finished past declared deadline
  • total delay [minutes] – total sum of all the delays for all the orders in a day
  • 10 mins past delay – number of orders finished more than 10 minutes past declared deadline

The 4 algorithms were:

  • data replay, based on what really happened (Data)
  • incremental greedy Traveling Salesman Problem (TSP)
  • Vehicle Routing Problem with Time Windows (VRP)
  • Unified Planning Library with ready-made solvers (UPF)

Since the bin-packing and TSP variation combination are NP-hard problems, the UPF was not very successful in attempting to use it to optimize the issue. It was, however, very powerful when it was used as a simulation validator, where we solved the routing problem using either TSP or VRP and injected these solutions into the UPF solvers. The UPF was then able to plan the whole order process, from cooking until the delivery, using the prepared decisions and was used to validate all the orders were successfully completed, regardless of whether they were being delivered or picked up by customers.


The most suitable algorithm for the topic was VRP with Time windows. Based on the configuration, there are a few options we presented to the Partner. The following plot shows multiple configurations of this algorithm with the real data replay highlighted.

algorithm effectiveness plot

 As we can see from the plot, there are configurations that improve both metrics slightly (such as the green datapoint that improves the number of orders delayed by more than 10 minutes by 12% while also improving the drive time by 2%. There are also algorithms that improve the number of delayed orders significantly while only slightly worsening the drive time, such as the rightmost datapoint that reduces the number of delayed orders by 39% while degrading the overall drive time by only 8%. The Partner can choose what configuration he prefers to use and reflecting it into Recommender is possible via changing the app configuration

MVP-TSB for full integration

Selected algorithm (VRP) was implemented into the Recommender and deployed to The following image shows the UI that is presented to the Dispatcher at customer that uses it to guide his decisions on how to group orders into deliveries. A visual aid in form of a map is added to support the algorithm’s decision.

Filuta Recommender web UI

The KaaS Partner is now evaluating the solution in a form of weekly split A/B test, and we will incorporate any feedback they have.

Filuta Recommender deployed at customer's site

During the next period, we want to work with the customer to map the metrics to their monetary representation and we will be able to put a price on individual algorithms. This will allow us to further tweak the algorithms to find the best tradeoff between tracked KPIs to maximize the cost optimalizations for the Partner.