PegaWorld iNspire 2023: Digital First: How BT applies a Centre of Excellence model to Simplify Global Complexity

BT is the largest telco in the UK, with a global footprint. With an organization with the scale and breadth of BT comes complexity. In two years, BT has built multiple applications using intelligent automation on Pega Cloud® – ranging from complex service requests to number allocation.

Structured around a COE that marshals front-door business requests to deliver in a scaled agile model, BT’s vision is to expand the use of the Pega Platform™ across the organization to ensure maximum utility and reuse at scale and speed. This vision is articulated in a simple message: "I want everyone starting and ending their day in Pega."

Find out how large-scale reuse, balancing scaled agile with a COE at its core, has enabled BT to mitigate legacy, transform at scale, and broaden Pega adoption across the business.

Transcript:

- My name is Mark Jackson. I'm one of the comms industry principles here at Pega, and it's my pleasure to introduce James and Gerald today to present to you. Just a bit housekeeping before I do. They're gonna present for about 30 minutes. Appreciate if you could keep your questions till the end, and then we'll answer them at time. And if you do have a question, there's a couple of microphones up there. I'll put your hand up and I'll bring one over to you and we can make sure that your question is heard loud and clear in the room. So thank you very much, and I'll hand over to James and Gerald.

- Perfect. Thanks so much, Mark. Good afternoon, everyone. Thank you so much for your time. I'm James Glavey, I'm director for design and delivery for BT. So looking after our technical, our solution design and our delivery and field services capability for our global customers. And Gerald, if you wanna introduce yourself.

- Yeah. Hi, I'm Gerald Griffin. I'm software engineering manager for the DPA, Digital Process Automation Center of Excellence in BT, primarily, yeah, if focused around, centered around Pega. So yeah, just briefly about who BT are, just in case nobody knows, world yeah, very large. One of the world's leading telecommunications broadcasting organizations. It's primarily based in the UK but it's a very varied organization. So in terms of its customer base, it's got customers, it gives kind of mobility, very mobile, simple mobile services to individuals right through to fiber to the home, broadband, TV, sport, small businesses, right through to providing extremely complex networks for large multinationals and government organizations. So yeah, across 180 countries for those kinds of customers. So it's got a vast degree of variability in terms of its customer base. And as a result got quite a degree of complexity as a result also. And interestingly, we were trying to figure out this morning, but it's got a legacy, it's lineage probably goes back about 150 years in one way or another from the birth of telegraphs right through now to, you know, what everybody considers to be, you know, an appropriate network for today.

