KLM's caterers used to load a meal for every booked passenger. Some booked passengers don't turn up, so on a typical flight some of those meals went in the bin. In February 2024 the airline said a model called TRAYS, built with the Dutch non-profit Kickstart AI, could cut that waste by up to 63%. It's a good example of AI across business functions, because the model's value comes from joining data that sat with different teams, bookings and check-in on one side and catering orders on the other.
The model is rarely the hard part. The data it needs belongs to two departments that have never had to share it, on different systems with different IDs, and nobody owns the decision the model is meant to change. Amazon and KLM are two well-documented cases where that got solved, and what each had to connect is the part worth copying.
If you're deciding where AI should go next in your own company, the same pattern gives you a place to look. Start from a decision one team makes often and gets wrong at a cost, then ask what another team already knows that would change it, and whether the two can be joined on a customer, a product or an order.
Updated by the TechFabric editors in October 2026. The Amazon and KLM figures were corrected against their sources and dated, and the method for finding the same opportunity was added.
KLM: passenger forecasts feeding catering
What it does. TRAYS predicts how many passengers will actually fly in each travel class, starting 17 days before departure and updating until 20 minutes before. Catering orders follow the forecast instead of the booking count.
What it achieved. Against catering for every booked passenger, KLM reported up to 63% less food waste. The biggest gains were on intercontinental flights from Amsterdam Schiphol, at about 2.5 fewer meals, or 1.3 kg, wasted per flight. Scaled up across all KLM flights catered from Schiphol, KLM estimated a saving of 111,000 kg of meals a year. The model went live after a three-month test.
Why it's cross-functional. The forecast lives in one domain (passenger and booking data, owned by commercial and operations), and the decision it improves lives in another (catering, often run with an outside supplier). Neither team could have built it alone. The window matters too. A forecast at 17 days lets catering plan, and the update at 20 minutes is what lets the final numbers match the cabin.
Amazon: product data feeding packaging
What it does. Amazon uses machine learning to choose the packaging for each product, such as a padded mailer, a paper bag or a box, and whether a product can ship in its own container. Amazon Science described the approach in January 2022. The model combines natural language processing over product descriptions and customer feedback with computer vision on images taken in fulfilment centres, so it learns from both what a product is and how it actually arrived.
What it achieved. At the time Amazon said these tools had helped reduce per-shipment packaging weight by 36% and eliminate more than a million tons of packaging, equal to more than 2 billion shipping boxes, over six years. Amazon's own figure has grown since. Its sustainability page, updated in August 2026, says it has avoided more than 5.4 million metric tons of packaging since 2015, across all its packaging programmes.
Why it's cross-functional. The inputs come from at least three places. Product data comes from the catalogue, damage signals from customer service and returns, and images from fulfilment operations. The decision lands in a fourth, packing. The model is only possible because those data sources can be joined on the same product.
What both cases have in common
Both cases share four features.
- A decision that's made with less information than exists elsewhere in the company. Caterers ordered by booking count while operations knew who usually doesn't show. Packers chose boxes by rule while customer service knew which products arrived damaged.
- A shared key that connects the data. A flight number and date for KLM. A product identifier for Amazon. Without a common key, the data can't be joined and the model can't learn.
- A measurable outcome in money or waste. Kilograms of food. Tons of packaging. Both projects could show they worked.
- A decision owner who acts on the output. The forecast changed what catering loaded, and the recommendation changed what the packer used. A model whose output nobody acts on saves nothing.
Finding the same opportunity in your business
The four points above work as a method. Run through your own operations looking for them.
Start with decisions, not data. List decisions that are made often, cost money when wrong, and are made by one team. Order quantities, staffing levels, credit limits, stock allocation, maintenance schedules.
Ask what another team knows that would change the decision. Sales knows which customers are about to place large orders. Customer service knows which products generate complaints. Maintenance knows which machines are about to fail. If that knowledge isn't reaching the decision today, there's an opportunity.
Check for the shared key. Can you join the two teams' data on a customer, product, order, site or date? If the CRM and the ERP use different customer IDs, fix that first. It's unglamorous work, and it's often most of the project.
Measure the cost of the current decision. Waste, overstock, stockouts, write-offs, overtime. If you can't put a number on how wrong the current decision is, you won't be able to show the model is better.
Name the person who'll act on it. Before building anything, agree who changes what they do when the model says so, and how they can override it.
What gets in the way
Three obstacles come up repeatedly.
Data quality at the joins. Each team's data may be fine for its own purposes and still fail when combined. Different definitions of an "order", timestamps in different time zones, and products renamed in one system but not another. Expect to spend real time here.
Ownership. A cross-functional model belongs to no single department. Decide early who funds it, who maintains it and who is accountable when it's wrong. KLM brought in an outside partner to build the model, which works too, as long as someone inside still owns the decision it feeds.
Trust. The people making the decision today have experience the model doesn't. Start by running the model alongside the current process, compare the two openly, and let the decision owner see the model's reasoning where possible. Adoption follows evidence.
Making the data available
Both projects depended on getting data from several systems into one place where it could be joined, cleaned and modelled. For most companies today that means a shared data platform where each system's data lands with consistent definitions and access controls, so a model can use sales, service and operations data together without each team copying spreadsheets to the others. Our data engineering work is usually that first step, and if you have a decision in mind that another team's data could improve, talk to us.
Frequently asked questions
What if the two teams' data can't be joined on a shared key?
Then the model has nothing to learn from, so the join comes before any modelling. If the CRM and the ERP use different customer IDs, we'd treat building that mapping as its own piece of work with its own owner. Expect the join to fail in ways neither team's data showed on its own: different definitions of an order, timestamps in different time zones, a product renamed in one system but not the other.
How do we show the model is better than the decision we make today?
Put a number on the current decision before you build anything, then run the model alongside it and compare the two on that same number. That gives you a baseline to beat, and it gives the decision owner something to look at besides a claim. KLM's 63% figure only means something because it was measured against catering for every booked passenger.
Does it matter if an outside partner builds the model?
It doesn't, as long as the decision has an owner inside the company. The partner can build the model, but someone on your side has to change what they do when the model says so. Settle who funds it and who answers when it's wrong before the build starts.
Sources
Checked 11 October 2026.