PegaWorld iNspire 2024: Lloyds Banking Group: Transforming & Improving Customer & Colleague Experience with Pega Customer Service

In this session we will explore Lloyds Banking Group's quest to modernize and simplify their technology estate, across Consumer Lending, Consumer Relationships, Insurance, Pensions, and Investments creating efficient and straightforward banking solutions, enabling customers to easily manage their interactions with LBG through their channel of choice and empowering their colleagues to provide excellent customer service.

Transcript:

- Well, folks, I'm glad you've made the right choice. This is absolutely the right place to be after lunch, as Don said in his keynote, this promises to be a phenomenal session. My name's Simon Thorpe, I lead our product marketing for customer service and our sales automation business. And I'm thrilled to be joined by Luke Rimmer and Olly Male from the Lloyds Banking Group. As Don said, one of our largest and oldest banking institutions in the UK. And the guys have been doing some extraordinary things, so we're so grateful for them joining us and giving us the chance to hear a little bit more about the transformation journey they've been on, how they've been improving both customer and colleague experiences using the power of Pega customer service. So it promises to be a really good session. We will have time at the end for you to grill the guys with questions, and I'm gonna ask them a few along the way as well, just to keep them on the toes. We ask you to use the microphones, I'm sure you're familiar with this now, day two, but if you can come up, introduce yourselves and ask the question. When we get to that point we're filming. So if anyone's a little camera-shy and doesn't feel like they wanna be on camera, that's perfectly fine, but just keep that up your sleeve, if you will. So we're gonna do something a little different to introduce the guys. We've had a bit of fun with this. Any Europeans in the house? We've got a few. We checked this the other day to see whether the game Top Trumps was something that translated around the world and apparently it doesn't. The Top Trumps is very much an institution of a game that's played in the UK. And so the guys have created their own Top Trumps cards to tell you a little bit more about themselves. So without further ado, let's introduce Luke and Olly and give them a round of applause.

- Thank you, Simon. So I am Luke Rimmer. I have been working for Lloyds Banking Group for 13, nearly 14 years now, 10 of those years working with Pega. I originally started, joined as sort of a release manager. I did some license management and now my job title is shaping lead. Now, no one knows what a shaping lead is. It would appear that has been the first thing that most people have said to me. So I kind of manage the engagements that come into our platform and estimate those out. And as we're in Vegas, my favorite casino game is poker.

- Thanks Luke. My name is Olly Male. I'm a engineering lead within our IP&I lab. IP&I stands for insurance, pensions and investments. So essentially myself and my team look after all the Pega engineering for insurance. I've been with the bank for 19 years now. I was working in the support team at the start. And my boss came up to me and said, oh, there's this Pega project, do you wanna go onto it? And yeah, 14 years later here I'm talking to you. My favorite casino game is Blackjack, but I actually haven't had a chance to play it yet, so, yeah, need to fix that.

- [Simon] What about golf? Have you both keen golfers? Any hitting the golfer at all? What's you been here?

- So we haven't been on the golf. We did play top golf on Sunday, but I asked for this one to go in 'cause this is the only category where I can actually beat Olly. So that's why I asked this category. But after top golf, there's no one I'm giving you 10 shots going.

- No, there you go.

- When we was doing this, I kind of thought, oh, you might get some sleep having kids under three, but Vegas is probably not the best place to come from that, is it?

- It's not really happened yet.

- No, no.

- So I'm conscious that not everyone knows who Lloyds Banking Group are. So just a brief issue of who we are. So we are a financial services group based in the UK with over 325 years of history. So yeah, we've been around sort of 70 years before the declaration of independence was signed. Just give some idea of how long we've been about. We are the UK's largest mortgage lender. We have over 27 million customers, 21.5 million of those customers are digital. We spread across 16 brands, which Olly will talk about in a second. And we're made up of 66,000 colleagues, and luckily a few guys, the best two are on stage today. Well, sorry, I shouldn't have said that, my boss. Our motto if you like is, helping Britain prosper. Why that's quite important sort of differentiates us from the other banks in the UK so that we are completely UK focused. The vast majority of our work is based in the UK and therefore we have a significant impact on the sort of the economy and the overall prosperity of Britain.

