Where the loss arises

Stattküche GmbH has prepared lunches for schools and kindergartens around Münster for more than four decades. According to the European Digital Innovation Hubs Network, it produces about 22,000 portions a day. A family may order a meal in advance but neither collect nor cancel it in time. The kitchen learns about actual demand too late, and surplus prepared food has to be discarded for hygiene reasons.

The task is not to have a model “invent the menu.” It is to estimate how many ordered portions, by site and menu type, will not be collected on a particular day. Both directions of error are costly: a surplus creates food waste and ingredient expense, while excessive cuts can leave people without a meal. The forecast should therefore support a planner rather than dictate one automatic production number.

The company approached the European Digital Innovation Hub EDIH-DO. Its case study describes a pilot outcome: the kitchen gained access to historical-order analysis, daily forecasts, and a way to adjust production volumes. But an explicit caveat in the primary source matters more than a polished presentation: quantitative evidence of waste reduction and cost savings has not yet been published. This is an operational forecasting example, not a proven return-on-investment figure.

What happened to the data

Before the project, order logs were held by an external IT provider, and the company itself lacked convenient analytical access to its history. The EDIH-DO team obtained raw records from 2020–2023, cleaned them, and aggregated them by production site, date, and menu type. The team also considered public holidays, weather, and information about flu waves. Smaller businesses will recognize the obstacle: data exists in a service, but export rights, permitted use, and consistent menu names can be harder to sort out than the algorithm.

Several approaches were tested: Random Forest, XGBoost, ExtraTrees, and the SARIMAX time-series method. The project description says ExtraTrees had the best accuracy on held-out data. However, the primary source does not provide an error value or a comparison with a simple forecast based on similar past days. It would therefore be wrong to claim that this particular algorithm is universally superior for every canteen.

The result was packaged as two documented Jupyter notebooks: one for exploring the data, and one for daily forecasts with scenario switches. A separate Python script prepares data so the model can be retrained when a regular feed becomes available. According to the case study, no extra hardware was needed; the hub supplied expertise and computing resources, while the company supplied staff time and process knowledge. The pilot was funded by the hub, so its budget cannot simply be copied into a commercial project for a Russian company.

A repeatable architecture

For a canteen, caterer, or central kitchen, the first requirement is not an LLM but a dependable event table. At minimum it needs date, site, menu type, confirmed orders, actual servings, and late cancellations. A school calendar and holidays are usually useful; weather and other external features should be added only if they improve forecasts on later periods.

A practical flow could be:

  • Agree on a regular export from the ordering system and verify the right to store and process these records.
  • Normalize site and menu identifiers and order statuses; distinguish returns and corrections from genuine cancellations.
  • Compare a simple baseline with several models on successive held-out weeks without mixing future data into the past.
  • Show the planner a range, the history of errors, and reasons for manual adjustment rather than a single “magic” number.
  • Record each day's forecast, actual servings, prepared portions, surplus, and shortages.
  • Retrain on a schedule and separately test whether quality deteriorates after menu or calendar changes.

At low order volumes, a simple calendar-based calculation may beat a complex model on transparency and maintenance cost. With many sites and different demand patterns, a model may help—but the choice has to follow measurements on the operator's own data. An independent study on canteen meal forecasting likewise starts with booking and attendance history and considers seasonality and holidays. It does not verify Stattküche's outcome, but shows that the problem extends beyond one company.

A local deployment is realistic here: the order table, batch feature preparation, and a small forecasting service can run on an existing server or workstation. A language model is optional. It might separately explain deviations to a Russian-speaking planner, but it should not replace the numeric forecast or source-data checks. Student personal data usually need not enter a portion-count model: aggregates by site, day, and menu are often enough, subject to the actual process and its data requirements.

Economics and pilot limits

For an internal calculation, compare the cost of building and maintaining the export, preparing data, computing forecasts, and planner time with two effects: less surplus purchased and cooked, and less discarded after service. Include the cost of shortages and a safety margin. The goal is not “zero leftovers at any cost” but the lowest total cost at an acceptable service level.

Start with one site and several weeks in shadow mode. Produce a forecast each day, but let the planner continue deciding under the old process. This reveals where the model overestimates cancellations, how it behaves during holidays, and whether the safety margin can be reduced. Then agree on a small permitted adjustment band and measure outcomes on real days. Do not declare success merely because forecast error has fallen; measure waste, expense, and instances when meals ran short.

The managerial lesson from Stattküche is the sequence: first access to orders and consistent data, then comparison of algorithms, then a tool kitchen staff can understand. Vnutrik the robot intern may cheerfully bring another empty tray “just in case,” but a person decides tomorrow's portion count using the data and service requirements.