Where the idea came from
Most of us on the team have been in that situation, standing in a security queue at Schiphol, watching the clock and working out whether we would still make it to the flight. As a non-EU passport holder, I was also stressed about the passport control that I still had to go through before boarding. So I always arrived as early as possible, and even that did not guarantee I would reach the gate on time. Many people around us had similar stories, especially from the summer of 2022. When the AI Strategy Lab was introduced, we chose the topic almost immediately.
What I did not yet know was whether the course could help me see the problem differently. My initial impulse was to reason from a passenger’s perspective. Since the lines were long, the answer seemed to be predicting them better. This project taught me how limited that first approach had been.
My role
Our team of four divided the project deck into three core workstreams. I took the first, defining the problem, mapping the opportunity, and designing the business model. I chose to work on it because I enjoy laying the foundation on which the project rests. I had also been closely involved in generating our topic, and by the time we settled on Schiphol, we had many puzzle pieces. They included our own queue stories, the 2022 queue crisis, Schiphol’s time slots, the security contractors, and the idea of telling each traveler something different. What interested me the most was fitting those pieces into a structured foundation, which forced me to understand the whole project before anyone else could build on it. My job was to explain why the problem matters, who benefits, and how value is created, delivered and captured.
What surprised me
My first expectation was simple. Schiphol does not see the queues coming; therefore, an AI model should help to predict them. While preparing the proposal, I found an interview with a Schiphol product manager (Future Travel Experience, 2025) that contradicted my expectation. It stated that Schiphol already uses sensors, models and a digital twin, and lets 99.6% of passengers with booked time slots wait under ten minutes.
Schiphol’s gap is not prediction but acting on it. As we learned in Session 6, a prediction only creates value when someone redesigns the decision around it (Agrawal et al., 2018). We had planned to test our forecasts against Schiphol’s; however, the feedback to the proposal pointed out that this would only test prediction, not whether the guidance changes behavior. This flipped our project from prediction-focused to decision-focused.
My second expectation was that providing more information to users would result in better system outcomes. We expected that if passengers knew where the shortest queue was, they would spread out across lanes. However, our simulation results revealed the opposite. When a new lane opened and this was announced to everyone, a large share of each queue moved at once, and the new lane grew into a 47-minute queue, almost double the 25-minute peak with no guidance at all. Session 5 provided an explanation for this effect, a negative same-side network effect (Eisenmann et al., 2006), where every extra traveler following the same advice makes congestion worse for everyone else. This was our turning point, as the core problem was not an information deficit, but one public signal reaching everyone at the same moment. Instead of predicting queues, FlowPilot would allocate travelers, giving each person a different instruction so the crowd spreads out.
My third expectation was that a good idea needs a revenue stream. Our business model has none, by design. Charging travelers would cut the take-up the system depends on, since every traveler who follows an instruction shortens other people’s queues. Instead, Schiphol pays for FlowPilot and earns its return indirectly, through avoided compensation for missed flights and stronger negotiation terms with airlines. What surprised me most was that a product can pay off without charging the people who use it.
What failed
Some lessons came from small mistakes. My first slides put the problem at about 275,000 travelers a year, because the estimate counted all passengers, although arriving passengers never pass departure security. Later we replaced it with 180,000 to match our economic analysis, but the deck still described the problem in three different ways until we caught it during our final checks. Initially, I had also assumed that the Schiphol app sends travelers personal instructions, until we checked and found that it only shows everyone the same wait times. Both claims had been checked once, but they drifted as we rewrote them to fit the narrative. I learned that a fact has to be rechecked every time it is reworded, not only when it is first found. This mattered the most for my part, because every slide after the problem definition was built on it.
Collaboration
I underestimated how much the foundation depended on others. My business-model choices fed my teammates’ economics, and their numbers fed back into my slides. Early on we set up a shared table of assumptions, from passenger numbers to the cost of a missed flight, so that four people would not invent four versions of the same figure. Our table covered numbers, but not words, so next time I would start with a shared document of core facts and terminology.
Demo Day brought a different challenge. Explaining a whole course of work in about 10 minutes seemed impossible, so I suggested keeping it simple. We started with a queue visitors had stood in themselves, showed how security works today, and only then presented our demo as the improvement. Because the story was easy to follow, visitors engaged with the product rather than the slides. One visitor asked whether FlowPilot would keep people traveling together in the same queue, something our model had overlooked because it routes travelers one by one. This experience made me learn that a simple pitch is easier to present and also invites better feedback.
How my view of AI and strategy changed
Before this project, I assumed the AI model would be both the product and the advantage. FlowPilot taught me the opposite. The AI was the cheapest part of our solution, about one percent of its yearly cost, and the easiest to replace. As Barney and Reeves (2024) argue, a model anyone can rent gives parity, not advantage. What made FlowPilot hard to copy was how the AI was integrated into Schiphol’s own processes, linking live sensor data, the supervisors who decide when to open a lane, and the app that reaches every traveler. A competitor can rent the same model, but not the processes around it. Ultimately, AI strategy is less about what a model can predict and more about how its outputs are built into the way an organization decides and acts.
I used to treat a queue as a personal problem, solved by finding the shortest line. I now see it as a system, where the best outcome comes not from each traveler choosing well but from someone allocating them well.
References
Agrawal, A., Gans, J., & Goldfarb, A. (2018). A simple tool to start making decisions with the help of AI. Harvard Business Review.
Barney, J. B., & Reeves, M. (2024). AI won’t give you a new sustainable advantage. Harvard Business Review.
Eisenmann, T., Parker, G., & Van Alstyne, M. W. (2006). Strategies for two-sided markets. Harvard Business Review, 84(10), 92–101.Future Travel Experience. (2025, July). How Schiphol is leveraging tech, design, data and AI-powered intelligence to redefine airport capacity and flow management. https://www.futuretravelexperience.com/2025/07/how-schiphol-is-leveraging-tech-design-data-and-ai-powered-intelligence-to-redefine-airport-capacity-and-flow-management/
