PegaWorld 2025: Transforming Customer Interactions – Insights from Northwestern Mutual's Pega Implementation

PegaWorld 2025: Transforming Customer Interactions – Insights from Northwestern Mutual

Good morning. I'm Suzanne Clayton. I'm a senior director. I manage the EY relationship globally here at Pega, and I am here to introduce this session. So we're going to be talking about transforming insurance customer interactions, insights from the Northwestern Mutual implementation.

And um, Northwest Mutual is going to be talking about their journey leveraging Pega to drive value for their customer experience and efficiency gains. So we're going to start out with Sheldon Clarke, who's a VP of technology that helped drive the initiation and delivery of the transformation program. and then that'll be followed by Prasad Krovvidi, a managing director at EY who has been responsible for the Insurance and supporting the Northwestern Mutual delivery. So I'm going to bring Sheldon up. Thank you.

Good morning, everybody, and thank you all for coming to hear about our Northwestern Mutual journey along with Pega. I hope you all are having a great time at the conference. All I themed and ready to tackle Blueprint. So I'm Sheldon Clarke. I'm with Northwestern Mutual.

And for those of you who don't know Northwestern Mutual, we're primarily known for our life insurance, particularly in whole life. Um, and, um, I've been with the company now for three years, and my role is a VP of Software Engineering. And I focused and spent a lot of my time focused around technology modernization, large scale transformation. And before Northwestern Mutual, I was with JPMorgan Chase, before JPMorgan Chase, I was with Nationwide Insurance in Columbus, Ohio, and then also Grange Insurance. So between banking and insurance have got a pretty good depth and breadth of experience across the financial services space.

So agenda wise we will talk about. So introductions I already covered. We'll talk about the challenges that led to the Pega selection and implementation. Then we'll talk about the journey. Um, how do we how did we move along the path, uh, to being here to talk about some of the successes that we've had, the outcomes and our future with Pega as we move forward.

And of course, we've had some lessons that we've learned along the way. So I've already talked about Northwestern Mutual just really quick. Again, we're more than just a life insurance company. We bring the whole financial package, uh, to, to to our customers, uh, not just life insurance, but annuities, wealth management and retirement planning. So we bring the whole financial, uh, suite together.

And so, you know, our motto is protect and prosper. And, um, through these pillars, we're able to do that. So when we looked across the service operations landscape, we we noticed that it became very clear to us that Modernization is really critical and it's urgent. The time to act was now. And what drove largely the modernization initiative is that we've had 32 plus applications that needed to be integrated across the ecosystem.

It took about five months, on an average, for new employees in the customer service center to be onboarded. And in addition to that, we've got 70% of our documents needed to be touched in some way, shape or form. And the desktop that they operated from was cluttered with 20 plus applications that they had to navigate. So that led us to the path that we had to formulate a clear mandate, and that mandate was around make it seamless, make it automated and make it guided. And it was very important for us. And what led to the selection of Pega. And so here is a snapshot of our journey. Um, we wanted to really understand what goals and objectives we were going after and we wanted to solve for, um, which I've highlighted in a previous slide, and we wanted to make sure. And why that was critical for us is that we wanted to make sure that we didn't just select a technology and look for a solution. We wanted to start with the problem and whatever technology or partners that we select, it would fit the needs for the issues that we were tackling.

After we we've we've identified and settled on the clear mandate and the things that we wanted to solve for. Next up was who are we going to partner with? Not only from a technology perspective, but also from a vendor partnership implementation partners. And we looked across so many different applications. We spent so much time, the entire Northwestern Mutual team evaluating, do we build something on our own? Do we go with other stuff or do we go with Best of Breed? And we landed on. We wanted to go with Pega full stack for for a number of reasons.

And you'll see where for from a Northwestern Mutual perspective, we selected not only case management, we've also selected the service desktop. And we'll talk a lot more about that here as well. So. We think big and we execute tactically. So we start with the end in mind and we wanted to understand how are we going to deliver value incrementally in a meaningful way to our business so they don't have to wait 3 or 4 years or five years to start to get value? And one of the things that we wanted to make sure that we, we, we evaluate is how did we how do we deal with the friction of employees having to deal with 20 plus applications on their desktop? We know we're not going to get rid of them overnight right away, but we know that we wanted to at least start to make it less friction.

