Steve Williams Sure, I guess the, the sort of first challenge in many ways is, is to make sure that, you know, we don't get overrun by the hype. So a lot of my business colleagues will, you know, they'll have a chat with somebody who's a robots of the future, and all the rest of it, and they all sort of come in and think that, and they'll talk to the vendors, and obviously, the vendors will tell them a good story. And they'll often think they've got a silver bullet. And that's obviously not the case. You know, sometimes they feel that they won't have to worry about things anymore. It'll just happen. But of course, they still need to be responsible. And they still need, they do need to help us particularly during the development and testify ease. Because some, particularly some of the processes can be very difficult to get good test data for. And we actually need the business people to generate that data. So I think we have had some challenges where it's not been realized, you know, and I think some of that is, you know, collectively our responsibility, because we were relatively new to it. But what we have learned is that, you know, yeah, we do have to work together and make sure that we have the components that we need in order to make the thing successful. Another thing that we kind of learned was that I mean, there's a couple of ways of kind of running the robots. One is to effectively say to the business team, data robot, you run it, or another way as a sort of more centralized model, where, if for want of a better phrase, you kind of got expert robot users who can do that. And we've transitioned from the former to the latter. I think we started with the view that because the business guys know the process, when they hit a problem, they can deal with it. But actually, what really happens is you train the robot to do the process, so the robot doesn't need any help with the process, it knows what to do. And it knows the situation, if it doesn't know, it'll raise an exception, and it will get passed over to the business team. And what was happening is that the problems that you do here are more kind of infrastructure type problems, you know, there's been a, I noticed a service, there's been some patching on a server and when it when it comes up, it doesn't start properly, or, you know, whatever it might be. And so I think we have moved to that model of a more centralized control room, if you want to use that phrase. And we found that that works, that works much better. So that was it, that was a good learning, we did have a, I would say, the other thing is probably more to do with how, again, how we first started, we kind of probably didn't have as an experienced team as we as we should have done. And so I think like, like anything, it's always good to have good experts involved, we've got that now. And the difference is, is huge. You know, from my perspective, personally, I have nothing to worry about, the guys are great, and they get on with it. Whereas previously, maybe I was getting a little bit too involved in what was happening. And I guess two other things that are worth just bearing in mind is changes in the systems that the robots working with, can often trip you up, might be as simple as the movement of a field on a screen or the jury to an upgrade. And then the robot suddenly doesn't know what to do. What's been interesting there is we again, we were sort of a bit worried about, okay, every time there's an upgrade, we need to do a lot of testing with the new version of software. But we thought we find that in reality, probably 90-95% of the time, there's no impact. And so all of that testing is a bit of a waste of time. So the approach we're actually taking now is not to do the testing and in effect, to let it fall over in production, but to be ready and fix it, because again, we find that usually it's a fairly minor change, maybe a position or a slightly different order of a screen or something. And they can be fixed within a day or two. So I think overall, that's a more effective way to do that. And obviously, I think that's, that's the sort of thing that will depend a little bit on your individual situation, you know, our systems are relatively old, so they don't change very much from that point of view, if you've got newer systems that change more often, you might want to take a different approach. And the last thing I was just going to touch on, not really a problem. But we were originally kind of running the robots manually. So somebody would have to log on and kick the robot off. But we've now use an automated log on feature that comes with the RPA software. And we're able to effectively control when the robots run and what they do if they fall over and all of that, all of that kind of stuff. And that obviously means that we can be much more effective with the robots, because now we can really look at 24/7 running. And that's kind of where we're going to probably, you know, be looking in the future to maximize the value that we get out of the licenses.