- Okay, thank you. Wanna move on? Wonderful. So we wanted to spend some time today talking about a business problem that we had for our multinational customers and the way that Pega's helped us to solve that complexity. So I guess just to build a little bit on Gerald's introduction to the company there, if we look at our multinational customer base. So we started supporting global customers in the '90s. And since then we have grown and through acquisition and also organically, and with increasingly complex portfolio of products and services. And that's kind of evolved and created a level of complexity that we had today. We have about 3,000 global customers that we support and as Gerald said, across about 180 different countries. And the complexities that we have is effectively into four areas. So the first one around operating model complexity, we had a scenario where we didn't really have a standard offering as such. So we would speak to our customers about their requirements effectively with a blank piece of paper. And that would lead to many different support models and delivery models for how we would support our customer's needs. Second level of complexity around our product and service portfolio. So as I mentioned, we have grown and evolved over a number of years and we have inherited, but we've also built a number of different systems to design, to deliver, and to build our customers. And they have been built on specific products. So it's created a complexity for our teams whereby for customers that then purchase multiple products from us. Our employees have to know which systems to use for which products data doesn't flow fluidly between those and manage that estate. The third complexity is around contract complexity. So our customers have increasingly taken solutions from us rather than just taking products. So they would typically take bundles of different products with a bespoke service wrap. And again, coming back to my previous point, our design and our delivery systems are geared around individual products. So again, it creates an element of inconsistency. And we also have the vast majority of our work then by default is non-standard and bespoke, and our customers contract with us to bespoke SLAs as well. So dependent on the criticality of what they use our services for. We would have very different terms and conditions, different SLAs, even down to different templates and ways of engaging with us. And that finally leads onto the process complexity, which is basically a combination of all of that complexity together. So it's our employees who have to manage that. So our customers want and expect a seamless service. They want that as a consolidated solution and it's our people having to navigate all of that ecosystem and basically coordinating activities to create that kind of a single view for our customers. And that can often mean as I touched on, using multiple systems, isolated data points, and managing that effectively with manual handovers, spreadsheet trackers, all the stuff that we wanted to get away from. In spite of that, we actually deliver an exceptional service to our customers and one that we're super proud of. We have always achieved, you know, an NPS score of +40. So our customers recognize and appreciate what we do, but the reality of it is we just weren't providing a digital experience for either our employees or our customers. And we effectively had this scenario there, I guess to summarize where we were operating our business on very bespoke delivery models, and very manual in nature of how we got work done. We had too much inefficiency as a result of that manual work that resulted in high costs. And we really had a lack of visibility across all of those different component parts. We have a longer term strategy, so BT for its global division is replacing our international network. We are building a new global network and we are building that on one common system stack. So we are strategically fixing this problem, but that will take us three, four years to build and to transition our customers to, and we currently have about 3 billion pounds a year of business going through the estate that I've just explained to you all. And that's what Pega has worked with us in partnership with Virtusa as well and to be able to simplify for our employees and for our customers. So our way, I kind of desire in our mission statement of what we wanted to achieve with that, as you can see on screen. So to deliver the best end-to-end digital journeys for our colleagues to sell and to deliver brilliant customer experiences and by digital journeys, we wanted those to be simplified, to be standardized and highly automated as well, to make us more effective and to try and roll that out as far and wide as we could. And when we talk about brilliant customer experiences for our customers, they tell us that's all about being reliable, being predictable, being transparent, being accurate, and being relevant to their business needs as well. So I wanted to spend a little bit of time talking about how we structured ourselves and how we governed should I say, our transformation program. So firstly, we decided to deliver this transformation through a Scrum Agile approach. Relatively new concept to us outside of our technology and part of the business, but something that we wanted to trial here for our transformation. So I led a transformation team and a transformation program whereby because of the number of technologies involved, had an overall technology lead, had architects in there, firstly from Pega as our solution, but also a data architect, a solution architect, a customer experience lead to make sure that the customer was at the heart of everything that we did and kept us honest there. And then Agile coach as well, as I said, we were relatively new to Agile and we wanted to increase our maturity as we went through that business. And really the role of that functional leadership team was to make sure that all of the component parts that became part of our transformation all fed into one overall end-to-end digital transformation. And we really adopted this servant leader mindset whereby very much saw it as our role to remove any barriers to support our teams and really to enable the teams below us to deliver what they needed to deliver. In terms of how we then structured the teams, so broke the overall kind of mission and scope of our transformation down into manageable chunks and set up squads with product owners to run each of those and made sure that within each of those squads, so very consistent with Scrum methodologies, right? So all the resources required to deliver that business transformation contained within the squad and made sure that we had professional capabilities in there. So Scrum masters, process designers, and business analysts, but then really, really importantly subject matter experts from the business. So we took people that were previously leading some of these operations teams and brought them through to comment and to be part of our transformation for the last couple of years, and did that so that we would have that close working relationship with the business and to make sure that the people understand our customers, understand our system estate, understand how we get work done, we're involved in shaping what our future solution would be. And then finally, we also had developers within that team from Gerald's team, and he'll talk a little bit more later about what that looked like. The real, I guess, the point I wanted to make in this was, it didn't feel like a technology-led transformation, nor did it feel like a business-led transformation. It genuinely was the two different parts of the business working very, very closely together to create one solution on a consistent set of kind of KPIs and our mission as I say. So moving on to talk a little about our cadence and how we ran this. So really had two main objectives that wanted to achieve through the cadence. The first one being that absolute tight alignment with the business and making sure that what we were gonna deliver was gonna be fit for purpose, was going to deliver against the business's requirements and was gonna be able to deliver the business benefit that BT expected. And secondly, as we were fairly new to Agile in this space, that we would have the right cadence to make sure that we truly embraced that way of working and that we could create incremental development and releases, and be able to really start adding value from day one through our minimum viable products. So I won't go through in a huge amount of detail, but just to kind of explain some of that cadence. So at an executive level, we manage that cadence on a quarterly basis and we would start first with what we call our business community days. The transformation that we were driving really touch the whole business. So that would be us engaging with executives across sales, across contract management, across design, across delivery, and across our financial area. And we would bring insight into those sessions. So from the analysis that we'd done, what we felt were their pain areas and what we felt we could do to add value, but probably more importantly was our role in listening and making sure the business then had a voice in them telling us what were the priorities, what did they need us to fix, and what kind of value would that add and how would that add to the business? We then took that insight into our big room planning. So the whole tribe together for two days. We did that virtually where we would then take all of that insight from our execs and we'd figure out our detailed plans of what we were gonna be able to deliver over the next three months. And that would then be constrained on the resources and the budget we had available, but we would effectively use the voice of the customer to then prioritize and agree what we could deliver. And it wasn't a case that we could always deliver everything that was kind of on that wishlist from our execs. So we would then play that back into the third step, which was our playback sessions. And we would really use that to, I guess, almost contract with the business on. This is what we are committing to deliver to you over the next three months and if we deliver this, what do you commit in terms of what the business impact would be? And whether that be financial or non-financial. And we would then agree a series of kind of KPIs and things that we would measure to be able to make sure that that was having the desired impact. And we would then interlock and contract on that. And the next stages then were really a monthly cadence where we'd get back together with those stakeholders, we'd review the progress, were we on track? Did we have any unforeseen dependencies? Did we have risks? Were we delivering against what we needed to? And really importantly, where we were delivering? Making sure that the business was cashing the check on any business value that we were adding there. So then secondly and fairly typical of a kind of Agile methodologies and sprints here. So we ran our deliveries through fortnightly sprints. So we would start planning out, so what were we gonna do over the next fortnight? We would then move into our design and develop. So breaking everything down into task level of what needed to be done and who was going to do which task, and then manage that governance on a daily basis. Then we would demo to our user groups. So letting them see, letting them play with what we'd created and test that, take their feedback, what worked well, what didn't work well, how could we improve? So it was constant iterations getting better and better, and better, and more useful for our business users. And then once we'd meet or met the success criteria, then go into full deployment and formally release that piece of work. And then the final thing we did in that sprint then was a retrospective. So again, given the whole team of voice and I guess that's the message that I wanted to land was it wasn't just the kind of top team making these decisions, it was the entire tribe. Then giving them a voice to say, "What had worked well over the previous fortnight, what hadn't worked well, what could we do differently?" And that could be in how we developed, how we designed, how we'd engaged, how we'd communicated, kind of, you know, nothing off the table there. And created an environment and a culture that was just constantly improving and getting better and better every fortnight. And we would just run those cycles every fortnight. Okay?

