PegaWorld 2025: New York Life Transforms Claims Experience with Pega Customer Service

PegaWorld 2025: New York Life Transforms Claims Experience with Pega Customer Service

Okay, so this is Sukanya Rajasekaran. I'm the delivery lead on claims and money movement experience at New York Life. And I'm super thrilled to be here in front of you all to talk about our claims transformation journey with Piyush. Hi everyone. I'm Piyush Shrivastava, I'm client partner for Virtusa and I take care of Virtusa relationship with our key client, Neha Clive. Equally excited to be here to present this story jointly with New York Life. So at New York Life, every interaction that we have with our client, especially during claims processing, it's a moment of truth. These are not just transactions. This is where our promises become real.

So we had a question for ourselves like, why can't we make these experiences more intuitive, more digital, more modern, and more empathetic? That's when the transformation really began. And this transformation is not just modernizing a technology or fixing something that wasn't working. It's really redesigning the way we wanted to support our clients and help them. And that's when Virtusa came in. So, as Sukanya mentioned, when New York Life was looking for this engagement, we came in with a lot of expertise, both around Pega transformation and claims implementation. I'll give you an example of an implementation that we did in past AIG. One claim I don't know how many of you have heard about it, but there is a platform from AIG that serves 45 countries. And we heard about the Situational Layer Cake today morning.

It uses all of that to serve those 45 countries. So with that, and we were the implementation partner for that, and it is regarded as one of the biggest, most complex claims implementation in history of Pega. Having done those kind of things, we were ready to come in and provide both the domain knowledge and the technical knowledge to help New York Life to transform this project from a more of an IT implementation to a business transformation, and help New York life to achieve the business goals they were looking for. So anything to add before we move to the next? Sure. Piyush. One thing I wanted to add to the beginning of our story is at New York. Life transformation wasn't a buzzword. It's a responsibility we had.

Innovation must be very thoughtful for a company like us that has 180 year old legacy, it must be rooted in purpose. And that's the mindset we brought into the transformation journey. Yeah. So this is what we are going to cover in next 25 minutes or so. We'll talk about the starting point. How was the legacy claim system? What were the challenges with that? We'll talk about how did we define the vision of the new claim system. What were the things that we were looking forward in the future state system?

We'll also talk about how did we incrementally build the whole system. And then lastly, we will also talk about how what are the benefits we are seeing from this new system. So these are the things we'll be covering. Moving on. Quick intro about Virtusa. Those of you who haven't heard about Virtusa, we are global leaders in digital engineering and technology services. It's Virtusa is privately held. We have close to 35,000 employees in over 25 countries. And one thing I would like to call out here for Virtusa is our engineering first mindset.

That's what you see on the logo on the right hand side. Now, to explain that, I'll have to take you to the history of Virtusa. Virtusa didn't start as a services company. We started as a company that was helping product companies to develop the products. That's how we started. And we still carry that product engineering mindset in our DNA. So when we are presented to a client problem, we look at that problem from an engineering lens. We don't want to just solve it. Immediate problem.

The immediate thing that client is looking for. Want to design a solution that is scalable to the future need. And that's what the engineering first mindset does to us. So now moving on to our product credentials. We started working with Pega 23 years back in a similar fashion as product companies. We actually are in the initial days, we helped Pega to build the Pega product Prpc Process Commander and some of the frameworks like customer services. Our teams were involved in building them. Now Currently we help close to 200 plus clients across the globe. Implement Pega projects.

And even now, today we are very closely aligned to Pega product engineering and innovation. I'll give you an example of that. We, uh, last year, February Pega announced Blueprint. And that was like the the innovative platform using GenAI and everything. That's what Pega announced. And last year, June, we won the award from Pega as a Blueprint partner of the year. So within four months, Virtusa was able to ramp up and also show to Pega that how what kind of a value we are able to bring on such new platform. So even today we are very much aligned to Pega engineering and innovation. So that's kind of where we are very different from the other service providers.

Moving on. Before I pass it on to Sukanya to talk about New York life, I'll just give a quick brief about our relationship with New York life. We've been working with New York Life for 15 years, and during this time we have done numerous Pega and non Pega programs for New York Life. We have done close to eight major programs for New York Life before this implementation. This is the ninth and we just started another implementation with a group which is out there on the 10th implementation. Implementation. So we are in double digit on Pega implementation at New York Life now. So over to you. Yeah.

