PegaWorld 2025: Revolutionising B2B Telco Installations with Pega Blueprint

PegaWorld 2025: Revolutionising B2B Telco Installations with Pega Blueprint

Good morning, everyone, and welcome. I'm very happy to join you, to welcome you to this session where we are going to talk about how Proximus is revolutionizing B2B telco installations with the help of GenAI Blueprint. I'm Jiri, I lead the Client Innovation team in Ma and I'm joined by two remarkable leaders from Proximus. Here we've got Laura, who's a B2B customer experience manager, and we have Kurt here, who's the tribe lead for Quote-to-Provisioning Tribe Lead. They have been instrumental to this transformation and really at the heart of driving this bold change while starting with small, incremental steps. And I have the pleasure to introduce this story.

And firstly, I would like to start with you, Kurt, and ask you to help us set the scene for Proximus, if that's okay.

Kurt: Okay. So Proximus is the largest telco provider in Belgium. Some of the people in the audience might not agree on this, but last time Telenet was here as well and they said the same. So what has changed recently is that Proximus is not only providing telco services in Belgium, we mainly do it for the B2C customers. For B2B, we are operational within Europe with our Proximus next brand where we also deliver ICT services and we now also have the international stack which is called Proximus global, where we acquired Telesign, American company, Root Mobile in India and where with our own domestic Bics company, we are now all branded together as Proximus Global and where we do deliver cpaas and digital identity services to big players.

Coming back to the domestic market, we do have our multi-brand strategy, where we have our premium brand, which is the Proximus brand. Then we have the mobile Vikings brand, mainly for internet, mobile services, also internet now and then, the low brand, the cheapest one, which is Scarlet, where everything happens digitally.

That being said, and in the context of Pega, so we are using Pega as our central order management system, mainly for our B2C, but now also in a second phase for our B2B customers, but in Belgium. So not in the international stack. And we are in that transition. So B2C it's already for a long time B2B, we are adding on top little by little. And the aim is that majority of our B2B orders also pass through our Pega ordering system by summer, end of this year it has been delayed already some times. So that's a bit more about where we use today Pega within our company.

Gerry: Thank you Kurt. And can you tell us more about your experience with Pega today?

Kurt: Yes. I can tell you a bit more about that. So about five years ago, the big Pega application, let's say software, came into my domain, and then I came to meet the bigger team because when there is a new manager, they all want to reach out to you, say hello, and want to do more business with you. And the first thing when Pega came to meet me, I said, we are not going to do more business as long as you don't fix the basics, because the basics were not okay. We had a guardrail score of 68 and I read somewhere you should be very, very complex systems to IT. If you have a very good application, you should be at 90. So I say we should do something. Also, our estimates when we needed to deliver a change request were very high. And for me it doesn't match with the low code application. So I said we have to do something. So that's where we started interacting with Pega and where we did an assessment of how to modernize the application.

That being said, modernization I discussed a bit yesterday. I will not repeat everything, but that brought me to a PegaWorld last year. And there, let's say, that's where I got introduced to do my first Blueprint.

Gerry: So I know that you had quite a life changing experience at last year's PegaWorld. Can you talk to us about what sparked your imagination and attention?

Kurt: Yeah. Okay. So last year when I came here, I was impressed. But everything got bigger. And this is also something what we discussed already today is that if you position Pega on the market, not a lot of people know about it. A lot of people talk about other companies. I will not mention the names over here, but I think Pega is a very powerful thing. And that's also my first impression I had last year. I got to know quite a lot of things, experiences with other customers. And of course, I got to know Blueprint.

So with a little push of some people in the room here, I was kindly forced to do my first Blueprint. So you see the picture here? That was me doing my first Blueprint last year and to be honest, I was impressed about it. It gave me directly a lot of ideas, a lot of questions. And as we were discussing of doing our Pega modernization, I directly asked, can we use Blueprint for existing applications to modernize them? Unfortunately, last year it was not yet possible. But okay, it's evolving very fast, but at the same time we have plenty of legacy applications as well. Old applications, old technologies. While discussing while discovering Blueprint, I say, why can we not just rebuild those applications? Because at that time last year, Blueprint was really made for creating new applications. Why those old applications? Why can we not just rebuild them with Pega Blueprint. So for a lot of ideas. Very impressed. I came back to Belgium after PegaWorld and I directly asked, or let's say, demonstrated the tool to my people. And also for a lot of people on the floor, they were impressed. And also getting to know for the first time Pega Blueprint. So really, really nice.