- As Luke referenced, these are our 16 brands. We've put a little Pega logo alongside the ones where we've got Pega operating within those brands. As we've also said, we are the UK's largest mortgage lender. So we do that mainly through our main retail banks, Lloyds, Halifax, and Bank of Scotland. But equally we've got AMC company, which stands for Agricultural Mortgage Company, which helps farmers get land and buy buildings and things. So real sort of quite wide variety of our brands and all of those 16 brands have a common goal of wanting to help Britain prosper.

- [Simon] Nice, nice.

- [Olly] Thanks. Bit of marketing. So we thought we'd just explained to you a little bit about how the bank is structured. So we've recently undergone a bit of a reorganization and we are now an agile only organization doing agile at scale. We have five directorates, which we've listed out along the top there. And each of those directorates has a platform, has many platforms beneath them, and all of those platforms have a product focus, so really wanting to enhance that product to make it better for our customers and equally our colleagues as well. We've also got a number of enterprise platforms, which is some of the sort of, I suppose the guts of how the bank operates, so how our risk functions and finance and various other things. Myself and Luke work for a team called Core Platforms Pega. We are part of the chief technology office, and Luke's gonna talk you through a little bit about our structure.

- Yep, that's right. So Core Platforms Pega as Olly said, is within CTO with the centralized capability for all Pega engineering. We set ourselves up with four delivery labs there and we've aligned those delivery labs to the different business units that Olly mentioned within those delivery labs. We have feature teams that do the engineering delivery of Pega applications. Across the top there, we have sort of our front door, if you like, the shaping and center of excellence, so that shaping word again, that's me and my team. So any inbound demand comes through our team. We propose a potential Pega solutions based on the recommendations of the center of excellence and architecture to make sure we are following the technology roadmap. We propose a couple of potential solutions, shake them up and give the cost and effort to deliver those. And then at the Boston AEC, we have our sort of our shared service layer. These guys do all the things through release and environment and configuration management. We have our evergreen team there that's constantly keeping our platform up-to-date and our life support function for when our applications are in BIU.

- So before we get into the customer service element of this, we thought we'd just talk you through a little bit about how our applications are structured. So before I go into too much detail, so before we moved across to Pega Cloud, we were an on-premise organization. So we had all of our Pega apps, essentially in one infrastructure, so I think at our peak we had about 45 applications on a single infrastructure, which as you can imagine trying to organize a change, a server reboot just turned into a bit of a logistical nightmare. And some of the codes retrofitting across all the different applications just became very complex. So when we moved to Pega Cloud, we knew we wanted to structure it a little bit differently. So we structured our VPCs in line with our directorates that we spoke about on the last slide. So we've got a number of applications across all of our VPCs slight difference areas. We've got our CLM application, which is across a number of directorates, but that's just for reuse mainly. At the Boston now we've got what we've called our Lloyds Banking Group marketplace. That's basically our internal group components. So for example, our customer system, this has about 50 APIs that's done centrally. And when you want to use those APIs, you request a deployment out. We deploy those components down and then you can make reuse of that, which has offered us a huge benefit. Being all Pega Cloud, we're keeping this evergreen, so that means essentially is up to date as possible. And we've put some SATs along there to say that we've done 33 platform updates since 2022, which is just a world away from our on-premise setup. Previously, I think we did two platform updates while we were on-premise and they took a very, very long time. And yeah, just a complete departure.

- Olly I said I was gonna jump in with the occasional question.

- [Olly] Yeah, yeah.

- [Simon] To keep you on your toes to make things interesting.

- [Olly] Yeah.

- For the uninitiated, tell us what a VPC is and also it looks a lot of cloud infrastructure here, a lot of different clouds. Why have you set up like this?

- Yeah, no, good question. So VPC is virtual private cloud. So it essentially means that it's a dedicated infrastructure. So I'm working quite a lot in the Scottish Widows, one at the moment. So I'll pick VPC 4, so that essentially means that when we want to do a platform update, we want to do a deployment, we just go out to that business area and say, we need to get some testers in to help with a release or we need to have a bit of downtime. It just means that we don't have to go out to every business area all the time.

