The problem we set out to solve and our proposal
When we started looking at Schiphol, what caught our attention was a gap. On an average day, security works well, but on disrupted days a storm, a strike or a lane closure is enough to create long queues. In 2022, staff shortages made thousands of travellers miss their flights, and Schiphol had to apologise publicly and compensate them (Symons, 2022). We realised the problem was not only capacity but coordination: an announcement that a new lane has opened sends everyone to the same place, and staff directing travellers by hand can only reach a few people at a time.
That led us to FlowPilot: instead of telling everyone the same thing, tell each traveller something different. It reads passenger and staff data in real time, detects imbalances between lanes and decides who should go where, prioritising those whose flights leave soonest. Generative AI turns each decision into a personal instruction, and travellers are sent in small waves so the new lane does not become the next bottleneck. Travellers without the app can scan their boarding pass at a screen, and supervisors keep the final say over staff moves. Following Furr and Shipilov (2019), we chose to adapt the existing operation rather than disrupt it, reusing Schiphol’s app, sensors and time slots.
What we’ve learned
Our way of working as a team was to divide the project by sections: Olha led the problem, opportunity and business model, Esme the economic and competitive analysis, and Jesilyn the future-market test and the final recommendation. Our parts still depended on each other, so we held regular calls to review each other’s progress and bring our ideas together, making sure the separate pieces added up to one consistent project. We learned to share early, imperfect versions so others could challenge them, and the strongest parts of the project came where one person’s work questioned another’s.
I, in particular, took on the part furthest from my comfort zone: building the prototype in Lovable and running the evaluation. With Jesilyn’s support, I built the operations dashboard, the passenger app and the Scenario Lab, and designed the scenarios, assumptions and metrics we used to test the idea. Together we also worked on the governance and failure analysis, which grew directly out of what the simulation revealed, and we leaned on each other throughout.
The turning point came from our professor’s feedback. We had planned to compare Schiphol’s Wait Times API data with its own published forecast, but, as she pointed out, that tested whether we could predict queues, not whether personalised guidance changes where passengers go. We rebuilt the evaluation as a simulation comparing four approaches (no guidance, a broadcast announcement, a human marshal and FlowPilot) while varying compliance from 0% to 100%. This also changed our core question from “will enough passengers comply?” to “how are their responses spread?”, because if everyone follows the same message, the bottleneck simply moves. To keep the comparison fair, we gave the marshal more compliance than the app (90% against 60%), since people follow face-to-face requests more readily (Roghanizad & Bohns, 2017).
The results surprised us. Broadcast guidance got worse the more people followed it: peak wait rose from 27 to 61 minutes. Average wait, meanwhile, barely moved across scenarios, while peak wait and missed flights changed dramatically; had we only looked at the average, we would have concluded that FlowPilot does almost nothing. Not everything worked: at low compliance the marshal beat FlowPilot, and moving staff after passengers had been routed created a new spike in the donor lane. We turned both findings into governance rules: check the donor lane before moving any staff, and rely on FlowPilot only once a pilot confirms real compliance.
We were also clear about the limits of our demo: it models one security hall during one peak hour (07:00–08:00), runs each scenario only once and relies on assumed values for arrivals, lane capacity and compliance, because we could not observe how real travellers react under stress. Our results show how the mechanism behaves, not how much it would actually improve Schiphol, which is why we see a shadow test with real data and a pilot in one hall as necessary before any wider rollout.
This project also changed how we think about AI. At first, we thought the AI would be the most valuable part of our idea. We realised it was the opposite: any company can use the same AI tools, so on their own they do not give anyone a real advantage (Barney & Reeves, 2024). What makes FlowPilot work is something only Schiphol has: control over the security lanes and live data on how busy each one is. The AI makes it possible to send a personal message to every traveller for a fraction of a cent, something that would otherwise take staff who can only reach a few people at a time. We also learned to be realistic. FlowPilot can make bad days much better, but it cannot fix everything: if there are not enough staff to open lanes, better guidance can only go so far.
For me, the most interesting part of the project was building the demo. I was impressed by how a tool like Lovable can turn an idea into a working dashboard and simulation in a matter of minutes, something that not long ago would have required a team of developers. A skill that used to be scarce, writing code, had suddenly become available to anyone, and the value moved to what remained scarce: judgment and the ability to frame the right problem (Harvard Business Review, 2025). What made our demo useful was everything the tool could not do for us: deciding how travellers behave, choosing a fair baseline and checking whether the results made sense. In that sense, AI lowered the cost of building, but not the cost of thinking.
Conclusion
Looking back, FlowPilot started as an idea about AI and became a lesson in how to build the case for one. A technology project is only convincing if it starts from a problem that is well understood: who is affected, how often it happens and what it costs when it goes wrong. Studying the 2022 crisis and how disrupted days are managed today is what gave our proposal a reason to exist. The business case then had to show who pays, who benefits and why the solution is worth it. The feedback we received, the results that surprised us and the limits we had to admit all pushed us in the same direction: away from what the technology can do and towards what actually changes for travellers on a bad day. The lesson we will take forward is that a good technology proposal needs both: a solid understanding of the problem and the opportunity, and an honest evaluation that asks what the solution should be compared against and which outcome matters to those who bear the cost of failure. For me personally, taking on the prototype and the evaluation showed that I can contribute to the technical side of a project without losing sight of the business question behind it.
References
Barney, J. B., & Reeves, M. (2024). AI won’t give you a new sustainable advantage. Harvard Business Review.
Furr, N., & Shipilov, A. (2019). Digital doesn’t have to be disruptive. Harvard Business Review, 97(4), 94–104.
Harvard Business Review. (2025). Strategy in an era of abundant expertise. Harvard Business Review.
Roghanizad, M. M., & Bohns, V. K. (2017). Ask in person: You’re less persuasive than you think over email. Journal of Experimental Social Psychology, 69, 223–226.
Symons, A. (2022, August 12). Amsterdam’s Schiphol airport compensates passengers for missed flights and apologises for chaos. Euronews.