I also stimulated my team's not working on Pega to use Blueprint whenever they had to build a new application. It might give them ideas, it might help to do the design work. So that was really my first impression after Blueprint and PegaWorld 2024.

Gerry: That's great Kurt, and can you talk to us about how that led you to our team and to discussing a potential Catalyst workshop?

Kurt: Yeah. Well, yes. Like maybe also in other companies over here next to old legacy applications. We also call it shadow IT applications. Business cannot wait until it delivers it, then build something themselves. But of course, no support, no upgrades. And all of a sudden there was a business critical application and Laura did contact me. Could I have a problem? I have a very business critical application, but it's on a Maria database and never heard about Maria database. It's crucial. And will you take it over?

Okay. I don't have any competences with Maria database. But you know what? I saw a Blueprint. Why not give it a try with Pega and rebuild it? It will help me to extend my resource pool of Pega resources for my ordering. And then at the same time, I can balance my resources for your application to the others. And that's where, let's say I did end up with a meeting the Catalyst team for this new node. That shadow IT application.

Gerry: Thank you Kurt. And now over to you, Laura. Can you bring the situation to life for us? What was happening? What was the situation?

Laura: Well, I would actually like to check with the room. Who within your organization has shadow it or citizen it? At least one application that is citizen it. Raise your hands. Okay. Not everyone. I'm quite surprised. Okay. Then, who has at least one application that is run on the knowledge of one person? Hold on. So I had both. So it was an citizen it and run on one user or one person.

And so what happened was, you have customer order follow up, by the way. That's what Gofu stands for. And the initial application was called tofu, not the fake meat. It was technical order follow up. And so it was a dispatcher. What he did was basically dispatching technicians, getting them to customers on site. And what happened was, he was doing both B2C and B2B volumes. As you know, B2B typically has a lower volumes. It's only 10% of all the installations that we do is B2B, but they require quite some work. It's quite, with a lot of exceptions. It's also quite complex, but we don't really build business cases to get this automated.

And so what happened? This guy was very can do dispatcher himself. And he was like, I'm going to learn how to develop in PHP. And I'm going to, let's say outside of it, develop my own tool. Which is great, of course, because if the user himself builds a tool, then it is matching the user needs perfectly. So it's a great tool. And then it was within dispatching and the team started using it as well for dispatching B2B volumes and managing all the exceptions.

And then the guy was like, maybe I should find my own IT company instead of being a dispatcher. And so he left the company with all the knowledge, and all of a sudden we were left with this application, not knowing how it worked. A whole department working on it. Yeah. Silly situation, to say the least. And so, that's actually how we ended up, and how I went to Kurtz because Kurtz is a tribe lead of, a quote to provisioning, which is in this, in this field. And so I went to Curt and said, I have a problem. And he was like, I'm not I'm not going to sign a blank check just to take over this application. While we don't know what it does, how it is working. So yeah, that's when he first said, I'm not married to Pega. But then he said they have a quite genius, way of working where they facilitate a Catalyst workshop. And that's when we had our first meeting.

Gerry: That's great. And how did the workshop help you?

Laura: Well, it was, the good thing. So here you see a group picture. A lot of people, basically from three different angles. So you have process business people, which is myself and the team. You also had the people really working within dispatch and also customer service, very crucial because they will use the tool and they have built the old tool, or at least felt like they really built it. So it's very crucial to have them in this workshop as well. And then of course Kurt's team, it and so the critical thing is that we really needed to speak the same language. And so that's where Pega really helped us to, to have that common ground. Gerry: That's great. And can you talk to us about how that how that workshop was structured and how it worked?

Laura: Yeah, I still remember we had our first meeting and you were like, normally it's like, I think two days workshop. Yeah. And I was like two days for dispatchers to be in a workshop and also for people from customer service that might not work. And then so we squeezed it. So normally it's one day really on aligning and one day on creating your blueprints, refining it. But we squeeze it into one day. It was a quite packed agenda, but it was really a very good concept. So the morning was about, okay, what do we want to do? We don't just want to build a prettier TOEFL, right? It's we want to think about what do we actually want to, achieve with this new application. We might also think not only about dispatching, but maybe involving other departments. So that was the morning, and then the afternoon was the prototyping with Blueprint.

Gerry: Yeah. And what was the feedback like from the people who participated?

