The idea I proposed originated from something I experienced during my term on the board of my student association. During that year, I had to submit several event permits, and this process was very time-consuming because it involved a great deal of back-and-forth emailing before the municipality had all the necessary information. Although the municipality’s website states that a permit application takes eight weeks, when a submission is incomplete, the municipality is allowed by Dutch administrative law to suspend this 8-week decision period to request additional information. During my board year, it took at least five months to get each permit approved. As a result, we also faced the issue of incurring upfront costs on rentals before the permit had even been approved. My own experience convinced me that this process could be handled more efficiently, and the frustration and uncertainty I experienced provided a starting point for this project.
However, when we tried to support this claim with data, we found that there was no published data available from Rotterdam regarding the pains associated with this process, such as correction rounds or processing times. Therefore, we had to borrow the processing time per permit of 4.5 hours from Súdwest-Fryslân. Targeting the event organizers was unrealistic, because organizers are often small groups. They only submit requests a few times a year and are unlikely to pay for our tool.
Although the idea started from the organizer’s side, after several discussions we concluded that the greatest benefit lay with the municipality’s employees. Consequently, the application’s main added value became improving employee productivity and freeing up time. Siger therefore framed the problem around the hours spent on processing each permit. With this shift in perspective, we began shaping our strategy from the Track A viewpoint, attempting to visualize and transform the workflow. While EventKlaar showed promise in that context, we ultimately opted for Track B due to the strategic potential to scale the solution to other municipalities in the future. From my perspective, this was a logical choice, given that the software is scalable when adjusted per local bylaws, and I expect other municipalities would also value the time savings provided by this automation.
Within the project, I was responsible for the as-is design, the to-be redesign, and the agentic future test. Additionally, I ensured the entire PowerPoint presentation followed a unified theme rather than using four different styles. In the to-be redesign, I chose to place EventKlaar before the loop from the services review back to the organizer. Because of my board year experience I labelled this as “takes the most time”. Putting EventKlaar before that loop means partners receive a file that has already been checked. At the time, I based this on the experience of having at least three rounds of back-and-forth to add extra information or clarity to our submitted documents. However, looking back this was sometimes also when the services were already looking at the documents, so I am not completely sure we will prevent this with the current EventKlaar solution. In the as-is design I deliberately stated that advisor capacity is not addressed. This is because EventKlaar speeds up checking files, not the number of advisors. If advisor capacity is the real bottleneck, saved review time may not turn into faster permits. Instead of the back-and-forth, the organizer receives one complete list. This choice came from having a clear overview of the missing information and knowing that when these are resolved the submission can go to the next phase of the process.
Before I started working on the agentic future test slide, I had not considered the possibility of organizers using an AI agent to write their permits. This is because before this course, I did not comprehend the possibilities of AI in the future. In particular, I had not considered gaming where an AI agent would keep resubmitting until it passes. This is something I became aware of during this course. The agent would write based on the 41 publicly available rules, so every submission will look as if it is complete. This results in a loss of value for EventKlaar, because a complete document is not a correct document. When this happens, EventKlaar would need to check whether the claims made by the organizer are really being fulfilled. This showed me that the value of an AI tool is not only dependent on what it does, but also on how the organizers respond when a tool exists.
The collaboration was mostly individual, with occasional calls to check in and decide. By dividing the work, with Siger doing the economics, Luka the prototype and Anne the Business Model Canvas, we optimized the deliverable, but not each person’s learning. At first, I was going to do the economics, but as I struggled to use assumptions to create a realistic cost overview and Siger could use his work experience, he took over this part. Handing off certain parts of the assignment gave me the feeling I did not learn everything this project had to offer, such as the economics and building the prototype with AI coding tools. In hindsight, I would prefer to work together on campus, to experience the learning moments together and teach myself to take more time rebuilding one teammate’s decisions before agreeing to them.
Looking back at this project, the course has opened my eyes to the possibilities AI can be of use in a company, it is not a solution you just implement on a problem. It is really important to adapt your strategy and idea along the way, by being critical of the value it may bring.