- Okay.

- [James] And with that, I'll hand over to Gerald, for what you're doing.

- Thank you. Okay, yeah. So, you know, to support everything that James and the organization needed, we created a Center of Excellence. So again, working with Pega. So Pega was chosen by BT to kind of fill that gap to bring all of these disparate systems, you know, together, you know, to layer, to provide connectivity into those systems and bring everything into as much as possible a common interface. So we set up Center of Excellence or Center of Excellence, we've got a hub-and-spoke model. So to kind of fit in with the Agile, you've got the, you know, COE in the middle number of squads around the outside that are quite autonomous, you know, in, you know, following the kind of Agile methodology, they're meant to be autonomous. So product owner decides, determines what happens next, decides what's happening in the sprints with the Scrum master and the team. We grew very quickly. So at what one point, you know, we grew from three years ago to zero. At one point, we had 18 or 19 squads, you know, working around the side and we were providing Center of Excellence services and the services that we provide are consultancy. So we've got expert people within our Center of Excellence who provide consultancy to the squads in terms of how to deliver, what to deliver, how to use Pega appropriately and so on. And to kind of manage some conflicts as well. We provide platform support. So we've got two, but primarily one major Pega instance where we've got four quite distinct applications running on. So it's a Pega Cloud application. We provide the platform support of that on top of obviously what Pega provide out of the boxes on Pega Cloud, where we manage the incidents with Pega and support, you know, going back into the tribes and the users as well and manage that quite area. And in addition, we run, you know, the major upgrades, from, you know, the 8.7 to the 8.8 and so on. We do all of the release management. So, you know, at one time we had all of these 18 squads. Now, we've got about half that number of squads as the wave of demand has kind of settled. And we're in a bit of, you know, a bit more of a level cadence, but we do all the release management for every release. So for example, in the past year, because of the number of squads, and every squad is working in an Agile way, in one year we've done 130 deployments. So across all of that, so there's quite a lot of release management going on all of the time. We manage the resourcing. So we've got a relationship primarily with Virtusa who have helped us get to where we are. So you know, we work with Virtusa to get the right people, provide 'em to the squads, work with the Scrum masters and product owners to understand what they need. So, you know, different levels of Pega, you know, Pega BAs, CSAs and so on. And so we work directly into BT's architectural organization then the enterprise architects who decide where the company is going from a tech, you know, from a really kind of high level architectural point of view. So making sure that what we're doing in Pega fits in with their vision of where they want to go, what the strategic systems are, how the digital transformation is going on from and so on. We manage the security and data. So, you know, people in the squads, you know, they don't necessarily think about, you know, data confidentiality, authentication, authorization. So we set up a framework around that for managing authentication and authorization of people deciding what kind of access groups within Pega are appropriate, how they should be structured, thinking towards the future, you know, so that they are optimal, and then strategy also. So, you know, strategy even within Pega, when do we start adopting new things within Pega, when do we bring in new features? You know, a lot of people have been thinking right now, you know, when do you start using Constellation versus Cosmos? When do you upgrade? And so on. So you know, we work with Pega primarily as well in that to try and figure out what we're gonna do and other Pega capabilities as well, like process fabric, process mining and so on. And then, yeah, it's also governance. So you know, all the deliveries, we check the guardrails, we're providing reports on the usage of the system and also providing reports, you know, to James and his team. We provide a lot of reporting via BIX as well into a kind of a Google data lake that BT are using. So we're providing reports there, but also Pega reporting independently, more directly 'cause at times that's quicker and it's more effective than waiting for getting stuff out of Google. Yeah, and then we manage the external relationships as well. So all the relationships with Pega, with our suppliers, you know, Virtusa and with kind of everybody else, you know, in BT various kind of parties. So oh, wrong way, right? So yeah, how did we get here? So we started off, we had nothing. We didn't have a Pega platform. Pega was just chosen as the solution, you know, in January, 2020. We had no skills, no Pega process orchestration skills, case management skills within BT. But what we did have was, I think we hit a perfect storm within BT. There was the, you know, digital transformation was really kicking off. Agile was really being, you know, promoted a lot, you know, and we had a lot of support, yeah, for Agile coaching and so on. So there, you know, we were just at the right point that we could ride that wave and build up, and for Agile and Agile at scale to kind of be taken seriously and supported. But we needed to build very quickly 'cause there was a lot of demand there. So we started working with Virtusa. We chose Virtusa as our scaling partner. Again, that was January, 2020, February, March, 2020. The world just kind of closed down for a while. But nonetheless, you know, within that time, you know, during the COVID period, so, you know, this was January, 2020 BC as we said, yesterday in the meeting. But we managed to build up to a team, you know, with all of these 18 squads all through COVID, you know, multinational team primarily in terms of, you know, the Virtusa people, a few key people in the UK but primarily otherwise, you know, in India and Sri Lanka and working with James's team that are also, you know, based across Europe, UK, US. But, so we had to build very quickly. So we got good scaling partner, they helped us decide on Pega Cloud versus on-prem. And we had a really good licensing model with Pega as well that allowed us to innovate, you know, without any extra cost 'cause the license was already built in. So it allowed us to innovate quite a lot. And then we agreed some guardrails with the architects. So for example, you know, data management, we keep the data in Pega very thin. And so we used systems of record elsewhere as much as possible. And again, we look at the Agile ways of working. We had our own Agile coaches as well. And we also very much... We promoted Pega within the organization. We had regular show and tells, sometimes we got, you know, quite a few hundred people coming, understanding what we were doing. And we provide education as well. We help people from James's team and other customers getting through Pega certifications. Because in Agile, you know, one thing is Agile brings people from different historical cultures. It brings people from software engineering, but people who've no software engineering experience at all. So, you know, subject matter risk experts from the business, product owners, process experts. And so, you know, they all speak, we all speak in different vocabularies. So to bring people together and to get them working together, we promoted, and you know, Pega certifications for anyone who was interested and we provided coaching for that as well. So what have we... So kind of three years down, you know, we built really quickly, so we're quite mature now, but I think a few things are basically the same. We've still got the, you know, champions within BT. There's been quite a bit of churn but still the COE concept has been understood and accepted, and supported. So I think it's quite a robust, you know, it's a quite a robust model. The culture is still there promoting Agile, massive digital transformation mindset still in BT. But what we started to do as well is, you know, we've realized that we can measure a lot more. And so we can understand how the platform is working, and what case types are successful, what case types are underused, and also even measuring developer productivity. So we have built all of that up and we've got technical maturity as well. As you know we've worked with Virtusa to bring ourselves, you know, to where we are. But we've built up a degree of maturity within BT as well. And we understand, you know, automation itself brings new problems to the table. You know, sometimes things that are manual are actually easy. When you bring automation, you need a lot more predictability and stability, even for example, where you store documents, what the structure of those documents are. It can't be in disparate places anymore. You need to know where they are, so you can automate them. And then yet scaling partner, still very strong relationship with Virtusa but in parallel, we've built up our own BT team. So a year ago, just myself and one other person, were BT people. And I've had no Pega experience. I don't have any Pega experience, but in the past year we've built up a team of 20 BT people work side-by-side in the same squads, in the same teams with Virtusa. So you know that's still there, but we're building up, we're getting, you know, a different balance across our Center of Excellence. So I think we've got a good balance. We've got really good people in Virtusa and BT who work well together. And so yeah, Autonomy versus Control. I mean, this slide looks very like the last slide because the high level things have not changed, but the detail has. So for example, in terms of... We still provide the guardrails, but rather than that we found, you need to evolve. And that's the one thing, even the Center of Excellence, you know, no life form is ever perfect for an infinite amount of time. You need to evolve. And ideally you need to proactively evolve as well. Identify when you need to move, when you need to change. So for example, in kind of what you might call pure Agile. We found that the squads, the pure autonomy of the squads meant that sometimes there were too many conflicts or there wasn't as much potential for reuse as there could be. So we've switched that. So we gather all of our BAs from the squads, all our tech leads from the squads and the key people from the Pega Center of Excellence as well. And we manage kind of a single backlog now so that improves things like estimation, identifying conflicts, identifying potential areas, reuse a lot of area. But we still work in the, you know, the squads do the sprints every two weeks nonetheless. And we still communicate and promote, but we know we need to continue to evolve. And I think that's always the thing. And I think if you want to build a Center of Excellence, I would say these are the high level kind of building blocks of the recipe. But as to how they're put together, I think that, you know, in terms of quantity and what happens next. Same with the omelet today. I think that will vary from side-to-side. But these are the principles that haven't changed, that underneath they've changed for us. But these are the same principles that have worked quite well for us. And I would say that you just need to identify, you need to evolve, you should not kind of keep your head down and ignore the need for change. Somebody once said to me, "You've gotta go, go to the fire." And so you need to encounter and confront the way that your business is changing. 'Cause otherwise it'll change without you and you will get lost. So you know, if there's a fire, you go to it, you attack it. 'Cause otherwise it's gonna get bigger anyway, and you know, it's gonna consume you. So you need to tackle issues. I think even in PegaWorld, I think we've discovered that we're gonna do things differently when we go back now again, and our COE is gonna be different in a few months again, I'm quite sure.

