We explored whether Voetbaltrips.com could use AI to create personalized football trips, designing an interactive planner that an employee would use before making a booking. I focused on the business-related aspects such as pricing, unit economics, and the ecosystem that supports the planner. The most important insight I gained was that I needed to start by considering what the technology could achieve and only afterward think about the value it offered and to whom.
I decided to focus on the economics since I’m comfortable with figures, even though I had previously underestimated how important the subject is. Rather than carrying out actual calculations, I ended up deciding what to believe. Since there was no real company data, I based every element of my model on assumptions, from package prices to the number of inquiries that lead to bookings. At first, it felt like I was building a house on sand. Eventually, however, I realized this is typical when developing models for a new situation. The essential skill isn’t making the numbers precise but making the assumptions clear and showing which ones affect the conclusion.
My view of the issue changed. The first model I used was intended to present the case strongly, emphasizing AI as a cost-saving measure since it takes an employee much less time to check a shortlist than to prepare a quote from scratch. On my second review, I noticed two points I had earlier overlooked. I had assumed that saved staff hours could be treated as equivalent to saved money, whereas in reality those hours only translate into cash if the company ends up paying for fewer hours. Also, the positive outcome was based on a conversion increase that we had never actually measured. By making these two points clear, the conclusion changed from “AI pays off” to “AI pays off only at a certain volume and only if more customers book.” That was the main lesson: a recommendation is most useful when it specifies the conditions under which it applies, because only then does it tell a manager precisely which experiment to conduct.
Two points surprised me. The first was that a business case is weak if margins are narrow, the reason being that a large portion of the price of a travel package has to be paid to suppliers and therefore a small change in one of the assumptions can cause the result to go from a profit to a loss; earlier on I had regarded sensitivity analysis as being the final step, but in this instance it became the central part of the analysis. The second point was that the AI system, which I had thought would be the most important component, proved to be the one that was easiest to replace. In contrast, the ticket suppliers became the top priority because a perfectly recommended trip is useless if the tickets aren’t available. The pilot experiment gave us useful insights: participants who used the planner finished their tasks faster and produced more valid trips, and my initial reaction was to incorporate those results directly into my model.
Yet because the study compared two planning methods rather than the company’s actual quotation process, using it that way would have been misleading. Nowadays I always ask myself first, ‘What does this evidence really show?’ before wondering, ‘How can I use it?’ The failures also gave us some important lessons. The AI sometimes failed to keep up when participants changed the dates or group size. This could appear as a technical issue on a slide. In terms of a business model, though, it adds cost because someone has to identify and fix those errors. It is right to have a human involved, but that isn’t free, and I only factored that cost in after the failures forced me to. My teammates then took the question further by asking what would happen to our margins if our customers used their own AI agents to compare prices. I had no answer, and building that stress test showed that cheaper planning makes little difference when the trip margin itself is under pressure.
What I discovered after working on the project was that dividing up the tasks came easily, but reaching an agreement was difficult. The figures I used resulted from decisions made elsewhere in the project, and the other slides used the same figures, so changing one assumption would have affected the entire presentation. In the end, we adopted a single common model as the source of truth, but next time I would agree on the key assumptions on day one. I also ended up in a very uncomfortable position because my work included caveats. As a result, I was usually the one to reduce the team’s interest in achieving excellent results. I concluded that criticism is only useful to a team if it comes with an alternative, so I made an effort to rephrase each “this does not hold” as “this is what we would need to test.”
The biggest change was how I viewed AI and strategy. Before, I saw the main purpose of AI as automation—carrying out identical tasks more quickly and at a lower cost. This project has demonstrated that improved efficiency does not necessarily mean increased value. The key lesson is that a tool might improve every aspect of performance and still fail as a business if it doesn’t capture value. The most important feature of AI is usually also the easiest to copy. Since our team produced a working planner in just a few weeks, any competitor could do the same. What survives over time is what is hard to copy: namely, relationships with suppliers, reliable data, and the ability to deliver. As AI agents become more widespread across the market, I believe advice and planning will become inexpensive, with value shifting to the individual who controls the scarce foundations. The question I now ask about any AI idea is no longer “Can AI do this?” but “Who will capture the value when everyone can?”
Written by:
Diederik Beekhuizen, 664883db