So NY, the New York Life Insurance Company, that's the largest mutual life insurer in the United States. And the fortune 100 company. Our company's strength allows us to invest in the long term value to our policy owner. The transformation reflects the philosophy. The journey that you're going to talk about reflects the philosophy of creating meaningful and modern experiences, while we preserve the client's trust in us. One. Have you ever built a car? Anybody in the room? Have you ever built a car?

Not the toy car. I'm talking about the real car. Piyush. Have you. I have driven many cars but haven't built any. Come on. Yeah. So I know that must be a very odd question to ask. Like, have you built a car to all the technologists here?

But reimagining claims was something similar to building a car. It's not just like that. We snapped all the parts together to make one. We started with a bold vision, and then we assembled the high precision parts together. Then we brought in the expert teams to work together. And finally we put put that into extensive tests before we brought it to the road. So what we have right now is a high performance machine with people at the center. And where did we start? We went to the next slide.

Yeah. Where we started. Our old claims system was a legacy system. It had a lot of mainframe dependencies, siloed data, manual paper processing, a lot of transactions, siloed, inefficient client correspondence. And our service professionals had to toggle onto multiple different screens, multiple different applications to get to an answer. So our goal was to unify the claims experience and provide the necessary tools to our CSR so that the agents, beneficiaries and the clients get a better solution from us. And I can bring this to life with an example here. So this is our old legacy system. You can see the green screens multiple applications.

So when a client call comes in what happens is a CSR attends the call and we send out the paper forms for them to fill out. And while we wait for their responses, the client may be grieving. They might have other logistics to manage in life. It's so hard. It's not easy for them, right? So our CSR did their best at that time to support them, but they did not have the right tools or the modern technology to perform much better. So for us, fixing a technology wasn't a speed for the speed sake. It's really for the CSR to help and perform better during these moments. So Sukanya mentioned about how our transformation journey was very similar to building a car.

And now if we look back, it had very disciplined approach about building a car, kind of a thing for the transformation, we needed to define the vision, what we were trying to achieve. We needed to get all the parts that were needed to build that car. We needed to assemble all those parts together, and then we needed to test the system that it is ready for the prime time, finally launching that system into production. These were the five stages of transformation that we did for our claim system. So starting with the first one, which is very obvious, you. You want to define your vision. You want to define what you're trying to achieve. And that is even before a single line of code is written. You want to have that ready.

And now if you take the analogy of the car, what do you do when you are designing the car? Although Sukanya asked and none of us designed any car. But if I have to design, I will just think about speed. Maybe not. I'll think about the speed, security, safety, passenger experience, driver experience and maybe I will think about the center of gravity, centrifugal force. So all of that will come to your mind. So overall, you will want to have like the overall experience for your passenger and driver when you're designing the car. Same was with the claim system. We wanted to reimagine the experience of CSRs and the Benny's.

We wanted to provide a digital first platform with all digital capabilities like self-service. And third thing, which was most important is we wanted to streamline the end to end claims journey by. What do I mean by that? Is that all these, like Sukanya talked about going to different screens, trying to get the data that shouldn't be there. CSR should be able to just talk to the customer and answer the things they are looking for. CSR shouldn't have to go through 100 screens to do that. So we wanted to streamline the end to end journey. So that was a shopping list that we had along with New York Life. We went to the town to look at different products which are out there now.

Life insurance claim has existed for a very long time. So there are platforms that that provide that services. So we looked at some of the Cots platform. Now here some of the Cots platform were not able to meet New York life needs or some other ones were overkill They're like providing too much feature that New York life didn't need. So we looked at some other platforms and we finally selected Pega. Now, Pega was selected for two main reasons one, it's a low code, no code platform to easy to code and implement, and your speed to market is high. Second, it also provides you the complex case management functionality that is needed for something like New York Life. Claims handling. So that's how we selected Pega.

Now, once we decided on Pega, it was another step to figure out with business that they can believe on this system and this is the right system for them. And that's where we partnered with Pega to run the Claim Catalyst program. Now, those of you who are unaware of the catalyst program, I'll just put it in a layman's terms. It's basically helps you to jump start your Pega program in like A56 week cycle. You're able to see a working or rather a like a pseudo prototype, which gives you like the kind of a reference that you will be getting from the final system. So with the Catalyst, we showed it to the business and we got high fives and thumbs up from them. And with that, we were able to achieve two main things one. What is the art of possibility business? Believe that this is the right platform.