And so therefore, a customer 360 was something that we knew we wanted to be in our first MVP, our first rollout. We also knew that we wanted to have an integrated telephony experience. Not only does the phone call come in to the desktop, but also provide that screen pop and help them to identify who is on the other end of the phone call at the moment that the call arrives. We wanted to make sure that we've got good ways and consistent ways in which we authenticate and verify who the person on the other end of the phone say they are. And so those were things that, while they may seem very simple, when we observe and and, and shadow the users in the contact center, we spend a lot of time what we saw.

They spent a lot of time putting customers on hold, especially for the newer folks, and having to consult with either manuals offline, or make phone calls to others to help them get through. And so you can just imagine the friction and the patience of having that customers are having to be on on hold. The frustrations that you may see from there. And so we knew these were key things that we wanted. And we wanted to also start with a small a small pilot, which was very important for us.

So that was year, year one. We when we roll that out for year one, we started to get some really, really good early feedback, positive feedback around what went well and what we could improve upon. And so that led to now a year two where we started. We took those feedback and then started to scale and start to, you know, add more product lines and more guided experience. To that extent, I will bring my friend Prasad up to talk about our partnership.

You can keep it. I got one slide. If you enable the mic. Thanks. So thank you, Sheldon.

So one of the key things, um, is it's always a privilege to work with true partners like NM, right? So as we started the journey, we thought about how we should drive this journey as an CI. Right? It's very, very easy to effectively go and do a sales pitch. But to build a true partnership model, we identified about four fundamental components. One of the first components is to foster innovation and have quality delivery. Right.

Um, so innovation is a term that's consistently used by everybody, but it's very hard to execute, right. You would need leadership support from a client perspective with folks like Sheldon and a few others. We were able to take early decisions to make sure that we not only have quality delivery, but we also evaluate the key aspects of Pega and leverage them and not shy away and do minus two versions or minus three versions. So that resulted in us effectively implementing Constellation. It's one of the first implementations of Constellation.

And trust me, it was not a very non-smooth ride. We had a pretty bumpy ride, but in the end, the commitment of NM with our support, we persisted. And right now we have a good implementation of Constellation, right? The second aspect, which I think was very interesting, is we wanted to go in and ensure that the IP of the solution that we build live with NM resources. So NM folks actually had a plan up front as to how the knowledge transfer would happen. They had some experienced resources up front, but at the same time we ensured that we had a preplan of making sure that folks start leading work streams right now, um, in a current state, effectively.

EY is the arms and legs of the engagement, and a number of these implementations are actually led by resources. And we hope that continues ahead, because the objective is to ensure that we make sure that GNM is self-sustaining. Right. The next one is establishing a true partnership model. Again, um, this is easy to say, but hard to execute.

The idea is when you have a transformation program like this, right? You have a number of stakeholders and operating from an engineering standpoint, right? We want to make sure that we bring various teams in place, and ensuring that EY experience with other areas of GNM is being shared across. What that helped us with is to effectively drive solutions for key problems and even establish relationships with them, right? So we effectively worked across stakeholders and we always kept our eye on the goal. Although there were times where we got a lot of stringent feedback and the last one and the key one is having a flexible engagement model, typically through a transformation journey, right. We cannot have a consistent engagement model. And we wanted to make sure that we meet the needs of our client.

Right. So effectively the way we approach this is we had a core team, but we were actually willing to scale up and scale down and at times even put the team on pause to ensure that the program progressed and we were meeting the needs of the program as opposed to driving it through an SOP. So I think these four factors really helped us understand them better and helped helped us deliver on NMEs goals so far. And I think NM does appreciate what we have done so far. We do.

Thank you. A. Lot with that. Back to the star of the show, Sheldon. I will just emphasize the the partnership, right? Not only was it with EY, but also with Pega as well, because we we took a leap of faith in the sense that we knew that this was going to be a 3 to 5 year journey for us.

And we had some decisions that we had to make. We know that Constellation was the new thing that was out. And we know that if we played it safe and go with the current proven platform, by the time we were done in 3 to 5 years, we then need to focus around upgrade again, and it's tough to convince our business to dump the money they've dumped into this. And then right as we're done, another upgrade. So the partnership is is really something that I'd emphasize on that says that was really a core part of our success.

We did find some issues within the Pega Platform, but the partnership from an early adopter perspective has helped us to overcome. And I can tell you those issues that we've found never threaten our implementation plan at all. So kudos to the Pega team. Kudos to the EY team for being there with us and making us feel really, really comfortable taking on this unknown risk, right? Outcomes. We we delivered on the pilot.

