Samad, welcome. It's a pleasure to have you with us here today. Thank you. And let's get going then and start with something that I think there's a little bit of a loaded question maybe, but you know, when you start talking about AI introducing this technology in a very traditional industry, when we're talking about shipping and transportation and so on and so forth, that must not have been an easy ride or at least the start of a conversation. Can you put a few words on how that started and how that process went? Yeah. I mean, the idea was actually a deliberate experiment. So you're absolutely right about the traditional nature of the business. And suddenly when you start to think about very, very traditional legacy processes, you think, oh, there are too many resistance factors in this. But the objective around it was, so let's try and take a very traditional legacy process. We have many of them. So let's try and not create preconditions for processes which we should select, which are maybe further along the line into the digitalization. And then let's try the best of what AI as in sort of decision support and automation can offer and see how we can disrupt and sort of take a maybe a broader leap. So obviously objectives around the process matter, i.e. progress matters. But also there's an there was an interesting element of learning as well. How far can you push it? Was then there a specific objective before you get going? Like was there a target for it to achieve that? Absolutely. I mean, you talked a little bit about some of the challenges we talked about. We had significant volumes of claims processes that we needed to handle. Payouts not necessarily in control under increasing significantly. Lots of in process claims processes that, you know, the backlog sort of grows. So naturally the process in its sort of traditional sense, in its legacy sense had a lot of clear things, KPIs that you could do. And then you could maybe look at a very long term stretch around it. But you could also maybe think about some of the immediate things that could happen that would be early proof of whether this is working or not. So yeah, I think that was important. But then let's focus first. I'm really curious to hear about a bit of the impact that you got out of it. And then maybe we can focus on the how right after. So if we start with that. Yeah, the the obvious part of this is you can look at rejections. So rejections, we reduce rejections by about 50 percent in the in the regions we've rolled it out. Payout. So we talked about payouts increasing by 18 percent. Now payouts are more in line with inflation and what the damage valuation is like. So consistency, transparency, what's in the backlog, the backlog is reduced significantly. That's in the previous world or in the traditional world, we weren't maybe looking at it from a overall perspective, what how big or long the backlog is. And I think, well, albeit anecdotally, but the customers who've been exposed to this new process suddenly realize, oh, my claim was processed very quickly. Oh, this is good. It was a pleasant, positive surprise. So we're getting qualitative, subjective feedback as well. So which is obviously useful. And in our business, if the customer says they're happy and they're not that easily impressed, that's a good thing. OK, well, that sounds like a great solution. But how do you basically what is that you did differently than it was before? What was the actual solution? You know, what did you do with this beautiful process? Yeah, I mean, as I said, a traditional process, there is an element of estimation or estimating what the damage is. And then there's an element of automation. There's an element of sort of decision support and automation of the process. So you're you obviously for that also, we had quite a lot of regional variances. So documentation of processes in a very traditional industry are not necessarily there. In some cases, there is no actual digital footprint of the process either. So the idea was to use AI to maybe look at sort of claim value estimations and then use automation tools to try and focus on getting the chain working and making sure that there is a macro view of the process and dashboards to follow up how we are doing across the board. Didn't you didn't you get any resistance locally for many of them when you look at this? Very much so. I mean, you know, legacy legacy processes have deep roots. Yeah. So it's it's I think it's, you know, in some cases, no documentation, no digital footprint either, no data to to assess and look at. So, yeah, there was a lot of resistance. And in fact, I think one of the interesting things was that maybe with the power of the tech that we have today, AI and automation, maybe in the sort of attacking the problem, we spend more time in actually addressing that, which I think is the the big nugget for us in terms of learning as well. Can you can you try to put a few more words? I was gonna ask exactly the same thing. No, no, it's okay. So curious about how you orchestrate that change when it's like full of so many variables and so many different sets of legacy processes. I think in this day and age, I think even people who are not so exposed or not so digitally savvy kind of see AI as this very powerful thing. So the the question around proving technology as such, which used to be the old paradigm, oh, come and prove your technology works and then we'll see. People have this sort of understanding that this thing is powerful. So then and and then we're able to sort of shorten the cycles in terms of what solution we put out there. Then a lot of the focus is building trust. And I know a lot of your earlier guests talk about trust, but I think that's the whole game in terms of implementing these solutions. You're spending a lot of time trying to build trust. And maybe we there that there's a lot of learning and a lot of excitement. But I think the barriers of just or the days of just proving whether technology works are we are a bit beyond that, I think. Okay. And okay. But then then there is one thing here, right? Because now technology changes. We've just been seeing, you know, the velocity of how that happens. You chose a system, you chose a variety of systems, probably you have your architecture, you have a lot of technical solutions out there, and you're basically deploying this at scale. How do you ensure that that's also sustainable in your six months time or nine months time or whatever it is that you're making the right technology choices? That's what I'm trying to say. Yeah, and I think this is where also the nature of the technology is very interesting, the learning element of technology. So when we say, well, we've chosen a system, well, actually, the system needs to learn the assumptions, the model needs to learn, the process needs to learn the data context. So in some cases, we don't even have a data context or process context. So you're kind of building process context, data context, and you're also maybe improving your model over time. It's not a reductionist. We start with this system and just implement it, roll it out. I think there is that there is this there's this beauty of learning in the process. And we should extend that when we talk about, well, machine learning or tech, you know, AI developing the process context, the data context and the sort of organizations kind of learning across the path as well. So emphasis on that is interesting. Okay, if I can just grab that because there's a very interesting, I think, question just popping popping up in the chat. So when when you're integrating AI at scale and across many regions and many different, let's call it process maturity levels, for lack of a better word. The question here is how are you sort of constructively managing the risk of layoffs by both upskilling? Do you make mobility choices internally for people to swap or are you sort of maintaining the status quo for the people you have working in the process? How does that work? Yeah, I mean, upskilling is a big question. I mean, for us, the reality is that we are going to physically move people and goods. People are are the game is obviously operational efficiency. And in that, how do we measure efficiency? What do we do in that? I think there are in our in our example, there are people who've never even seen a iPad or a dashboard in their physical daily work. They don't you know, they're not seeing sort of AI photos of damaged trailers or anything. And suddenly you've got dashboards and so it's a it's a big leap. But we also think that even if we're very traditional or industry, a lot of people are very exposed to in their personal lives to these to these things. And I think that's important when it comes to the process, the the the belief that we need to upskill people. Yes, in operations, maybe our focus is not like maybe the traditional R&D manufacturing companies or traditional software houses. But I think the necessity to upskill is as relevant as important. It is also a question of survival, also a question of and I think just a personal reflection on use of tools internally at the company like Stenaline. Every time people go away on holiday and come back, suddenly the use of internal, you know, these tools goes up. And the reason is that people are actually externally influenced. So there is also pressure externally to learn. And so our job is to just encourage that and obviously give people access to tools to learn and and play, but also maybe make it concrete for how this can work for a very operational company like Stenaline. Is there a specific, you know, we we talk a lot about the learning organization. Is there a specific learning program that you guys are focusing on or is it kind of a learn on the job, learn as you go? Do you have a, you know, a structured approach to that? We are traditionally very, very good at experimenting, but we experiment fast and sort of like because we were not a manufacturing company, so we don't have a long, long R&D cycle. But we are very good at experimenting. And I think we're maybe maybe leaning a bit on that. I think sort of like in this case, you look at sort of the whole development cycle and you look at AI and learning systems, learning processes, learning the methodology of how you develop systems and how you interact with systems, how you roll them out is also changing quite a bit from thinking about standardization at the start and locking that in from a reductionist perspective and trying to roll it out is not so good. When you learn, you build trust, you tweak your algorithm, make sure the regional nuances are taken care of. So I think a lot of that process is almost like it's infusing into what we need to do. You just need to be conscious of it. And I think traditionally, we should sort of also maybe rely on and back on what we are good at. We are good at maybe quite a lot of experiments and just trying to move forward. And maybe that's useful. You just have to be aware that sort of as in Ethan's challenge, everything's up for review and you need to open your mind. So I think that's important just to remind yourself. But I just want to just would like to grab that a little bit. There's another question that came up in the chat just coming up on how have you learned and like all these things that you are actually setting out on a giant experiment kind of. Then there's the question here is, have you made any changes to the way you were organized, like roles and responsibility or even line leadership? Has anything on the sort of organizational structural layers changed as a result? Yeah. So the fundamental thing is, you know, the for an operational company like us, we are an asset heavy operational company. So our are we have long term multi decade assets like boats and vessels and and ports. And then we have the here and now the operation. We need to sail the vessel in a safe way. So there's this big dichotomy of of but I think because we don't have that engineering or, you know, background, maybe perhaps people are not so data driven or or tech savvy. So there is that risk that all people are we need to sort of have some sort of separate innovation engine to drive that. But I think in this day and age, what we need to do is just make sure that the tech teams. And I always like to say the the cycle of business development is equivalent to digital development is equal to a development. So business development in our business is actually all about a development. So it's almost putting organizationally putting all those teams much closer to the business. So the claims team needs to know how are we going to learn if the IT department is separately running on a different schedule and and we are not developing the process or data contact. So proximity is important. So I just, you know, in that one as well. And it's only a 30 second thing, but but there is something around the learning organization because everybody's fighting for talent. Right. And then Ethan said, listen, we don't have a lack of AI talent. You just have a lack of people who actually understand that they can do it themselves and you don't need 100,000 data engineers for every single company. What is your take on that? I agree. I think if you if you do an executive, I always say to our executives, all our leaders, if someone gave you a piece of code today, you can do something with it. Actually, you couldn't do it maybe two, three years ago, but now you can do it even if you've never coded. So there is a lot of power in that. So you've got the tools are out there. I think. I think. Yes. Then let's go. Interesting. Yeah, I was going to say, because the last thing we just want to do is touch back on this poll. And there are two that are so close to each other. One is the data readiness and quality. And then funnily enough, actually, this this relates because it's the skills and roles to run AI at scale. Those are the two top scores at more than 50 percent combined that people in the audience are saying this is what's tricky for them. What's your perspective on the data readiness? I know that's great example for us. Some of these processes, there is no digital footprint. There's there was no not even a digital footprint on the. So, I mean, if we I think that we've kind of also proven to ourselves that we can apply some of these things, too. But I think the skill is to actually, as you say, yes, did garbage in and garbage out is true. But in this case where we don't have a data context, we can actually make sure that the learning process continues. So we build the data context that will help us in the future. Sorry, what was the other? The skills. Yeah. Yeah. I mean, brave new world, you've got to approach it with with sort of like that learning curiosity. Some of it, as I said, maybe you have to dig deep into your innovation culture in your company and maybe build on that. Not sort of it's not necessarily a question of abandoning. I think a lot of the skills for a really old shipping company like ours, our curiosity, our ability or the our our ability to take on risk is something we people can bank on. But it's about how much you learn and how curious you are about what's out there. So and finally, maybe just one remark. What have you learned in this process that you didn't know before that you said, OK, I really wish I would have known that before I embarked that? I think the the biggest learning is to not be set about standardization and the process now and the tools are so powerful that it allows you to maybe give time to those nuances. And it gives you time to build trust around systems, how you work with systems, how systems spit out decisions and how you do them. I think you have the time and space to actually use that. I think we need to think about that and see how do we build trust with these machine learning models and how do we let it thrive and let it maybe go past our own judgment. That's the interesting learning part. Fantastic. Thank you very much. Thank you so much. Thank you so much. Thank you.