- [James] Okay, thank you. Just one last line-

- Yeah.

- . Wonderful. Thank you. So just spending a little bit of time before we wrap up on the so what, so the results that we've had and what we've been able to achieve through our partnership and utilization of Pega is a genuine end-to-end process that's integrated into our historic legacy systems. So we've integrated something about 15 different systems into Pega. So for our employees now, they have a single system experience where the kind of model that we keep saying is around an objective of trying to start and finish your day in Pega. So they're not having to swivel chair between many different systems and tasks. We've implemented ServiceNow as a digital portal for our customers, again, integrated into Pega. That now means we've migrated 30% of our volume onto that ServiceNow digital portal. And what that's given us, is it means now that the vast majority of our requests that come from customers are catalog driven? So we get about 86%, should I say, of our requests now are self-service catalog items. And it's just removed a need for our employees to receive information historically just on email and to have to interpret that, to validate it, to assign it, that happens automatically now as do the data validations as well. So we've been able to automate those. And again, it means instead of people doing that, it happens automatically and it's also had a significant impact on improving the number of unclean orders that we would've got previously. That's dropped significantly. We've integrated Pega as I touched on with our delivery systems. So it's meant that we've been able to automate our KCIs or keep customer informed. We've done that just for our internal customers at the moment. So it means all the stakeholders within BT who need to know the current status update on something at those moments that matter, get that update. So it's moving us from a culture of people having to find out who's working on something and then chasing them up and phone calls, and emails, and being able to make that much more digital and automated and we have the opportunity to switch that for end customers in the future as well. We've integrated with our pricing systems as well so that it basically means that data is flowing right from the kind of front end when the customer's submitting the request right the way through design and delivery and into billing without people having to rekey information. And it's allowed us to automate our supplier ordering as well. So currently, we're at about 30% of our supplier ordering that's now automated and again, that started from zero a couple of years ago and we've got ambitions to keep that going and improving there. And really importantly as well, it's given us a far greater ability to be able to jeopardy manage requests. So we've got automated flags that are letting us know when something's at jeopardy, so we can be proactive and we can jump on that and fix that sooner. And that being achieved through having that end-to-end visibility of understanding where things are up to. And if you do one final click for me, please.