We delivered on the things that we set out to accomplish. Uh Northwestern Mutual. Along with a lot of other companies, right? You know, when we start to spend a lot of money on projects, people from different walks of life, different companies typically come with some level of concerns, right? They don't necessarily want to wait 3 to 5 years, uh, you know, big bang approach. And so we had to make sure that we're delivering value along the way. And we had some really, uh, successful delivery and outcomes across the customer experience, operational efficiency and agility.

And, uh, you know, some of the feedback that we received from our pilot was so critical that we had to make those changes and incorporate those changes before we scale. And and oftentimes the engineering team, along with our product and business team, you know, it's like, wow, if we had to custom build this, there's no way we could have incorporated the feedback from the pilot group and scale it as quickly as we were able to. Given our success, given the feedback from the business, given the fact that we've now got a lot of maturity and experience around Constellation the platform, the partnership with Pega and EY is is proven to be solid. Uh, we we clearly can state that we're going to continue with our execution and our five year. We're two years into our five year journey.

I remember we quoted we started talking about how long will it take us to be done. And our executive sponsor on the business side, we were teetering between 5 to 10 years, uh, depending on investment. And she made it very clear. Uh, we had to be done in five years. Right.

And so, uh, we're making really good progress, and we've got no concerns that we'll be able to continue. The theme here was I. We've not yet incorporated all of the AI stuff into, but we have teetered with some of that. Um, in terms of our future, we believe that it could start to add value to our CSRs and really assist them in a digital way to go out, bring information in, help to summarize it, and present it to where they could either make a decision. And so we we expect to start to incorporate and adopt those those features into our platform.

With that we're we had some lessons learned. Stakeholder management and engagement was crucial. Uh, with with any big transformation initiative, we have to make sure. And it's really crucial that technology and business operate and move as one. and we learned that on very early.

We operated in a transparent and manner. We had to think about how we're going to scale. Um, we know that we had some ideas around scaling, but as we start to roll it out, we had to pause, revisit, take on additional scope that we didn't think through because the business process itself would have been fragmented. And that's something that we didn't want to do. So in some cases, we had to expand scope to make sure that as we move capabilities over as best as we can, we don't keep it as we don't make it as fragmented as as it could have been.

We want to continue to embrace and leverage Pega's capabilities more. Um, every year for the last six or so years that have been coming to the Pega conference, um, I'm always amazed with what's next? And? And it never seems to amaze when when I come to these, I get energized to go back and see the capabilities that the platform, the decisions that we make to not custom build, but leverage partners and leverage, uh, capabilities that Pega and other providers. How do we take those advantage and bring them to market faster for our clients, our customers, our CSRs? And so we're planning to continue to expand, continue to leverage the capabilities in the platform. And I can tell you that as recent as yesterday, I was asking someone on the business, uh, she's here in the crowd around. Well, what has been the experience? Because one of the the desktop capabilities that we have today, I won't name the application or the vendor.

It's it frequently crashes and it's around 20 to 30 minutes of recycle time. And one of the promises that we've made when we rolled out the service desktop is that with Pega is that it will be available, it will be stable, you know, highly available and resilient. And that's always the question I ask. How is it? And I've heard that it's been pretty stable. You know they don't experience the crashes.

And perhaps we could, um, add more capabilities. So the good news is that the business wants us to go faster than we're able to move. Um, and we'll continue with the journey with that. Any questions? Um, what were some that you mentioned? You had encountered some issues in this journey with Pega. It would be great to hear some maybe examples of that, and maybe even examples of the early feedback your stakeholders shared.

Um, where you found that Pega provided the Opportunity to move faster to accommodate those kind of nuances or new changes to the design. Good question. So in terms of. So the case management was one of the core things. So we have about 5 or 6 case management platform that we use.

And our mandate is that we're going to go from 5 to 1. And and our contact center was really more product centric, focused than it is customer centric. And we wanted to make sure that we move into a customer centric versus product centric. And what we didn't factor in was that earlier on is that when we start to look at a case to work that case from start to finish, it may require more than one teams. And we started to take a team based approach and realized that unless the team that start working on the case can complete it, if it has to go to another team, we had to figure out, do we bring that team onto the platform or wait? And so it's those types of things where initially we started to take a team based approach to say, we're going to bring team on our department based approach, only to find out that we had to recalibrate a bit to say, well, let's take a look at who all is required to work a case and complete it from start to finish and determine whether or not right, whether the team based approach work or partial teams across multiple departments work.