- Got it. Thank you.

- Luke, anything I've missed on that one?

- One thing I was gonna say, I guess is an idea of the scale of Pega in Lloyds Banking Group, we actually have 45 applications. Not all of them are listed there for ease of viewing, but that's the size of our estates. And we have Pega being used by over 35,000 people within the bank. So it just gives you an idea of how large it is. And we had to submit these slides a month ago and they're already gonna be out to date 'cause we do that's right. I'm sure one of these VPCs has been upgraded since then.

- [Simon] Yeah.

- Okay, so customer service in LBG as Olly was saying, three of our instances use customer service. And don't forget, we're engineers not marketers. We don't come up with the most wonderful branding. VPC 4, VPC 5, VPC 8, but yeah, so VPC 4 and VPC 8, both using customer service for insurance. Olly will talk about those in a bit more detail. And VPC 5 is our consumer relationship instance, which is using customer service for financial services.

- Okay, so we're just gonna drill into VPC 4 a little bit. So this is used by our Scottish Widows brand. It's a really heavily used application. So we've got about four and a half thousand of our colleagues that use this application on a daily basis, around about 11 million requests come into this system annually. This is done through five different channels across the system. So a number of online channels, posts, telephony, and email is quite a common one as well. We've got 45 journeys to migrate from this application. All those journeys are not there at the moment. We're underway. We've got our first journey being migrated next month, which is our bereavements journey. And the reason for that, 'cause we've been building this for quite a while, is that we took the decision to essentially start building some core components. So the fundamentals of how our business operates. So things like how you pen a case, how you do quality checking, how you do, I can't think of other things now, but you know, all those sort of common things that you really need to operate as a business. We built them out, they're now deployed, they're now ready. And as we build our customer journeys, you can then pick those common components through and have them into the customer journey. As we've been building our bereavements journey, we've been building around about a third of our code in a reusability layer. So we've got our sort of a reusability layer just slightly above the implementation layer. So that means that as we go through our 45 journeys, we're gonna be reusing that code. So about a third reuse within that is quite good. So we should really see some benefit as we start to roll out more journeys later this year and early next year.

- It feels like I'm picking on you now, Olly, but I'm gonna ask you another question because it's come up a few times over the course of this PegaWorld. Why did you choose to use the customer service application over the traditional platform?

- Yeah, so this application started life as a 6.1 application. So we started the build for that in, I wanna say 2009, maybe 2010. And we essentially, I don't think we necessarily realized it at the start, but we ended up building our own customer service framework. So we built our own interaction case and then used it to feed off to service cases all the time. And as we've started our move out to Pega Cloud, we wanted to keep things outta the box. So we wanted to use strategic applications rather than building a lot of custom code. So as we looked at our application structure of our previous application, we sort of realized that customer service was a really great fit and it obviously introduces the data model where we can get the 360 view of the customers come through, and it just offered us a lot of benefit, so it seemed sensible that we didn't start building a really complex application when we could use the outta the box.

- Very good.

- Right.

- VPC 5.

- VPC 5, yes. So when we first started building Pega applications in the bank at scale sort of 2008, 2009, 2010 time period, we effectively were building a new application for every process or even sub-process that we had. We got ourselves into a position where in sort of the retail operation space, customer service, we had about 18 different applications and they varied from something as simple as change of details or self scanning branch where you're scanning a document branch, ends up in the back office somewhere all the way through to our bereavement journey. Obviously a very important journey, very complex, long running, multi-actor and a significant moment of truth for our customers. So that gives you an idea of sort of breadth that we had there. But what that meant, it was very much a product centric estate, so whether you came in via different products, you'd have a slightly different experience. We had these 18 different applications, lots of applications switching for our colleagues. It was quite difficult to have cross skilled teams and it wasn't as easy to get a sort of single view of the MRI reporting that comes out of that, so fast forward a couple of years and now into 2024, we've been able to put all of those 18 applications into one single consumer relationship, customer service application. The channels of that services is branch, our call centers, post and online. And what this now means is it's now very much a customer-centric. So similarly with insurance, we have the customer in context with 360 degree view pulling in details of them from different APIs, but it's now one single application. So we have that consistent user experience for both colleagues and for customers and we're able to make most of that with cross skill teams.