- [Gerald] Mm.

- And the impact of that for us. So we've seen a 38% reduction in the cycle time to get proposals to our customers and we know the impact that that has on wind probability. I think it's something like a 25% increased chance of winning business for the first responder from a supplier. So that 38% has made a massive difference for us there. We've managed to get 96% of our complex volume flowing through Pega. So again, whereas historically that would've been emails, isolated processes, no visibility, that's all flowing through that Pega system now. We saved tens of millions of pounds in our cost of delivery and that's predominantly through two areas. So one with the reduction of manual efforts, but our ability to be able to assign the right roles and the right tasks to the right resource and just making us use our workforce more effectively. But also was being able to more intelligently schedule and place orders so that we can coordinate activity so that things are delivered and arrive at the same time. So we're not incurring costs without revenues. And I guess the final point being, it's also created for us a platform that we continue to build on. There's lots that we still have left to do. We we're two years into this journey, we've probably got that long again at least. And there's more automation, there's more ambition and we want all of our requests to come in through ServiceNow. We want all of our supplier ordering automated and yeah, it's given us a really exciting platform to kind of build on. So yeah, just to thank you to the team at Pega for the support that you've shown us. It made a massive impact to our organization and changing how we deliver service and likewise to Virtusa as our partner. So, thank you.

- Thank you, guys.