Second, business was able to visualize what they are getting. So it also gives a reference frame to business to distill their requirement in different phases based on what they saw as a prototype. So that's how we started our journey with Pega. And now this from the from the point of trying to figure out the vision to narrowing in on Pega took close to three months. Now, once we had Pega as our platform of choice, the next thing was designing all the parts of the car. In this case, Pega case ID was the first one we designed. Pega case types for all the claims journey state through processing express claims. Now in for this implementation we selected Pega customer services framework. So we got some ready made parts there.

We got the interaction driver, which is basically the place from where you can start the task and all. And we also got the caller authentication, verification, composite tabs, all those things we were able to get with the CSS framework. So that helped us to fast track the implementation. Now we stick to one thing as much as possible. Don't customize. So we were we were trying to use the out of box features as much as possible. It helps you in two different ways. One you don't have your speed to market is high because your effort is less. And then second thing it helps you is when you are trying to do upgrades later on.

It makes your journey much easier on those upgrades. So that's why we use the Out-of-box feature to maximum. Next thing to design was all the complex business rules for the adjudication process. Claims is not simple. You have to run a lot of logic to calculate the payment amount. So we use Pega decision table to do that. Now this system cannot exist without the other systems. It has to talk in real time with other system. For that we use the New York Life integration layer, which is basically of MuleSoft.

We tapped into that. However, we also used Pega data pages feature to persist data from one screen to another so that you don't have to make the repeated service calls. Now, one of the other thing that we were very cautious about is reusability. We talked a morning. We heard about Situational Layer Cake. Now our system is not as complex as Unilever, but still on the claim side, you still need to handle things like state variation. So you have a basic claim layer and then you have the state variations and things like that. So we used Pega Situational Layer Cake Situational Layer Cake. Sorry.

So to achieve that, and we, uh, we did a lot of reusable components. We built a lot of reusable components on top of it. So for example, uh, for the correspondence, we build a reusable correspondence engine which can dynamically generate correspondence during flow actions, depending on where you are in the flow, what template you are trying to use. Another feature I will say is the UI components. We develop in a very modular fashion, which allowed those UI components to get called from different flow actions. And you have to you can render the UI with those components. Your effort is saved there also. So those are the things we used. And I will say it is very important to figure out what parts you are putting in the car, but it is equally important to figure out what parts you are not putting in the car, because things like you don't want to do everything.

I mean, when I'm designing a car, I'm not thinking about the road. I'm thinking this car should be able to handle the roads. So the scope boundaries are very important to be defined. So in this case we work on a regular Pega architecture coupled with New York life nuances. And many features were kept outside. For example, policy limits claim is the only consumer for policy limits. However, policy limits are part of admin system. New York Life has six admin system and we didn't want to take on that burden, so we kept those limits outside. Similarly batch printing batch processing is outside the system.

So we took some conscious decision about what should be outside the scope of this claim system. So now we had all the parts ready. The next thing to do was go to the assembly line and assemble it. So that's what we did. Now our assembly line was agile framework. That's what we used to assemble everything together. I'll pass it on to Sukanya to talk more about it. So as you heard, the teams not only went through the transformation in business as well as technology, they also went through transformation in their process and the mindset in the entire journey. So they started transforming into the new ways of working in the agile space.

The teams were structured into high performing teams, into agile release train scrum teams, and they all collaborated with each other to break down our vision statement into key objectives and the objectives into Epics features and into smaller increments called User Stories. You may you may be familiar with that. So what they did is they took all the user stories, prioritized them, and started delivering business value in monthly releases. So what happened really was they shifted from the Big Bang releases from the olden traditional method to monthly release cycle. So business was able to get time to market value much sooner, and also the toggle features that were enabled using Pega, where the business had the flexibility to roll off the production implements to a smaller group of people, like a POC and turn it on or off based on their need. The teams also came up with a CI, CD Continuous integration continuous deployment pipeline that the Pega offers, so faster, reliable deployments. They also used metrics to measure their progress and to have good decision making and iteration. After iteration. They had some improvement goals, and they also used automation on the regression test scripts, as well as the end to end test scripts so that, you know, the manual effort on the quality engineering improved.