Laura: Overwhelmingly positive actually. People were really like, okay, I understand where we want to go to. I also understand how we could visualize this within 15 minutes, as everyone is saying, we had our first Blueprint. And it's really crucial for a tool that has no or limited documentation. It is in one person's head, but that person left. It is critical that the users can describe within the AI, basically within the Blueprint what it is doing for them. And then it just rolled out out of it. So it was yeah. Mind blowing.

Gerry: Yeah. And how how did you come to that vision state? Can you talk us through that as well?

Laura: Yes. So I myself had of course already something in mind. So I've written something down. We had some pre alignments with the DM and the team. To really check what, what actually do we want to achieve. And that was basically very clear. It's not only having because what tofu is doing. I did not explain that yet, but tofu, the current tool is alarming when an appointment is in danger. So for example, material is not delivered yet and tomorrow is the appointment, but the technician probably cannot do a lot. And so in B2B, we have a lot of these very specific exceptions linked to a certain industry, for example. And so that's why we needed a separate tool. Or the dispatcher built a separate tool.

And so here what we basically said was we don't just want an alarming tool, we want to have people working together because what we have is we have our customer service. They are very dedicated to large enterprises. You have one customer support officer for one customer, so there's a one on one relationship while in dispatching. It's just yeah, basically processing all the volumes. We do around 4000 installations a day and 10% of that is B2B. So for them, it's just they they actually don't really realize whether there is a B2B or B2C customer behind.

And so we really wanted to bring those two departments together because there's of course, quite some frustration when appointments are moved and these type of things when you are the main contact towards the customer. And so that's for us very, very critical in terms of not having a prettier tofu. We wanted to have, and that's why we call it tofu. Customer order follow up instead of technical order follow up. So as you can read here, it is really making sure that customer service centers and dispatching can work together within the same tool. They see the same thing and that we not only have that 360 visibility, but what is also crucial. And that is something that is not in tofu today. It is that you have, a workload management because today it is giving alarms but a bit best efforts. And with Pega, you can really make sure that you have the right cues, that you also have end to end orchestration, meaning that there are SLAs. If the SLAs not reached, it goes to another person. And that is critical for these type of exceptions.

Gerry: That's great. Thank you Laura. And once you had the vision defined and you brought the team together to pursue that vision, what happened next?

Laura: Well, then in the afternoon, we built our Blueprint and there it was. It was crucial for us because there was no other party where we could really visualize where we wanted to go to in such a short period of time. As you can see here, 15 minutes was just literally giving in the right information. And so the next video will really show what we actually did. It's of course a short video. But here you can see, as, as for every application or blueprint that you can select your industry. And then we had a one case type which is order follow up. And then basically by dispatchers describing what they currently do, the case type was, was built. There was a data model, obviously foreseen, where it was proposed to have different data sets. And here you could edit them. So it's all still very high level, but people could really think of okay, That is behind that case.

And then here you can see the preview of the application. And it was just literally within 15 minutes. And so you could start changing your personas. And also because it people were there within the workshop, they could see from their point of view the studio, which was also crucial for them to see then how business they could see their front end. But then, it could also see how the App Studio would look like, the App Studio for us was really crucial to see why because, obviously for dispatchers, TOEFL is a bit their baby. They build it themselves. And so there are people in that, in that team that want to have access to, let's say a deeper access than a regular user. And so here they could really see within App Studio, you, that they could basically change some triggers. It's still quite it's not that you are really coding, but for a business user or an operational user, you could really understand and develop yourself and not needing to wait for organization to change something. So yeah, that's that's basically it.

Gerry: That's awesome. Thank you very much for that. And obviously you've been, through this journey. What are some of the key takeaways and reflections that you have on the progress you've made so far?

Laura: Two very important key takeaways. So the first one is, we because B2B is a lower volume, we tend to not see the potential of automation. It's very complex behind. And so it's there's always a need for human intervention. But the dispatcher proved otherwise the other way around. So he built a tool he could automate work where we from a business and IT point of view said it's not worthwhile. But now we're replacing it and we have a business case. So really think about workflows in a very structured way. And even if it's very complex, and not a lot of volume, it might still be worthwhile to, to have a basic structure. Especially within Pega, you can, you can really have a basic layer and then build upon, which is, which is very interesting, for us in such an environment.