- Yeah, I think Allan would be thrilled to hear that. I mean he couldn't have written the script better really. You've totally embraced the center out philosophy, right? And I was interested just hearing you talk this through. Lloyds is a big complex bank, lots of moving parts, lots of brands. How have you coped with the challenges around dealing with journey duplication and creating consistency across those channels, across those different brands? I imagine that's a headache.

- Yeah and we knew we had a problem with sort of 18 applications, but the one that sort of jumps out is when we were doing discovery phase for this piece of work, we actually had the change of address process in nine of those applications. So it didn't matter sort of what product you have had, what type of customer you were, which channel you went through, you probably got a different experience of change address, all did the same thing. It proliferated out to our systems of record, but clearly we've been able to take the opportunity now that it's much more customer-centric, that we have a single change of address or change of details journey. So I think that's probably a pretty good example.

- Yeah, Absolutely.

- Okay, so moving on to VPC 8. So this is quite a new application that we delivered back in Q4, I think last year. So this is for our general insurance business and is specifically focused on our home insurance claims. So previously, before Pega, this was a very manual process. So we had basically all of our colleagues doing manual claims processing and manual decisioning on claims. So we've made the decision to digitize our architecture, put Pega at the heart of that, managing the journey for both digital and colleague claims. And we've got about 300 claims colleagues that are using this application. And we're gonna have about 150,000 claims going through this on an annual basis. We've got four of our brands that are currently putting cases through this. And whilst we're not there at the moment, we've got claims that we would like to have 65% of our claims registered digitally. We're already making good progress in that regard. And this is our first application that's using process AI. So what we're doing with process AI is we're using, this is a decision engine, so instead of having colleagues making these decisions for every single claim that comes in, we're gonna use process AI to start automating some of those decision and giving colleagues a view of what the likely outcome of this claim is and helping them sort of make the best decision for both the bank and our customers.

- Olly, can I ask, I'm sure we're all familiar with Karim's keynote yesterday, would anyone remember what he said the future of digital transformation is?

- Gen AI.

- Gen AI, gen AI, gen AI, gen AI, you can't move from discussions about gen AI at the moment. How is the bank thinking about the proliferation of AI and different use cases and how that might fold out into the future?

- Yeah, we're having a lot of conversations about it, but I'll probably pass this one over to Luke, is in his shaping capacity to answer this one.

- [Simon] Nice. Yeah, no, you're right. So...

- Yeah, obviously my role with the engagements that come in AI is a massive buzzword. Lots of people want to talk about it and want to take advantage of the capabilities and Pega clearly has some of those. We already use sort of AI machine learning capabilities across the group from Pega's perspective. We use email bot in a couple of our processes, which obviously has the machine learning capability. Olly spoke about process AI in general insurance. A couple of the engagements that I've got running at the minute, we have one in sort of a transaction dispute space, so similar sort of use case I think really where a customer disputes a transaction that they're seeing showing up on their account based on the sort of the input that we get from that process AI will spit out and say, we are X amount confident this is something that we would pay out on, it's a genuine dispute. And then the colleague can make an informed decision off the back of that. We also think that we probably could do with some support as a lot of the organization can do with sort of economic crime prevention as well and using sort of learning from whether it's duplication or learning from themes and trends. Again, giving that colleague that's picking up the piece of work a holistic view and more information, they can make a better decision saying, you know, we think this is most a false positive, continue the work you're doing to ensure that or now this is something that needs to be escalated more quickly 'cause it's more pressing. So I think that at the moment, but like you say, I'm sure after today and this trip, we are gonna have a lot of people that are talking about gen AI to us. So that with next one that I need to brush up on, I think probably. Okay, and then yeah, in summary we thought it'd probably be quite useful to give some of our top tips and lessons that we've learned over this journey for the last couple of years. So I think the big one, whilst it's not necessarily completely strict to customer service, but in general moving to evergreen is a mindset shift. I think a lot of people, and certainly we did at the start was thinking this is a technology shift, but really we found its mindset and that's not just from end users in the business, that's also from an engineering perspective. I think, you know, we didn't do many upgrades in the past, so engineers weren't overly keen to build the capacity in their backlogs to say, okay, that upgrade is coming along, we're gonna be moving onto a later version through the route live because they were saying, well we don't need any of those features. But the reality is, you know, get yourself moving forward, build that into capacity because you may need that and if you do need something that's a couple of updates down the line, you know, it's a bigger work to do a minor release rather than a patch. So, yeah, mindset shift I think is a good big one for moving through guilds.