So that was reduced and we had a better quality product. Of all the things that I mentioned, one thing which I love the most is the collaborative one team And while culture that the team had, that's the important mindset change that they work together in this entire transformation journey. So a couple of things I'll mention in addition to what Sukanya said, we use some of the Pega features to achieve it. Achieve the outcome. Pega deployment manager that Sukanya talked about, we extensively used it for the CI, CD, DevOps pipeline. We used Pega unit test for unit testing. And now again, it's important that you figure out what are the tools that you have in your tool set and which works for you. So we looked at Pega scenario, which is basically automation suite from Pega to automate your test cases. However, we ended up using a different tool that New York Life has enterprise wide for test automation.

So you basically pick and choose what you want. Now you are taking Pega, but still based on your ecosystem. You have to tweak certain things. So that's what we did. Um, another thing I will call out is, uh, our guardrail score. If you look at it, it's more than 95%. The reason being, we stick to out-of-the-box features as much as possible. Anybody in this room who's thinking of implementing Pega once you pay for the product, don't pay so much for customizing it. So that's I think one of the things I will say, if anybody is doing a take away from this, that's a takeaway.

Now everything is ready. We assemble the car. What's the next thing to do? I mean, test it and make sure it is road ready. And that's what we did. So some of the things, the whole engineering rigor we talked about in the previous slide, using agile still applicable for this phase because you are trying to design a car which is road ready. So when you find a defect you go do your fix on that and then QA test it again. So all of that engineering rigor is still applicable, but there are were nuances that I will call out. We used the Pega toggle feature, which basically decouples the deployment from development.

So we effectively used for our pilot releases. Now, both during UAT and pilot, there were scenarios where we we saw that business is questioning some of the requirements. Now requirements were working as designed, but that wasn't something business was able to use it in the final system. So we ended up going back and changing those requirements. Now this is a very practical thing. We always write requirements. We think that we will stick to them. But finally what matters is adapt adaptation of the system whether people are using it or not. So we end up making certain changes to to the system.

We did some of the regular stuff also on the system, like performance testing, load testing, all that was done. UAT, we ran with some extensive edge case scenario testing because payment logic you can't take a chance. State variations and all. We needed to test all of that. Now, it doesn't matter how good your system is if users are not using it, your system is not good. So we concentrated a lot on the training. We worked with Newark Live training department to roll out, uh, access based role based trainings. And here also we use some of the Pega features to fast track this. We used the Pega App Studio to do some training workflows, and we also use the App Studio to do some context sensitive help that we embedded into those screens.

So these were some of the features we used. Now to give you some perspective of the timelines of how we did it. We started somewhere around May of 2023, and we decided Pega product in next three months that Pega is the platform. And then in the next three months, we released the first NBA MVP release. So although six months might sound long enough, but three months was basically from the point of finalizing the product to the delivery. And now we are on to the monthly release cycle. So that also gives confidence to business that if you are going to miss something in this release, you will get it in the next release. So that's also kind of helping our system to getting more and more adoption, and also a lot of more business benefits that we are seeing. And to talk about those, I'll pass it on to Sukanya.

This is the showroom. Ready car. Ta da! Right. Looks cool. Right? Looks cool. Modern. Great look and feel.

And this is the full circle of our transformation journey. So, right from the vision, then the design, execution and the realized business value. And what the results are here. So faster processing the cycle time reduce. That's the first thing we always wanted to look at the average handling time and the response time, like the it reduced by 3 to 4 minutes and the response time was better. And we also streamlined the CSR experiences. I was showing you the screen with multiple different applications. So nine systems we consolidated into one Pega interface. So that's a great win for us.

And also the single unified pane of glass improved the client engagement, also improve the confidence of the CSRs who were managing the clients agents and beneficiaries. And also the communication was another thing that improved the real time updates, the digital correspondences. And finally we lowered the operational overhead. So fewer errors, less paperwork, less duplicates are great wins for us. Next slide. So look at this one unified interface screen that we got with all the digital capabilities embedded. It's very structured, modern, create a look and feel compared to the mainframe screens that I showed you several slides before. So as I reflect upon everything that we did so far, the systems we built, the automation, the agility as well as integration, there is one thing that keeps coming to me again and again. So there was an old gentleman who called us a couple of months ago.