Then secondly is Blueprint is not only for it, it's really also built for business people. So, when looking at the, the servicing teams, so really the people being confronted with customer complaints and the dispatchers themselves, they use blueprints and their mind was blown. It felt like they could develop. So that was very nice to see. So I would really recommend everyone to not only think within your IT departments, but really go outside, to process experts for example, but also to users and encourage that citizen development mindsets, but in a controlled way, of course.

And you can see indeed at the at the bottom of the slide a bit the timeline. So we had end of last year, the, the famous Catalyst workshop, which I really recommend. Then we had the refinement now in the first part of the year of the Blueprint. Because it's not if you create a blueprint that it's perfect, you still need to refine it, have, several iterations on it. And then in Q3, we will start the implementation. I'm looking at RAF. He's nodding. So that's very good. And we will do this with Pega consultants so they will implement it. So then we have a full circle. They will hand it over then to the team of Kurt. And so we really hope for a commercial launch in Q4. Then maybe next year we will have a whole other story and show you how it is actually working.

Gerry: So that's great. Thank you, Laura and Kurt, what about you? What are some of your reflections on this process so far?

Kurt: Well, it's a very, very, very, very nice. And for us it's also in the bigger picture. We are thinking and planning to move to the cloud. And when we discuss with our current teams, because today we have everything on premise. There is quite a lot of resistance. Some people within operations which are now maintaining the service, they feel like I will lose my job and what will be the impact. Today you can be proud or not proud about it, but we are running on an Oracle database that they have direct database access. They can manipulate some things and we have some processes to do corrections, all those kind of things. If you go to the Cloud Pig as a service, you don't have that access anymore. So there is a lot of change management that needs to happen.

So taking here Kofu as a first example, start small. We want to bring it. It will be directly on the cloud. And we hope to have a lot of learnings about it that it will ease a bit the change for the other teams as well, but it will bring a lot of learnings because that is one of the of the main steps where we want to bring Kofu.

The other thing as well is, today we are still on a Pega 8.6 on premise, so if you would have built it on premise, it would have been again with an application which is on a version which is out of service. So let's say I had to push quite a lot in the organization to go directly to A to Pega Pega as a service to build it in the cloud to go through. But that's really, for me, also a step in moving all our other applications to the cloud, learning for the team so that they start feeling comfortable with with the cloud capabilities, things like that.

And also, I just want to come back to Laura. You might have say you have done some iterations. You only start in Q3. We had to negotiate quite a lot with Pega and Proximus on really the legal aspects, because in Europe they are, and especially in our company, a rather strict on putting that data in the cloud of an American company. So this is quite, quite a lengthy process. But in the end, we have now the big framework being signed so that for all our other applications, all those hurdles are over. It was quite frustrating that our legal and security department was doing so difficult on all the dots and commas. Laura can talk about it. Didem can talk about it. But that's why it took so long. But now Diem has started. We aim for 2 to 3 months, and in Q4, we hope to see it working.

Gerry: Yeah. That's great. I would like to thank both of you for sharing your story. This is a wonderful example of how we can combine a visionary future state with practical execution. And the next step. Like you both are saying, there's still a solution to be developed and delivered, which is which is great. We look forward to partnering with you and putting that into production in 90 days or less. Indeed, that's the ambition. And I'm sure we'll have another even bigger story to share next year. So thank you. Yeah, thank you very much. Thanks.

I think the time is now to open the floor to any questions to Laura or Kurt, if you would like to ask any question. I would like to ask you for a favor, to come to the microphone and ask any questions that you have.

Q&A Session Audience Member 1: Hi. My question is, in quarter one, you had your Blueprint. So why is it still taking you 2 or 3 quarters to go live?

Laura: Well, it is in we actually had already last year the first Blueprint. But then, as Kurt mentioned, it was quite a lengthy process to get the documents signed. But the main challenge for us is getting the data ready for Pega. We have a lot of, yeah, as you can imagine, the the guy building the tool building tofu Awful. He just had no rules. So the data model was very illegal. Let's say in it terms of what he did. And so we needed to have a lot of work on trying to look into the data. What is what is behind that tool?

And then I think it was rough. You were giving advice like we were really focusing on the current tool, trying to figure out how it is working when it is triggering alarms. And then RAF really advises like, okay, but can we take again one step back, see what do you really want to achieve. And maybe just start from from a blank sheet. And that's accelerated the exercise to to go a bit faster. But that was main loss of time was negotiation and then preparing the data.

Audience Member 1: One more follow up question. Did you had any data migration to be done? Like Blueprint will create you a new application.

Laura: No no no, no data migration. No, indeed.