- Yeah, we've also found the sharing back best practice through our guild. So we have myself and my team, we have a guild on a weekly basis where we get all of the LSAs and dev leads together and talk through some of the complex problems that we have. So there's not always, you know, like an an easy path to fix a problem, but getting everyone together and discussing it, you fix things so much quicker. So we've found that really works well. We also have a platform wide guild, so sits across all of our delivery labs and that's sort of turned into a bit of a, I wanna use the phrase governance, but it's almost like a gateway to actually go in live, so you take your design in there, all the LSAs from across the labs will review it and just make sure that you're building things correctly and with a view to what Luke was just talking about from an evergreen perspective is just your building so that you can enable future upgrades and future releases without breaking things.

- Reusability, we both mentioned that a few times today, but it really is a game changer for us. So the importance of the reusability layer, we're calling it the LBG marketplace, but it's effectively where our common components are. So I think Olly gave some stats around how many are in his application are being built in that reusable layer, but we are now able to build a component that can be used across all of our eight VPCs by any application. So the advantage of us being that centralized capability and through the guild and things like that is that we have that common knowledge and understanding of what the components are in that layer and how we can reuse them to accelerate future delivery.

- On the final one we have is obviously out to the box is gonna be best practice, is what we've all heard over the last couple of days. It's what we try to adhere to, but it's okay to customize your application, your business is gonna have unique needs. Every business does as long as you build it correctly. So going back through the guild process and having your LSAs really come up with a design that's gonna work well, we've got some really, really good results with having some safe customization and we're still keeping the applications evergreen and upgrading them frequently. So, yeah, it's okay to do it occasionally.

- Fantastic, guys, I can't thank you enough for giving up your time and coming over to share the story. I'm sure we're gonna have some questions in the audience, but thank you. Let's give Luke and Olly a round of applause. So now's the grilling. Now's the grilling. I know no one likes to be first with these things, but does anyone want to stand up and ask a question? Yes sir. Do you want to come round to the microphones? Please. And if you could introduce yourself and fire away please.

- [Jose] The microphone is a bit tall. Nice to meet you all. And Luke, I'm Jose Camerano, group product manager in booking.com. I have a question on VPC 4.

- Okay,

- Yes.

- [Jose] I wanted to understand if you can manage 100% of the volume of the inbounds with the 45 customer journey that you have, and if not, how can you manage what is not covered by the journeys we use like dynamic action, action templates or something else? Thank you.

- So in our previous Pega 7 application we had pretty much most of the stuff going through the proper customer journeys, but I think it's probably fair to say over the years those customer journeys weren't necessarily reflecting what colleagues were doing on a day-to-day basis. They became a little bit outta date and so we had a bit of a catchall case type, which was a administration case type, which the business had a bit of control over. So we have a lot of delegated rules that they can tweak that case type. So over the years, probably a little bit too much work has gone through that case types, as you say, sort of catch the stuff that didn't go through it. So as we've been rebuilding onto our new Pega Cloud application, we've been really trying to focus on actually not having that case type as a catchall and building them properly, making sure they represent what colleagues do on a day-to-day basis and what our customers have to do. So yeah, I'd say we probably had it on Pega 7, we're intending not to have it on Pega 8, but yeah, we'll see where we go, we're not intending to do it.

- [Jose] Okay, thank you very much. Will be great to connect to more.

- Yeah, sure. Yeah, badly.

- [Jose] Thank you.

- No trouble.

- I love the fact that you people are sat there writing notes. This is wonderful. This is wonderful. Anyone else? Would you like to come and ask a question? Yes sir.