He lost his wife and he was a beneficiary thanks to our modern transformed system, especially the straight through processing, which is one of the key features that we implemented. So our service professional was able to end the call with him saying, your payment will be mailed within three business days. And he thanked her and he said, this is the easiest thing that happened since my wife passed away. It really touched my heart and everyone's heart, isn't it? You know the story. This is why we do what we do. It's not just modernizing something. It's not just fixing something that wasn't working before. It's not about technology.

It's about helping people when they are in need. And in this case, there were, like, less paperwork. Actually, no paperwork, no follow up, less repeated follow up calls. So. And that's why he said he said that. So this is why I'm so proud about being part of this transformation journey. Because it's very meaningful. It's not just coding. It's not just execution.

It's not just business transformation and the road ahead. It's just the beginning. I have to say, like everyone says, road ahead has a lot of opportunity for us in terms of deeper analytics, AI driven decision support and continuous journey optimization. We have really redesigned the way we wanted to support our clients in an efficient manner, and now we are driving forward in the modern car with confidence and purpose. Thank you so much for this opportunity. Pega and Virtusa. And thank you everyone for listening to our journey. Thank you. Thank you everyone for listening.

We can open up to any questions that anybody has, and there are some mics there if you can walk up to them when you are asking the question. The two of those. Did you use the constellations with your journey or was this on a prior version? So? So it was on the prior one. So we didn't use Constellation, but we are looking into it right now. Hello, my name is Nicole from Booking.com. Thanks for your sharing and the very practical experience which you share with us and what I'm very curious about. And I missed the first part of your session, so maybe you addressed it.

To what extent have you actually built all the possible journeys which a customer could raise or, or is there also some sort of flexibility where a representative can actually then, depending on the situation, decide him or herself how to handle the case? You can. Take it. Yeah. So so, um. We are still building some of the things in the system. So we initially completed the MVP was for the term policies, only simple things we kept first, then we subsequently moved to more complex scenarios. Now we are also enabling the annuities claims payment. So not everything was envisioned in the first step itself, but we had plans to do it.

Now we have looked from the journey side, both the CSR and the many journeys, and they are enabled on multiple platforms. We didn't talk that much because we are talking about Pega here, but we did enable them on multiple platforms. So for example, Pega is is enabling the journeys on the customer service portal also. So those journeys are getting enabled. The functionalities like for what they are getting enabled is coming in different phases. Okay. Did I answer your question? Yeah, yeah. Well the background to my question is, is that within Booking.com Customer Service we have.

It's. Hard to look at you because there are two focus light beaming onto my eyes. But go. Ahead. We have we have we have built a many very customized workflows so agents can truly kind of follow the flow in order to know what to do. But we also realize, realized because it has been so customized, it also makes it tricky because there's always exceptions to the journeys you have developed. So the big question to us is also how to strike the best balance between actually provide a guided workflow to to your agent, um, versus still having the flexibility to accommodate a specific situation of the customer, or maybe newer use cases which you haven't built for or planned for. So I will say this. Most of the Pega implementation I've seen you handle for the 90% of the stuff, and then 10% or maybe 5% is an exception, and every exception almost the same.

Somebody will look at it and then decide what to do. So I think you will save a lot of effort and money if you don't go for automation. Of those 5%, that's like based on the experience advice. Yeah, that's what I was direction currently. Yeah. Okay. Good to hear. Thank you. Thank you.

Hi, this is Sergio from Costa Rica. Thank you for sharing your experience. I have a couple of questions. Um, were you able to use the Blueprint functionalities of Pega in this first deployment that you did? How did it go? So. So, uh, as I mentioned, our first deployment happened in November of 2023. Blueprint officially was launched around February 2024. So we we didn't use deploy Blueprint for this one.

Uh, right now, since we are in active development, we we wanted to have a logical point where we can look at Blueprint. So we are looking at the annuities development on the claims processing to see if we can use the Blueprint there. So we didn't use it because at that time it wasn't ready. Now we are looking at it. Okay. Thank you. And the second one is um, do you work your your, uh, CRM operations with Pega or. And if you don't, has it been a challenge with your CSR to operate and to separate several systems regarding the CRM or and Pega for claims, or you don't have that type of difficulty? We don't.