Audience Member 1: Okay. Thank you.

Audience Member 2: Thank you. I always got a question. And this may be a Pega question and a question for you, but we're, I'm at US Bank, and we're going live on Monday with our first Pega app. And we went through did our Blueprint process and, you know, had our little Catalyst type meeting where we went through and worked it all out, even though we had done a lot of pre-work before that to kind of get the Blueprint back and forth as we were signing contracts, we were pretty close.

But I'm wondering, in your Catalyst meeting, did you just kind of flow out the happy path of all the steps? Because for us, it was like, God, we got a lot of decisions that happen along the way. And if this then go this way, and if that, then go this way. And like in this morning's meeting, you know, they were saying, well, we should get rid of BPM because it's so much clearer in the Blueprint, and I don't know if that's true for the unhappy parts. I think it's great for the happy path, but like, how did you show like the the all the flow in your Blueprint or did you do that later? And just the Catalyst was like, we're just going to focus on the happy path, and then we'll work through all those details later on, if that makes sense.

Laura: Yeah, yeah. Yeah, absolutely. So basically TOEFL is all about the unhappy flow. There is no happy flow in TOEFL because it's it's giving you when the appointment is in danger. To give a very short answer, obviously on that one day Catalyst workshop, there is no time for details. So it was getting the framework ready, visualizing how the future could look like. But then within Proximus we have two profiles. We have a process architect that is developing or designing Redesigning the high level flows. And then we have a process expert that is really going into the details. But we are actually not reinventing processes. They are there. They are already there. So we had a lot of documentation, word files, PowerPoints that we also put in the Blueprint. And it was it was quite powerful. We still have to adapt. And I don't know if you want to add anything. And if you want to add you, I kindly ask you to go to the mic.

Kurt: It's a very good question, by the way, because as you can imagine, one day, can you capture a complex process or deception and so on? The idea is that, as Laura said, you go from vision to what you want to really to achieve. We you have a roadmap. Obviously, it's not only MLP one that are going to be more more releases of this. And then what happened is when we start the engagement, the first couple of weeks or three weeks, depending on the complexity, is all about discovery Already faith where we're going to really drill down into those those details. Right. So I think that's that's where you where you're going to capture those exceptions. In your Blueprint or it gets reflected somewhere. You work on the Blueprint, of course. Yes. And you keep refining it. Yes.

Gerry: Yeah. By the way, Ralph mentioned MLP. Raise your hand if you know what MLP means. Okay. But are these all employees or. Because I never heard it it's during the Catalyst workshop and they say yeah, we're building a first MLP and a second. And I was like, are they making a mistake? Is it MVP? But MLP is minimum lovable products. We want you to love it. Yeah. It's a nice philosophy. Very good. Other questions.

Audience Member 3: So one of the question was asked by my fellow friend that you didn't, do the data migrations. So then how your process flow is, how you are ensuring that those process flow is correctly working based on your historical data?

Laura: Yeah, it's a two fold answer because some of the data we are, because there is also a huge, transformation within our workforce system ongoing. That data goes to the cloud. So yeah, there we are benefiting from that. The data can be pulled, pulled in into the PegaWorld, let's say. But for the others it's but I think when it comes to the data model, we have a phased approach. So the the first MLP is really focused on, a like for like almost of what currently is there because we don't really have the time nor the the means to really investigate all of the data flows.

So what we are doing is for some of them, we are still basing ourselves on CSV files, which is obviously not the best thing to do. Yeah. But then we have at Proximus, we have a very clear vision to put our data in data products so that each and every system can call a certain data product, like an order, for example, or an appointment. And it has different parameters or different qualifiers within that data product that each system can call and consume. And that's the long term vision. But that migration or that roadmap is not yet finished. So that will be probably a multi-year program, multi-year.

So we are going from CSV fully CSV today. Just for the record, sometimes the a CSV is down in tofu today, and no one really notices until someone within dispatch is like, hmm, it's already been a while since I've seen that exception. And then someone is indeed looking in the database and oh, that CSV file is done. So today we're going from the worst case to already having something. And maybe you can elaborate, but there is already some sort of monitoring where Pega will tell this CSV file is not consumed. But then we go, obviously the end goal is to consume these data products and get fully rid of all the csvs. So the first MLP will be a bit 50, over 50, 50% Csvs and then 50% for the, Cloud data of our workforce management.

Gerry: Very good. I would like to thank both of you again. Thank you all for joining this session. Thanks.