- [Bell] Good afternoon. Great job you guys. My name is Gene Bell, I'm with Northwestern Mutual, and we're kind of new on our journey with Pega.

- Okay.

- And I saw something on one of your slides for VPC 5, so I was just curious, what is an ISA? And then also you talked about the addresses, the address change, 'cause I'm going through that same thing too, find out that comes up in multiple different, what we call service interactions and we try to do it the same, but the experience is different across each. So two questions there, VPC 5, what is an ISA? And the second is how you dealt with the address change.

- So, an ISA is an individual savings account, so it's a tax free, tax efficient way of saving. So that particular process is the ISA transfer. So sort of the legislation in UK may be true elsewhere as well is that you can transfer an ISA from one company to another and there's sort of time limits in which you need to do that. So Pega is managing that process. So whether that's transfer in or transfer out. Someone moving their ISA into one of Lloyds accounts or moving their Lloyds ISA into a different organization's account. And change of address and change details. Yeah, so that was one of our first processes that we put on customers. So it's because as I was saying, it was one that was sort of proliferated across a lot of our applications and we're trying to open that up to different channels, but effectively we've just simplified that that journey as possibly it is a pretty straightforward sort of process, but there're different ways that a customer might want to interact and different sort of documentation that needs to be provided to prove that. So, yeah, we are managing that right from the front end all the way through. The back office process needs to be done to make sure our systems of record are updated and several steps in there are automated and some of those get handed off to a human to complete work as well.

- Thank you. Questions. Anyone else? Yes, madam.

- [Jennifer] Hi, so I'm Jennifer Gittens from Northwestern Mutual and I was surprised when I saw right customization is okay, 'cause we've right, as you mentioned, we're in the beginning of our Pega journey and so we're very much in the world of like customization. Is that, okay, right?

- Yeah.

- [Jennifer] To build that muscle on business. So I'm wondering like how do you work, especially thinking back to like the earlier part of your Pega journey, how do you work with the business to like engage them in moving away from that thought of like, every process that I have is special and unique.

- Yeah.

- [Jennifer] And thinking in a more kinda out of the box way.

- Yeah, I might say that one. So, is quite a difficult thing to sell to the business some of the time. And I think the reason that we said that customization is okay is, 'cause there are some sort kind of deal breaker things for our business where they're just so in our application recently, our colleagues quite frequently will pen something. So a case comes in, they haven't got all the documentation from the customer and they will pen that work item, it'll go into a work basket and it will wait until it comes back in, and the way that the out the box did it wasn't exactly as they wanted it to work and it didn't quite match MI metrics that they're measured on. So we've had to customize that. So we've spent a lot of time in our guild having our LSAs working through a design that's gonna work on a, you know, not just now but in five years time when we've got millions of cases in the system. So I think it's probably really important that you've got your LSAs and your LBAs really understanding the design and I suppose focusing on the things that are really key to the business. There are some things that can get away with. I suppose try and follow the 80-20 rule where you've, you know, sort of try and do 80% out of the box and then customize where it's really necessary.

- [Jennifer] Thank you.

- I think the important point there is around the future sort of upgrades, you don't want it to break every time you do an upgrade and if you're not careful with your customization, you do that. So there's all he is saying, doing that safe way prevents that.

- [Jennifer] Thank you.

- Another question. Anyone else? I'm gonna ask a question guys. We've talked a lot about blueprint whilst we're in the PegaWorld.

- Yeah.

- And the value blueprint holds in pulling together collaboration between business and IT teams. And I wonder, given the transformation journey you've been on, whether you can share any best practice examples of tying those two groups together and what your own personal experiences have been like of working with the business. I'm thinking, you know, the people in the contact center, you know, are they part of your development loops? How do you specifically in teams interact with those groups and what's been the outcome for those colleagues as you've been through that journey?

- I can take some of that.

- Yeah, yes.

