Behind the paper · ECIS · 2026
Schnitzel-Prediction: designing human–AI collaboration for cafeteria demand forecasting
Around a fifth of prepared cafeteria meals end up in the bin. The fix is not a better algorithm but a better partnership between the cook and the model.
“Schnitzel started as a temporary working title for the software. At some point nobody called it anything else, so we kept it.”
Read the story behind the paper
In brief
A fifth of every meal goes in the bin.
Cafeterias plan by intuition and spreadsheet, and planning has been treated as either a human problem or an AI problem.
Nine months of action design research.
Three cycles with a financial services association produced a forecasting system in which the algorithm proposes and the manager disposes.
The model beats history. The manager beats the model on novelty.
Thirty percent fewer errors than the naive baseline, better than the manager on two menus, worse on the newly introduced one.
Four principles for coexistence.
Override and capture, semantic cold-start, an attributable dashboard, and relatable communication, for systems where human context and pattern recognition must work together.
01 / The problem
A fifth of every meal goes in the bin.
Every week, the manager of a corporate cafeteria has to guess how many of each of three dishes several hundred employees will eat. She works from pattern recognition, lighter meals on Mondays; from context, the IT department has an off-site; from exceptions, construction noise may drive people out; and from creative judgement, how will they react to “hearty Tuscan bean stew”? She does this with experience and a spreadsheet, and about twenty percent of what the kitchen prepares is wasted.
Machine learning for demand forecasting is old and well proven. The reason it has not reached cafeterias is a design failure. Automation approaches optimise the algorithm and alienate the planner, then fail on the first unexpected event. Human-only planning cannot analyse years of data. Each failed automation erodes trust in AI, and each burnt-out planner takes decades of tacit knowledge with them.
The paper’s question follows: how can an information system combine algorithmic pattern recognition with human contextual intelligence for operational demand forecasting?
02 / The approach
Practice first, theory afterwards.
We ran three cycles of action design research with a regional financial services association in North Rhine-Westphalia between October 2024 and June 2025, each a loop of building, intervening, and evaluating with developers, domain experts, and the kitchen. Unlike most design principle work, which starts from theory, we deliberately started from operational problems and derived the principles afterwards by reflecting on what had worked, then grounded them in theory.
The first cycle proved feasibility with simple statistics at about sixty-five percent accuracy, and surfaced three demands from the partner: contextual factors, cultural holidays, and new dishes with no history. The second cycle moved to gradient boosting, added forecasts at one, seven, and fourteen days, a German holiday calendar, and semantic understanding of menu items via a language model. Weather was tried and dropped, because forecasts beyond a week made predictions worse. The third cycle shipped the system as a web application on the partner’s infrastructure in June 2025, where it has produced forecasts for the three daily menus ever since.
03 / The principles
Four principles for coexistence.
Each principle answers one of the requirements the project surfaced, and each is grounded in a kernel theory that explains why it should work rather than just that it did.
Human-in-the-loop override and capture
Integrate domain expertise and build trust
- How
- Let users review and adjust every prediction, and store the triplet of model prediction, human override, and actual demand as one dataset.
- Why
- Socio-technical systems theory: performance comes from jointly optimising the social and the technical. Overrides are signals, not mistakes.
Semantic cold-start resilience
Forecast dishes with no history
- How
- Have a language model decompose each dish into attributes such as vegan, stew, spicy, and feed those to the model instead of the dish name.
- Why
- Distributional semantics: a word is known by the company it keeps. Novelty is a recombination of known attributes.
Attributable impact dashboard
Make sustainability measurable
- How
- Visualise the divergence between prediction, override, and outcome over time, so managers see when to trust the machine and when their gut.
- Why
- Information processing and sensemaking theory: a waste figure is ambiguous data. An attributed divergence is a cue for learning.
Relatable communication
Lower reluctance and foster adoption
- How
- Explain abstract processes in humorous, domain-specific messages during wait times. For kitchen staff: “Neural networks are being breaded.”
- Why
- Computers are social actors: people apply social rules to machines. A likeable system reads as a colleague, not a surveillance tool.
04 / What the numbers say
The model beats history. The manager beats the model on novelty.
Two claims were tested separately: that the model improves on a naive baseline, and that it adds value alongside expert judgement rather than replacing it.
| Model | Average error (MAE, portions) | Gain over baseline |
|---|---|---|
| 7-day lag baseline | 25.3 | |
| Random Forest | 17.7 | 30.0% |
| XGBoost, deployed | 17.8 | 29.6% |
The tiny difference between the two learning models suggests the ceiling of what history alone can achieve. Feature importance tells the same story: calendar and holiday indicators matter far more than past demand. Context beats repetition. The second comparison, over 24 operating days in autumn 2025, put the model up against the manager’s own plans.
| Menu | Manager’s error | Model’s error | Result |
|---|---|---|---|
| Menu 1 | 26.6 | 20.5 | 22.9% fewer errors |
| Menu 2 | 23.8 | 19.3 | 18.6% fewer errors |
| Menu 3, recently introduced | 10.5 | 17.0 | Manager wins |
The manager herself beat the naive baseline comfortably, which confirms the value of expertise. The model beat her on the two established menus and lost clearly on the newly introduced one, where her judgement of an unfamiliar dish outperformed any pattern transfer. That asymmetry is the empirical case for the first principle.
In two think-aloud sessions, the manager and the partner’s head of AI used the system unguided. The manager completed the upload workflow immediately, called the interface “totally simple for us and, above all, very quickly done”, spotted that the forecast had correctly flagged an upcoming bridge day as weak, and set realistic expectations: “There will be deviations. That’s normal. This is primarily about the tendency.” The head of AI saw the same thing from above, and already had procurement integration and other group entities in mind.
05 / What it adds
Spend the time on the interface, not the decimal.
The contribution is not the system but the meta-design it instantiates: a class of systems for environments where new items keep appearing and human contextual knowledge is too valuable to automate away, and where success means diagnostic traceability and adoption, not accuracy alone. For human–AI collaboration research it is a concrete blueprint for synergy rather than augmentation, with the user reframed as a data source for what the model cannot see. For sustainable information systems it turns abstract waste data into something a manager can act on.
The practical advice is blunt. Managers should demand systems that respect expertise via override, explain themselves via diagnostics, and speak their language. Developers should stop chasing half a percent of error and invest instead in the semantic pipeline that handles novelty and the communication layer that gets the system used.
The limits are those of a single case: one cafeteria, one culture with its bridge days, 24 days of comparison, two internal think-aloud sessions, and a dependency on a proprietary language model, cheap though it is. The next steps are another domain, a longitudinal waste measurement, and using the captured override data to let the model learn the manager’s tacit knowledge over time.
Behind the paper
The idea, and
the path to it.
A paper presents the polished result. This is the part that usually stays unwritten: where the question came from and how the work actually unfolded.
This was one of the first projects of the Flow Factory, our joint research lab with the Sparkassen-Finanzgruppe, and it started in the most ordinary place imaginable: the partner’s own cafeteria.
Fun fact first. Schnitzel is one of the favourite dishes in that cafeteria. What started as a temporary working title for the software quickly became the name everyone used, in the company and among the researchers. At some point nobody called it anything else, so we kept it, and after some discussion it even made it into the final title of the paper.
Looking back, there is a deeper design lesson in that story. One of the hard parts of bringing AI into an organisation is making an abstract and often intimidating technology accessible to the people who will actually use it. In this project that idea became one of the design principles. During the few seconds the system needs to generate predictions, it shows kitchen-themed messages such as “Neural networks are being breaded” and “Rolling out apple strudel algorithms”, culinary reinterpretations of what machine learning is doing. Rather than presenting AI as a mysterious black box, the system speaks the language of its users. These small decisions turned out to be surprisingly powerful. They sparked conversations, reduced barriers, and helped the system spread through the organisation.
Many thanks to Justus Cappel, who led the development of the system, and to Mara Burger, Marleen Voß, and Jan vom Brocke for a great collaboration. And my thanks to the Sparkassen-Finanzgruppe for the collaboration and for the openness to let researchers into their cafeteria. We presented the paper at ECIS 2026 in Milan.