- Thank you very much, guys. Oh, there we are. So as we've got any questions, we've got about 10 minutes left. If anybody's got any questions out there, you will have to. So look up 'cause I can't see anything in these lights.

- Yeah.

- Yeah.

- Oh yeah, we got somebody there.

- [Katie] Hi, good afternoon. I'm Katie from Excellus BlueCross BlueShield in New York. We use ServiceNow currently, but we don't have a connection into Pega. So I'm really interested to hear more about this catalog-driven request system that you have. What's in that catalog? How does that work?

- Okay, shall I answer that first on functionality-

- Yeah. Yeah.

- And then maybe you talk the technical side. So what is basically allowed us to do is to look at our entire portfolio and to create these catalogs, so dependence on bundles of services. So we provide voice, data, security and different types of connectivity as well. Dependence on, if they need secure connectivity or if they want to go directly through the internet. So we bundled our products together and made catalogs that are available through ServiceNow and then integrated that into Pega. So dependence on what the customer selects that will change the journey and how that gets triaged and who it goes to. So not everything needs to be designed depending on what the customer chooses. So depending on what they select in the catalog will then determine the kind of journey and the flow that follows through Pega. What that also gives us the opportunity for and what we're gonna be doing over the next few months is trying to have more guided assistance and support for our customers. So if they don't necessarily know exactly what product they want, but they know what functionality that we'll be able to build in intelligence in there, that we'll start to ask them questions about what they need and what levels of resilience, and what levels of security, and what bandwidth, and then we'll direct them towards a catalog item that's appropriate. So we've got that opportunity. And then the second piece that we want to develop that further as well is, we are getting so much more data and insight now through Pega because it's managing end-to-end and lots of that insight on our supplier performance. So we want to be predictive as well. So at the point of order, our customers can understand for that specific service in that location, what will our lead times be, will that meet their requirements? If not, what other alternative options are available for them and also that we can proactively jeopardy manage on day one as well. So I don't know Gerald, if you wanted to talk about technical side.