In terms of feedback around. What could we have from a business in terms of what we incorporated? We took a really selective view, and we wanted to be careful around how much we expose. And candidly, there is a lot of calculations when we start to talk about life insurance. There's a lot of calculations and projections that that has to be true. And so we started by saying there are some core basic information that we want to make available in our client 360 platform.

And the feedback is that it's great, but it's just not enough information. And so then we had to think about what additional information and the systems that we would need to integrate with and what would that lift be. So it's those types of feedback that says, hey, if you add 2 or 3 more things to it, I could avoid going to three more applications. And so it's that type of feedback from a pilot that was important for us to determine, are we adding value when we when we deploy or are we adding to the friction. And so we take all of those things into consideration.

The engineering team looked at it, came back, partnered with the business and say, I think we can do these things within this time frame. Business thought it was reasonable and we moved forward. How do you use blueprints during the design process? Blueprint when we started was we started to know, right? We're now in the process of evaluating because when we started this journey, Blueprint wasn't really available at the time. And but now with this is a record breaking year, I think, for Northwestern Mutual, for so many people to be here at the Pega conference. And by and large, there's a lot of product and business people in addition to our engineering teams, spending a lot of time getting their heads around Blueprint.

So we started to move into the next phase of our our modernization. We believe that Blueprint is going to be critical for us, and that's why we made the investment to bring so many people here. And you talk a lot about the CSR. I mean, phone. Phone call.

Do you have a self-care internet for your customer. And do do it, do it. Include in a in what you built. Sorry, could you repeat the question? The you talk a lot about CSR and do you inside the project. Do you integrate the the the self-care for your customer on the internet for a self service? So yeah.

So we we have this model. So it's a great question right. Um, we've done some pilots around that. We've not yet done that. And part of the selection for Pega, we wanted to make sure that the platform itself can scale out to external.

Right. When we so choose to right now, we believe in eating our own dog food. So we want to start first internally, right. And we focus on internal teams. Next we've got some some work that is in the pipeline Around our managed client billing account to where we're looking to extend.

Now, some of those capabilities out. Right. And so we've not done it yet. But as part of selecting Pega, we did the proof of concept to make sure that it could work. Now it's a prioritization issue for us, which is coming up.

But we validated the platform could do it right. So trust but verify. Sure. All right. Okay.

Thanks for giving us a background of how you implemented Pega. So can you tell us how you utilize Blueprint and how was the journey overall and how really you utilize the outputs of the Blueprint? So we've not yet taken any Blueprint stuff to production, but it has garnered a lot of attention and we believe that it will help. And so, you know, my colleagues here in the audience, Adnan, you know, he and his team from a claims perspective. So we started with the customer service in before Blueprint was available. Now we're thinking about expanding into claims right? And it's very likely that as we expand into claims, Blueprint will likely play a big role in that.

Okay. And have you retired any of your legacy systems so far? We have not done that yet. And that that's a big part of. All right. So we're a year or two in.

Right. Year one was foundational proof of concept, making sure that we can do the things that we say we can do. Year two we started with small pilot and started to incrementally roll out. I would say as we start to hit into year three, likely we'll start to take capabilities off of the cluttered desktop, but we have not done that yet. But that is a big part of the goal.

And that's precisely why we started with the client 360 and starting to get feedback, because very soon we'll start to ask questions and provide surveys around as we start to take applications away, or what applications can we take off the desktop and make sure that there wasn't anything that's missing. And so that's why 360 360 view is so super critical for us to start with that. Okay. And for your system of records, is it primarily the interaction between Pega and your system of records? Is it primarily through APIs or is it a direct database kind of. Primarily through APIs.

And so one of the our mandate is that we we wanted to make sure that our business rules that run our core business operations were external to Pega. Right. And we wanted to make sure that we don't duplicate and bring things in. And so as part of selecting the platform, we wanted to make sure not only can Pega operate on its local native data, but also data that's not native to Pega through the APIs. And how do you bring that in and create that frictionless experience so that the users that are interacting with the platform has no idea where the information is coming from? Right.

And so a lot of our data is coming through APIs. We've got hundreds of integrations that we we've we've done to bring the data in. And we still have a lot more to go. Okay. So are you using Pega primarily to orchestrate the journey or the workflow or.

It's also a system of record for some of the policy details or whatever. Not a system of record for any policy information. Um, it's more from a customer service perspective around how do we bring that unified, frictionless experience together and leverage the servicing workflows to make changes consuming the APIs across the ecosystem. And so it's not a policy admin. It's not our intent to do that.