- So I think the way we set ourselves up now as an agile only organization, I mean within core platforms we've been doing agile for many years now, but I think we're sort of embracing a single methodology of agile within Lloyd Bank Group. So there are some changes that we're looking at, but it's effectively setting our teams up with business and technology sat next to each other, the sort of standard principles that you'd expect and having those show and tells and short feedback loops so we can constantly be showing the end users getting their feedback in their input to make sure that we are delivering exactly what it is that they want and what that means. It will look like, and actually now that I've seen it maybe we need to change it ever slightly. So I think having that constant regular feedback is important. You know, I don't think we always achieved that as well as we could because I think, you know, the best people that could be a business product owner or representative from the business, the business don't really want to take them outta the business because they're obviously key to their delivery. But I think it's an education thing and a mindset thing that we were going through now to improve on that. And blueprint in particular, I think there's some pretty obvious use cases that we can take and actually I've been thinking about sort of my team, we often get, like I said, we often get engagements from business areas that they know they have a problem with everyday working their business processes, but they don't actually know what their business process is. And you know, just because it's written down the piece of paper, that probably isn't what you're actually doing in reality, so how do we turn a Pega solution to life to them very, very quickly. And I can almost see, you know, understanding what their problem is, what their business, what the customer journey is, tapping that into Blueprint and coming out with, well this is what a potential flow could look like here. So this is what your data model might look like. So I can see that might be how we certainly dip our toe in using Blueprint to start with.

- And one thing we've quite recently started doing actually is trying to use App Studio a lot more in our discovery and refinement phases.

- Okay.

- So, just trying to draw out a very basic look of here's what you asked for and the amount of times we sit down with the business afterwards and here's what you asked for. It's like, ah, I didn't actually mean that. Can you move this around, move this around. And that then saves us a lot of effort going down the line because we're not then building something and then we wait until we get into sort of peer review, sprint review kind of phase where we're then saying, ah, actually no I didn't want that. And then we've wasted a lot of effort. So yeah, just trying to sort of flush out exactly how the screens will look. Rough idea of how the process will look. And I think Blueprint will help that in the future as we start building more of our case types.

- Yeah, I've certainly been an old call center guy. I would've loved to have had something like Blueprint back in the day because if, you know, how I thought a process worked versus what actually happened when one of my agents was on the phone and the different workarounds that created to make their life easier, it was probably polar apart. So I do love that, that bringing together. So just quick cycle around, last question from me. Other than a beer after this, in the relief of finishing your session, what are you looking forward to the most in the future? What's getting you excited about that's, you know, either you've seen here or you may have seen outside PegaWorld that you think is really gonna be interesting for you guys?

- I think excited and terrified is probably with the AI stuff that generated AI. But I think particularly the Socrates that we saw this morning, in the keynote, I think we have them flying around the WhatsApp group this morning, saying, yeah, we could do that, we could do that 'cause we're on a pretty large sort of enablement journey at the minute we-

- Okay.

- We're trying to increase our permanent employees in engineering space. We've just opened up a Lloyds technology center in Hyderabad where permanent employees are based out there that will support our engineering capacity. So they're obviously on a learning journey. You can learn Pega and then you can learn how to do Pega in Lloyds. So it's quite a long journey. Obviously we can't drop our velocity because, heaven forbid, so I think using something like Socrates is a different way of learning. I like the idea of, you know, it's not just information, it's knowledge and-

- Yeah.

- Sort of, you have your own learning journey and you'll get there the way you do it and you don't have to do things in order. You've got those objectives that you're going to achieve over time. So I thought that was really interesting. We've already started having conversations how we might be able to enable that within Lloyds.

- Fantastic. What about you Olly?

- That still your own.

- No, you didn't, actually I was gonna, I think probably some of the Constellation architecture stuff that we've been seeing, I was over in the innovation hub and we're still using UI kit for a lot of our customer service applications 'cause we started them before Constellation was an option. And seeing that there's gonna be some migration paths through to Constellation and just what that's gonna mean for some of our digital journeys in the future. I think it's gonna be quite exciting. So, yeah, I'm gonna be over at the innovation hub this afternoon, looking at that, I think.

- Very good. Very good. Well, can I say gents, once again, we truly value the partnership we have with your phenomenal organization. We've done some wonderful things together and I'm so grateful that you've taken the time to share that with us here today. Thank you to you all for making the journey over after lunch and being part of it. So thank you guys. Let's give you a one final round of applause.

- Thanks.