- I mean from the technical perspective, yeah, I suppose it's just all rest. So the requests come in and the requests are based on TMF standards coming in, and then it's other way is just Pega is providing at certain points within the workflow, status updates back to ServiceNow that are then provided to the customer.

- I mentioned about the KCI piece as well and that we intend to use ServiceNow for that as well. So the data will flow from our legacy systems into Pega so that we've got the current latest position and then we can reflect that in ServiceNow so that the end customer can see where we're up to at any time as well. So they're the next steps too.

- [Katie] Awesome, thank you very much.

- Thank you. I hope that answered your question.

- Okay.

- Thank you.

- [Mark] Any more questions?

- [James] I hope this is a friendly question.

- [Audience 1] Very friendly. Yeah, very good. I learned a lot. Thank you.

- Come on.

- [Audience 1] Yeah, can you talk a bit more about the pricing integration, please? What does that mean?

- So we have certain pricing systems that our agents use. So what they will effectively do, the customer will ask for a certain solution and functionality. Our designers then create what CP will need for that and also what services we need, whether they be BT services or third party. And then dependent on the different products that selected our agents and have to use different pricing systems to input that information effectively. And then that will give them a cost back and then they can turn that cost into an end customer price by applying any discounts and margins. And all of those systems weren't talking to each other. So there was lots of rekeying, same information over and over again. By integrating our pricing systems into Pega, it means when the request comes in, we capture the requirements from a digital requirements capture form. They flow into Pega, they flow into our pricing tools so people aren't having to rekey. And then if in, you know, two months time the customer says, "Yes, I want to go ahead with that service," that the references are still there so it can pull that back. So it basically stops rekeying and it lets data flow right the way through. Okay. Thank you.

- Anymore? Brilliant. Well, I think we're pretty much on time anyway, so thank you very much, gentlemen.

- Thank you.

- Very, very insightful.

- Thanks so much.

- Thanks, guys.