But it needs to coexist in a frictionless way. Okay. All right. Thank you. I have a question.

So like are you guys are in the Pega, the Customer Service framework, right. Is it on like a 24 two or like 24 one? So we we are using portions of the Customer Service framework. Right. Um, and and I say that right. Because for the most part, we wanted the unified service desktop.

Aside from that, all of our data, all of the things that populate and present information in that 360. We use APIs. So it reduces the need for us to bring data into the customer. 360 data model within Pega. Right.

So we're not using the entire data model itself, but we are using all of the data model for any case management. So any case management Pega is a system of record for anything outside of case management that is required to support that. It's integrated in real time using APIs. Oh, you mean like the desktop means like it's not like a call center portal application? It's not a web application. You mean like.

It is a it is a portal. And it's. But it's not a thick client, right. And so the service desktop is, um, a new bolt on capability that Pega offer as part of their, their service in portal. So it's a, it's a portal framework specifically for bringing an integrated and stitching unique experiences together for the CSR.

OK and even Pega also came up with some Pega Voice AI. Right. So to transfer like a speech to text, are you guys using any chat? We we have not yet. We're evaluating. We understand and we know that the capability is there For us, we have adopted this crawl, walk, run model that we're at the base, and we wanted to first make sure that we don't lose sight of what it is that we're initially trying to solve, which is how do we make the experience frictionless for our CSRs, our clients, when they call in? And as we in the later years, as we move forward, perhaps that's something that we'll evaluate.

But we've not done that yet. Any version number that you can give me that you are using. Oh 24 part two. Okay. You guys started from the scratch.

Or like you guys did any upgrade from 8.8 to 20 4 to 20 4.1 to 2 to only one update. Oh, okay. Oh, okay. Okay. Well, that means you guys started from the Constellation starting. Not like cosmos. Okay. Thank you. And that was intentional. Um, excuse me.

Rich Lane from selective Insurance. I just wanted to ask you. It sounds like you have some heritage systems that are on prem, and you're using cloud based Pega. That's correct. So we have a mix.

We have we have cloud and we have on prem systems. And we're using Pega in the cloud. So I'm assuming you have to use the Prem bridge if that. If I'm stating it correctly to to get cloud to ground connectivity. Is that true.

What I do know is that for us, and I'll probably ask Vasu or someone to help me out here. Who's in the audience? Is that we we've we've from between Northwestern Mutual and AWS is where we're hosting it. We've built a private tunnel that allows us to tunnel in, and then through that, we have access from API perspective to make any of our our endpoints available in the cloud. Across that VPN. I was just wondering if, if you were using that prem bridge or not and.

I Rob RBC. Do you guys. Know? Can you say that again, please? I think it's called the Prem bridge that you would go from cloud to ground if I'm. No, we are not. So our Constellation is running on Pega Cloud, which is different from our Northwestern Mutual AWS cloud.

And we have connectivity between that cloud. To dedicated VPN. Yeah, through VPN and internally we have security policies that require us to go through a reverse proxy. And so we use a reverse proxy to control the traffic that's coming from external cloud internal. Thank you.

Is only relevant for GenAI connectivity. So unless you're using a tech solution Knowledge Buddy Coach is not. All right. Thanks. Thank you.

Thank you sir. Any more questions? Oh. Hey, Sheldon. Um. Great presentation.

Quick question on, uh, this is your build the solution for your policy services, right. Any plans to extend this to your producers or distributors? The same model. Workflows, processes? Yes. And so coming back to the model that we write, we want to start internally. Make sure we optimize before we expose too much of our our issues that we may have with the platform.

Uh and and then now we're going to look out and start to do more self-service capabilities. And so we're at the point now where we're evaluating those workflows. Uh, so right now it's all internal. Um, soon as part of our roadmap, we will start to expose those capabilities. I also heard that you have systems of records.

You connect with APIs. Right? And the business that we are all in, we do have multiple systems of records. So do you have separate sets of APIs, or is the same set of APIs that determine which where the policy resides and hits that system of record. Separate APIs, and so separate APIs in the sense that what we have, um, are API architecture. Northwestern Mutual is such that we've got an experience API that the front end knows only about that experience API.

That experience API might be communicating with 4 or 5 different domain APIs. That is, figuring out where that policy resides and make that call out to those systems. So it's frictionless for the end user. Um, but there's multiple APIs aggregated back up into a single experience API. Okay.

Thank you. All right. Well, thank you all for having me..