Our AI strategy Lab venture was an AI procurement-risk agent for small and mid-size general contractors in construction. The agent evaluates the cost of every disruption within a project and prices three possible responses based on comparable historic cases: accept the delay, switch to a different, slightly more expensive supplier, or pay the supplier extra to speed up the production or transport. The agents calculate the costs of these options, but the final decision lies in the hands of the manager.
My main contribution to the team project was the economics part and the ecosystem part. For the ecosystem I worked partially together with another teammate and some parts I did on my own.
When I started to come up with the pricing model, I did not really know how to set a price for an information system. My view before was that you look at similar products, take your costs and put a margin on top. The initial cost is significant but after that replicating this and running the program costs close to nothing so I had to rethink my approach to this task.
While going through the economics session of the course, I came across the willingness to pay (WTP) hypothesis, and it opened my eyes to how an information good should be priced. The question is not what it costs us, but how much value it brings to the contractor and how much are they willing to pay for it. I estimated this mainly through the manager’s time saved on assessing a disruption.
We planned to use versioning with two tiers since the beginning of the project. The base tier uses only the contractor’s own history, while the premium also uses our pooled data across all projects that we have supported. While I was estimation the WTP I realised that contractors that have much more expensive projects might be willing to pay much more for our system because it would save them much more money than ones with smaller projects. After consulting this with my team we decided to also include group pricing based on the value of the project.
I wanted to make the clients pay a monthly or yearly subscription for our agent but after consulting this with my team we realised that there would be a conflict of interests. Our venture would earn more money the longer a project goes so it does not promote solving the delays. I decided to move to a per project subscription, so both us and contractors would benefit from the project going as smoothly as possible. Similar logic made me not even consider charging them per tokens or analysis because a manager could ask himself: “Is this disruption worth the cost of the analysis?”
When we started working on the ecosystem part of our venture I thought we were building a platform because before the ecosystem session I saw any product with a lot of users and data as a platform. The idea of building a platform sounded like a solid statement.
After diving deeper into the course content and learning what a platform is I realised that a platform needs two sides that interact with one another on the platform. Our contractors do not interact with each other, information flows from a contractor, through us, and back to them. While brainstorming the platform question with my team we decided to include a future scenario when we could become a platform. We thought about including the suppliers and making it a platform but we decided that if we were to do it from the start of the venture would be a disadvantage because we would have to attract both sides at once, suppliers’ ratings would be based on very little data and contractors might stop trusting that our recommendations are neutral.
I wanted to relate a concept from one of the lectures to our project so I also analysed the subside vs money side of the potential platform that we would form. The ladies night example really allowed me to grasp the concept of subsidy and money side. In the case of the potential platform the Contractors are the money side since they heavily rely on suppliers to be able to operate. The suppliers are the subsidy side they have potential access to the contractors but the increase in the number of them within the platform makes the platform more attractive for the contractors. This analysis allowed me to better understand the roles within the ecosystem.
I identified two same-sided network effect even with our venture not being a platform. The positive network effect is that the more contractors in a segment use our system the more comparable records we have, so estimates improve and our system becomes more valuable, so more contractors want to join accelerating this loop. The negative effect would be competitive fear: as more direct competitors join the pool, contractors may fear that rivals could learn their costs and suppliers, in turn making them less willing to share their own data with us. We thought about becoming a platform so I wanted to see what network effects would arise if we do so. I found a cross-sided negative network effect for the suppliers if they were to join. The effect is the more outcomes of disruptions are reported the more price, and performance transparency is given to the contractors by the suppliers which leads to lower suppliers’ margins. Fewer suppliers might be willing to join the platform.
We all worked on the whole project together, but split some of the tasks so we could dive a bit deeper and then discuss the results with everyone. Often I was sure that my idea was right, but after discussing it with my teammates I would see and understand my perspective questioning whether my assumptions were correct. By pooling our brainpower we managed to improve the final solution. The two biggest changes in my part were dropping the yearly subscription and realising we were not building a platform. Saying things out loud made me realise that sometimes I was agreeing with myself too much.
Before the course I had limited knowledge of AI. I did not use a lot of AI, and I did not even know what an AI agent was. Through the project and the course overall not only did I learn what an AI agent is but also that the technology is the part others can easily copy because everyone has access to it. Our tests showed that the Agent is only as good as the comparable data behind them.
All in all, I really enjoyed this project, and putting the course knowledge into practice gave me an outlook of how making something like we did could look like in a real working environment. I realised how much brainstorming and working together enables me to dive deeper into not only the project work but makes me want to understand the concepts from the course on a deeper level to be able to improve what we were doing together.