We don't. Right. So we now if you talk about the customer services in general, New York Life uses Salesforce for that one. They use Service Cloud for that. Now actually I was talking about defining the system boundaries. This question came when we were defining the system boundaries. Should we start the initiation of the claim from Salesforce and then transfer it to Pega to handle it as a case management layer? Now, after a lot of due diligence deliberation, we decided to have the customer service framework to start that call. The reason being the the call center numbers for claims are different than the generic service numbers.

So all the service calls are being handled by by the Salesforce based service desktop, whereas the claim is like fully enabled in the Pega layer. Now we could have done starting it in Salesforce and then passing it on to Pega. Actually, we looked at the architectural feasibility of that one and we were kind of headed that way. That's when we looked at plus and minus and thought like CSS framework might be better because then you don't have to have additional complexity of parsing the data. And the service calls between Salesforce and Pega. So we did think about the overall CRM approach. We thought about. We also thought about surgically what we were trying to solve and then kind of compare and contrast what might make sense. Okay.

Thank you very much. Thank you. Can you describe for me so getting the executive buy in I mean this was a major effort across the organization. Can you talk a little about the journey of getting that executive buy in? What are the things you use to to build that case with your executive leadership? So it started with a it's it's not just the buy in. It's also the mindset. Right. It's a change.

It's definitely a change. And it's affecting people directly. But it's all for a good cause. I have to say, and it all initially started with a proof of concept. So to show something, hey, this would work for real. And then how we approach this again, as I said during my session, it's not a big bang. We started small and then incrementally added. And then we also even in our releases that we did, we made sure that everything is also manually verified so that nothing is getting impacted to our clients and customers. So only after that the POC got rolled off for many clients.

So all these things were put up together in front of the executive committee to get their approval and buy in. So definitely they were in support for the transformation journey and it paid us back with big gains. Okay. Um, another question really kind of getting more to your your product mix. So life I know that was a lot of what you do, but is it is it strictly life and then different uh either group to individual or is it like were you doing varying types of products that some are life where you're kind of, you know, one claim, or do you have multi claim systems that were also part of it? We started with life. We rolled off with life. And then of course we are still having some more life enhancements. So initial rollout we started with life and then we had some online beneficiary experience digital screens that we targeted for life again.

And then we moved on to annuities. So even annuities still we have some chunks like we are we delivered for one set of products and then we are now moving to the other set of products. And then we would move on to the payments we did for life. We have to move on to annuities. I think we have that. That's the prioritization that happened initially. Like once we broke our vision into several different key objectives based on the volume, the criticality and the impact. And as well as the tech complexity behind the scenes. Right.

So we did jot down the priorities. And then we have delivered. So so far like life is in a good shape. And then now annuities like some products are in Pega claims. Some are still working through it. And we had rolled off the experience for the online, you know, the digital screens and correspondences. Yeah. Again, we have a lot more to cover, like so many other products we have to bring into the platform. It's not simply, as I said, just snapping all the thoughts together.

It's like we have to take incremental steps here and we have to be very careful. It's a lot of risk and compliance as well as involved in these things, so we don't want to miss on those parts. Thank you. Thank you. When we talk about claims, the fraud comes into mind, right. So is there any fraud protection or prevention that has been implemented? I'm looking at a person there because he's the fraud lead and the the project project is called fraud. Yeah. So I was I was jokingly saying we should change the name to something else because the project itself is termed as fraud and I call fraud lead, and it doesn't sound well.

So I was looking at it when you just said that. Yeah, we do have a separate agent protection system. So that that has the that is also on Pega. So we, we have things going on there as well. Enhancements happening on that area to make sure that Fraud features are being detected. And that's that workflow system happens in that. So when you mentioned that it is on Pega, so is it on the same CSI framework or. Um, it's a different module altogether. It's on a different one.

So uh, fraud the way we are structuring it so the claims is more about the call comes in. There is a CRM component to it. Fraud is more like an internal. So the moment you identify this is possible fraud, you want to track it as a process and conclude it. So we have a common fraud like case management system that we are building, not just catering to the live side, but we are trying to see if we can expand to to other businesses also. But it's not directly like it is being developed at a separate system, and it is not on the CSS framework. Thank you. Thank you. I guess we can conclude.

Thank you so much for listening. To our stories.