When we first started, I thought this project was about finding a clever use for AI. By the end, I understood it was about a problem. Schipol is capable of managing the average day, but on disrupted days, when they are short on security staff or a lane closes, capacity and coordination fail together. Defining the problem clearly turned out to be the most useful thing our team did. Whenever we iterated, we went back to one question: does this change help on a disrupted day? It settled several decisions quickly and stopped us from adding features just because they were interesting.
My Role:
I was mainly responsible for the future market test and the final recommendations, and I worked with Laura on the prototype and simulation. The two pieces fed each other. The simulation gave the recommendations evidence, and writing the recommendations showed me what the simulation still couldn’t prove.
The feedback that changed our test:
The most important iteration was our test. Our original plan was to collect Schipol’s API data every five minutes and compare it with Schipol’s own published prediction. We received feedback after our initial submission that our idea was strategically strong and well developed, but the feedback pointed out that our key assumption and our test weren’t aligned. Comparing API data with a published forecast tests accuracy, not whether personalised guidance changes what passengers do. One of the suggestions we received was to keep the concept but simulate broadcast guidance against differentiated lane instructions, judged queue length, load balance, compliance, and missed-flight risk, with the API data used to set up the simulation rather than serve as the experiment.
This feedback was the most useful as it was specific and true. Our own argument was that value comes from sending different travellers to different places, so the thing to test was the response, not the forecast. We moved to a simulation of three scenarios: no coordination, a broadcast announcement, and our coordinated approach. Our peers also told us it was a good initiative, which was encouraging, but the feedback we received after our first submission is what actually changed the work.
What surprised me:
I was most surprised by our simulation. I expected the broadcast announcement to land somewhere between nothing and our approach. Instead, at 100%compliance, it produced the longest wait of all three scenarios: 61 minutes, against 25 with no coordination and 20 with our approach. Everyone was told to go to the newly opened Lane 7, and it became the next bottleneck. The imbalance between lanes told the same story: 54 minutes under broadcast and 6 under our approach. The average wait barely moved (12.9 minutes against 10.8), which taught me that the average hides exactly what matters on a disrupted day.
The results also showed a limit. The chart showed a short spike on Lane 4 right after staff was relocated, so even coordination isn’t free. These numbers come from a simulation with assumed passenger behaviour, full compliance, and 50% opt-in, so they show the mechanism, not proof that it works. That shaped my recommendation. Instead of implementing everywhere, I wrote a staged roadmap: a shadow test, then a three-month pilot in one hall on disrupted days, with clear measures at a gate before each step and a rule to fix and repeat, or stop, if a gate fails.
What was hard:
The future market test was the hardest part for me. We had to imagine a world where customers, suppliers, platforms, and competitors all use capable AI agents, and ask whether we could be bypassed. For a long time, I couldn’t find a convincing way. A traveller’s agent can only see estimated wait times Schiphol publishes, while our approach depends on live lane monitoring and staffing data that only Schiphol has. I couldn’t explain how an agent would know which lane was busy. The honest answer was that data isn’t the weak point; attention is: a traveller who follows their agent’s generic advice may never see the allocation made for them. So our strategic adjustment was to let agents request allocations from us, rather than compete with them.
Checking our own claims mattered as well. We had described the 0.4% as days when it referred to passengers, a reminder that airline agents shouldn’t be able to buy priority for business-class passengers. Allocation by published criteria, such as departure time, is fairer, and selling priority would turn allocation into pay-to-win and undermine the load balancing the whole idea depends on.
Working with the team:
Our team worked well together. We never had a serious disagreement; we were open about feedback, and we helped each other whenever someone had a doubt or question. We had several brainstorming sessions not only about the content of our presentation but also about what we wanted it to look like so that the slides could speak for themselves and follow a coherent storyline. Additionally, if we noticed something while reviewing a part done by another team member, we immediately addressed it – For example, when I couldn’t understand certain calculations made by another team member, we all reviewed it together to make changes and double-check the work. This taught me that openness made us faster: because nobody was defending their own work, we adapted as soon as we saw the flaw.
How my view of AI and strategy changed:
Before this project, I assumed competitive advantage in AI was a race to adopt the newest technology fastest. Barney and Reeve’s argument changed that. AI doesn’t create an advantage on its own; it strengthens a company that already has a sustainable one. In our case, the language model that writes messages can be rented by anyone, so it gives parity at best. The advantage lies in assets Schipol already controls: the lanes, the live sensing data, and the right to decide who goes where. That is also why we split the design. A deterministic optimiser makes the safety-adjacent decision, and the language model only communicates it.
It also changed how I think about value capture. Schipol doesn’t earn revenue from giving better advice, because advice is easy to copy. It captures value through avoided costs and reliability terms with airlines. The question for a company isn;t ”how do we use AI?” but ”which technologies create value for us, and how do we capture it?”
Next time, I would run the simulation at several compliance levels from the start. 100% compliance is the best case, and the real pilot is where our key assumption finally gets tested.
Overall, I learned a lot through this journey along with my team and have gained a better understanding of the strategic uses of AI and how AI brings value to organisations.
