Our idea created in the AI strategy lab assignment was an AI review tool for event permits. When organising an event you have to apply for a permit with the municipality where you want to host the event. These are very extensive documents and there is a lot of going back and forth between municipalities and organisers to make sure everything aligns before a permit is handed out. We wanted to make this more efficient mainly for the organisers as there is a lot of stress in organising an event which you do not have a permit for yet.
My role in the assignment was mainly in translating our idea into an economically viable business model. I was involved in specifying the problem, identifying the opportunity, identifying the stakeholders, mapping the ecosystem, shaping the business model and calculating the economics. As well as using my prior professional knowledge into shaping the final recommendation. I work in an IT startup that has municipalities as its customers so this gave me a trained business perspective for this assignment.
The problem
It is necessary to have a distinct problem to solve for a specific customer which you have to offer a justifiable business model. And even when you have this knowledge, it remains a real challenge to translate this into a convincing strategy when there is limited evidence available supporting your proposal.
Our idea was introduced by our teammate Danique as she had experience with organising events and requesting permits. I started with researching the problem. It was difficult for me to define the problem however. Should this be done in possible consequences for organisers, hours saved for employees or a financial gain? I identified that the main value created was the increased productivity of employees that resulted in freed up time. So I decided on showing the size of the problem by making an approximation of the hours spent on permit review in the municipality of Rotterdam.
Another challenge was to identify and prioritise all the stakeholders who were involved. The municipality, organiser and fire and police department all benefit from Eventklaar. However, who benefited the most and who would be willing to pay for the tool? Not only was this important for the business side but also for the technical side. Who actively used the tool? We settled on focusing on the municipality reviewer as well as providing an organiser with a more concrete review on how to improve their request.
Defining the problem is not just identifying inefficiencies. The challenge is to determine who receives value, and who is willing to pay for the solution. Also, a complex ecosystem can create an unclear business proposition so it is essential to define stakeholders roles clearly. This caused some misunderstanding and discussion within our group on how we would integrate our tool in the workflow. If we would have mapped out the ecosystem earlier it could have saved us extra revision work later on.
Business model
Initially, we started the route of Track A in redesigning the workflow. We identified the inefficacies and proposed a new workflow. In the later stages we revised this approach because we saw the strategical opportunities of scaling our solution. Eventklaar would only need small tweaks and updated local regulation to be used in other municipalities as well. So we decided to change to Track B to be able to reap these benefits. This way we could centralize our technological development and these costs would be spread across multiple customers. We noted that, even though the software is scalable, there would still be individual customer development costs because of local permit rules. As well as that this created a second internal business model that was dependent on attracting new customers and thus creating overhead costs like marketing and sales.
This was a new way of looking at our solution. Although everyone clearly understood that this would mean that we would have a new type of business model, not everyone understood that this created a whole new internal business model. Because of my experience in this sector I identified this and shared this with my teammates. The municipality business case revolves around receiving enough value to justify purchasing a subscription. The Eventklaar business case revolves around having enough subscription revenue to be able to afford technological development and overhead costs.
Economics
The economics for the business cases were based on a lot of assumptions. For the municipality we had to estimate the time that is saved by our AI tool. For the Eventklaar the biggest estimation was the technological costs. The rest of the costs we classified as overhead and did not estimate a number. Marketing and sales are a investment as the costs would generate more revenue. However, to determine a fair price we did not deem this necessary to include in the business model for now.
A big insight was that the price should be significantly less than the monetized saved hours as these hours did not directly result in a financial gain for the municipality. In the initial draft we did not state this clearly, and this sparked internal discussion as to maybe raise the price of the subscription. After everyone concluded that our business proposal improved productivity and not automatically realised a financial gain we could settle on the price.
The calculations of the economics made me realize how important it is to make distinctions in estimated and measured values. Because an illustrative business case can give an impression of an accurate one while being dependent on a lot of assumptions and estimates. This could also, for example, lead to a misleading business case when these assumptions and estimates are not clearly communicated.
Collaboration
Overall, i experienced our teamwork and collaboration as positive. All the members were communicating clearly and actively participating in the project. Our discussions were also productive in creating new insights, for example, in the customer/user discussion.
A lesson I learned from our collaboration is that verbal agreements should be as clear as possible. It happened a couple times that not everyone had the same understanding of the decisions we made. This resulted in work being made that had to be revised later. For upcoming assignments, I will suggest ending discussions with a written conclusion to specify the agreements and share written drafts more frequently to make sure everyone is aligned with a shared vision.
Conclusion
AI strategy is not merely about creating a nice tool. There are some checkboxes that need to be checked before you can successfully implement a tool. Although we found 94% of the gaps, we missed one critical one. Thus we advised to revise the tool first before scaling which highlights that technological promising tools are not always ready to be implemented. On top of that, the business case behind the tool should be perfectly aligned. An effective tool does not mean an attractive investment when expected benefits are uncertain.
That AI tools can automate business processes is certain. To make the automation of thus processes valuable it is way more important to have a thought-out approach to the economics, implementation and strategy.
