PegaWorld 2025: Revolutionizing Claims Processing: Primerica's Customer Service Transformation with Maantic

PegaWorld 2025: Revolutionizing Claims Processing: Primerica's Customer Service Transformation with Maantic

Have the opportunity to just give an overview of Primerica. So Primerica Life Insurance was founded in 1977 as a financial services company. We're located in Duluth, Georgia, which is just north of Atlanta. To date, we have more than 5.5 million lives that are insured through our life products. We also, as far as the claims operations is concerned, we average about $4.9 million in payments per day. Our contact center for claims takes an average of 135,000 claims calls per year. That's for claims setup as well as claim status calls. In addition to that, we're very proud of some of the industry recognition that we've received over the years, including from Forbes and USA today. And one of my personal favorites is being yet again nominated as a top workplace in 2024.

So outside of those stats, Primerica is not unique, as with a lot of you guys, as far as claims is concerned, dealing with legacy systems, homegrown systems and, you know, really striving to try to modernize those processes. You know, we just left a really awesome session talking about using the AWS transform. And that was it really felt like they were speaking to us, going through that journey from, you know, our legacy mainframe system over to an option like Pega Customer Service. So just wanted to give you guys an overview on that before we go further.

Now, as far as transforming our existing platform, Swagata, do you want to talk us through some of the challenges that we faced from the Pega COE perspective at Primerica?

Yes, sure. Thank you, Linda. So why did we choose to transform this experience and the platform that we were hosting? The original customer service, it was a legacy platform, which was good when it started. But as we modernize and as we get into our modern world of things, there were challenges that we faced on the homegrown software. There were multiple handoffs between claims and payments and all the agent processing, the conversations with the customers and all of that and the average handling time was really delayed over this process.

Now this because due to this delay, there were impact and not only impacted customers, but also the morale of the agents were kind of going down because the service was not as much as they were probably putting in in terms of effort, the ability to adapt quickly, to adapt to situations and changes, changes in the industry, changes in how customers perceive things, how the agents were able to deliver things, all of that were severely affected. And it was hitting our business platform for that.

So based on that, that's where we wanted to start achieving better KPIs. Better handling of the data, which was on mainframe, which is still in mainframe, but now we have a better process of accessing that data and maneuvering the data with the Pega Customer Service application. So accessing those data and then overall having a faster call resolution time. These were key factors, key KPIs, which we wanted to significantly improve on. And that's why we took up the next step of let's go and transform this.

And then why did we choose Pega Customer Service? Belinda, do you want to start off with that?

Yeah, sure. So we decided to go with Pega Customer Service specifically because of this success that we'd encountered rolling out the Pega claims platform back in 2020. So with that application already being in place, like Swagata was mentioning, a lot of our customer service reps, you know, they were accustomed to using web based homegrown systems for supporting the policy questions that they would encounter. But when it came to claims, they would have to pivot over to the mainframe system in order to get those stats.

So with Pega Customer Service or I'm sorry, Pega claims application that was already implemented, we were able to really reuse a lot of the existing APIs that we put into place to make that integration go a lot smoother. Since we were using a lot of the same data points, instead of that CSR having to pivot, as I mentioned before, across multiple different systems and applications. We were able to really hone in on the customer 360 platform that is afforded by Pega Customer Service to allow them to have more of a seamless experience when servicing our clients.

In addition to that, we were able to integrate knowledge based articles there, which really helped with the onboarding time for any of the new or less experienced CSRs, so that they could easily just type in a few key words and return consistent results each time. So those were some of the things that really helped us decide to go this route. It just really seemed like a no brainer in moving from Pega claims to our POC with Pega Customer Service specifically for the claims platform.

So a key feature of Pega, as we all know, is the providing a unified platform to interact with different systems across legacy, across APIs, across modern systems, distributed all of that. So that was a very important driving factor because we already had invested in the platform and it had such, you know, incredible capabilities, particularly in customer service as a framework. That was definitely a driving factor to choose that.

In addition, we of course, the knowledge management was a factor. And the other part, which was interesting to us, is that the customer 360 view, which was offered by the framework, which is not usually available in a lot of other systems. So that was very, very interesting. And when Maantic was able to demonstrate all the details of it, that made a lot of a difference. The reps, the micro journeys that we were trying to adapt to, those were also a key factor in making a choice of the tool and of the platform in terms of how we're adapting to the next steps of the technology and how we expect that the framework would be responding to.

We would, how about you take us through the journey that Maantic had with us?

Yeah, absolutely. So I think Belinda talked about a few of the things that the modernization journey that we had with the claims operation. So Maantic was the site partner for Primerica for more than three years. And initially, the biggest program that we did was the legacy transformation, where we did the claims operation modernization for both US and Canada, both the region and then customer service was an extension to modernize or replace their existing homegrown platform of customer service and bring Pega Customer Service into it and increase the efficiency of the CSRs efficiency.

So but the project was complex in the sense there were three aspects of it. One was the Avaya ACC platform that Primerica had. It was not out of the box getting connected with Pega. Second was the complexity of the business scenarios. So we had like you think of 30 different callers calling from claims operations. You have three different claim types, and then we have US and Canada variations across the region. So that was overall there were 2000 more scenarios, business scenarios for that. And the third was there are a lot of integrations which were involved to come up with a unified view because it has policies. It has claims and everything.

So what we did initially was doing a proof of concept with Aflac. So we built a custom solution working with the Primerica architect so that the Pega Customer Service can receive the call and have that interaction with the SEC. And then as part of the POC, we not only just did the technical feasibility of the Aware, but we also built the 360 platform with the unified view. And also we did not just do the unified view for the claims, but we did the view working with business for the entire life operations so that it can be scalable. Right. Because tomorrow you can have policy servicing, you can have underwriting. So the platform, the foundation that you're building, it should be able to scale and support all the different micro journeys together. Right. So that was the thing we did. And we were able to reuse that entire foundation layer when we got into the implementation.

Now coming to the implementation, what we also did, which is a little bit unique, was we deployed resources who had specifically implementation experience of customer service because that helps in asking correct questions. Right. Because there's a little bit of difference when you do the customer service implementation. And we also use the situational Layer Cake of Pega because as I mentioned, there are many APIs. So in Primerica, as part of the modernization journey of claims, we build those APIs into the enterprise layer. We build the APIs into their BFF layer, the division layer, so that it can be reused or even if cannot be reused, it can be modified quickly after talking to the integration stakeholders. Right. So that was the expertise that we brought in when we started the implementation. Right.

And the other important point was doing the, you know, getting the business early into the discovery of the elaboration session. This is very important. And that was one of the key success factor, I would say, because when we start with the business, we try to understand their pain areas where we can do automations. So for example, if I take an Avaya, a call is coming, right? And there is a policy number that somebody has entered while doing the call. So why can't we use the policy number and do an automated search. Why can't we use the region that is coming from that our input and do an automated search in the US or Canada there is a customer intent, sometimes a customer ask for a claim inquiry or a claim setup. So use that input and provide a suggested action for the agent.

So these are all small small things that helps in automation and business. Was also happy. It was more aligned to their vision what they wanted to achieve. And the integrations were, as I said, like it was seamlessly orchestrated over the micro journeys. And it was a Pega, Center-out architecture that we used for which the claim setup or the micro journeys like claim inquiry that we built out of the modernization were actually reused here. And the foundation layer reuse actually helped us to get the Canada Go live within two months after us.

Now the fourth point which is most important was the testing because as I said, when you have the verification steps right, for different calls, a beneficiary calls or an attorney calls, and then you have a different claim types and there are different verification steps. So what happens is if there isn't any change in one of those steps, you have to do a regression testing. And because you have like those 2000 different test scenarios, if you want to do a manually test all the scenarios, it's going to take time.

So we created a, you know, a template based, Excel based template for where it can be visually tested by the tester. And that helped to reduce the overall testing cycle by 70%, because it was all script based. And any change was tweaked into the script and it automated the outcome so we could actually see what passed and what failed. So this was one of the best, I would say the testing cycle, although we had the elongated UAT cycle for there because in customer service, what makes more important is, you know, getting business hands on early, what you do in the case management and others is like, you know, once you do a typically you do the development, you do sit, then you hand off to business during the UAT.

But what we did was we brought the business users early so that they know the navigation. So the change management was pretty easy because for the CSR applications, right? Any change that happens on the UI field or anything that makes time for them to get accustomed with that. So we were able to bring them together into this journey early, and then they were able to navigate properly. And when it went to production, actually, they were all, you know, very quickly adopted to the system. And after three months of the production, we had less than five defects. And what also happened was because of that reusability and the scalability of the application, when we did the Pega upgrade from 8.7 to 24.1, it was with zero issues.

So I think, you know, if I have to wrap it up, it was basically the major highlight was the collaboration with the business Primerica it. And again, thanks for that and us doing this entire journey together. And that was really awesome.

Yes, definitely. To second that part. A key success metric for us was the fact that when we were in production, it's actually two months and less than five defects in two months. So that was a very important piece. Which typically having done and seen customer, Pega CS implementations across my career, this was one of the best I have seen with literally so low number of defects. And also the upgrade was absolutely seamless. There was only one issue, which is like a really minor UI issue. So kudos for that. That was a very important milestone for us. And we actually didn't realize we would achieve it until we actually achieved it. So that was a very important, in terms of other success factors and how we got there.

One thing which we did different in terms of how we conducted our UAT and training the users, we did invest a lot of time to go through that UAT cycle. Typically a UAT of for this size of a project would be limited to a maximum of four weeks, but ours extended to somewhere around 6 to 7 weeks. And we spent a lot of time with dedicated users, being trained during that time and also working through UAT cycles hands on during that time. And while on the face of it, it was an extended period of time and it's not generally thought of that. Oh it's taking really long, but that paid off for us, big time because our production was so seamless after. I mean, we literally we just rolled it out and we could almost forget about it and hear only good things.

Also, our, we had a roll out time for us for about six, about eight, eight months to get it to production. And the Canada, which is the other region variation because of the hugely reusable components that we built together from the COE and Maantic, the way that was conducted by the Maantic team, that was also very important in terms of realizing a reuse of that and getting Canada out within two months of the US rollout, which is which was a big win for us, as Belinda would tell you in a second.

In terms of the training, the users, Belinda and her team, they had a lot of users, put in extra time, put in, set aside some of their existing priorities and focus on learning this training into a web application from so far a mainframe application, COBOL based black screens, black and green screens. So and that was another key piece of work that we put in. But they did pay off a lot. And finally typically you would not have such long UAT. So because they had to resource it in a very different way. I still don't know how they did it, but Maantic was really very supportive in the way, it did not affect our costs. So that was, a key factor for our success as well in terms of elongated UAT.

But, Belinda, would you want to talk about how we had our outcomes and we were so happy about it?

You're giving me the words there. So from the operations side of things, I definitely want to call out Maantic for being completely supportive throughout this journey. Cyan and their team were completely flexible. And as both Shane and have pointed out, we did have an extended UAT period. But I think that a lot of that had to do with the user's comfort levels. So it's not necessarily that the requirements or anything was changing, but when we're dealing with, you know, the CSRs who are essentially on the front lines, you want to make sure that they are comfortable with this system and that they're not fumbling around, you know, with the customers especially, you know, with some of the sensitive calls that, you know, they have to take. So it really was about getting to the point to where they felt comfortable involving them up front in the process, making them feel like, you know, they in a sense, were architecting the design here. That completely showed here.

Just wanted to call out, like, the way that our process works, we basically segment it in as far as three different types of customers. So we have our external customers, which are our beneficiaries or policy owners that they may encounter. We have our service servicing agents that are out in the field, assisting with the beneficiaries. But we also count our CSRs and our home office users as customers as well. So with myself being, you know, in implementations, but also having an eye to the operations side of the house, we have to make sure that our internal customers, as well as our external customers are being handled in the best way possible.

So one of the things that we did that really contributed to this success as well. Was that as part of our modernization journey? We started multiple micro micro journeys here along the way since 2020. So in addition to having the Pega customer Pega claims platform up and running, we did roll out a self-service portal for our servicing agents that allow them to set up claims, or to check the claims status on any of the policies that they service. 24 over seven. So even prior to rolling out Pega Customer Service, we all already were able to reduce the call volume by having a 30% or more adoption rate, from our agents to help reduce that call volume so that our CSRs can focus on the more detailed calls it needs.

So we did have, that option out here with the Pega workflow. We were able to introduce, an actual workflow for claims status. So we didn't have that option previously, but we were able to incorporate that into the workflow with great success in the feedback from those end users. Also, one of the things that I wanted to point out that, Shane, you were talking about earlier, the fact that we with this platform, we have the customer 360. So with just just a toggle, the CSRs are able to not only see, the claim information, that that particular caller is referencing, but if there are multiple claims on that policy, if there are multiple policies for that insured, they can seamlessly transition back and forth without having to type and search it, or to go outside of this platform so that that really, really has contributed to the success. And, you know, the, the accolades from from the actual end users throughout this process.

And just to touch base on the point that you mentioned about the modernization of the claims. So that really helped. I mean, echoing to what Alan today talked about in the keynote, right. The Pega's inside out architecture. So what really helped was building that micro journeys during this modernization and then making sure that those just expose it to the channels. So and that was done pretty quickly, right. When we actually published it into the peo like the, the web page, it was pretty fast. And within two months and we started getting the ROI and then it was the the call Pega call right. And it was also a big success. So the micro journey and the Insided architecture was really important. And that helped. Of course we had the situation Layer Cake for the region based variations.

Yeah, I think that, you know, ultimately what it comes down to is, most of the time is spent with making a decision. But once a decision is made, as far as how we want to plan out our roadmaps, for continuing to modernize, we're able to get to market fairly quickly with those solutions.

All right. So so what does our future hold? Right. So what does, we have been, we have done our claims application, and then we built the CSR application on top of it. And that is working pretty seamlessly right now, across two regions. What do we look for next is to introduce predictability of this, overall application. So bringing in, CDH into the mix, to be able to, generate predictive texts, generate predictive data analysis, overall decrease, increase our first call resolution time. So, so, so that we can, have a quicker resolution overall.

Average handling time has already been reduced quite a lot. And we want to get to a even better position. Overall we have unified portals, so nothing is getting dropped. Nothing is really, we're not relying on any more manual work in those pieces of, areas. The speed to market has increased a lot because of these transformations, and we are looking to, take it further along if we are going into new geographies or new channel adoptions, we do want to leverage our the Pega Platform capabilities, particularly since we have done an upgrade very recently, and that platform has so much to offer, as you have also heard from Alan and everybody else today, it does have a lot to offer, and we want to make use of whatever the platform has to offer in its best possibilities so that we can serve up a better, better customer service to not just so.

Our agents are also our customers. So we serve it up to the agents, and then they in turn serve it up to the end customers. So it's like a chain process which would be coming through. So that's what we have, in our roadmap and our landscape. So hope we get there soon.

Absolutely. All right, Sean, you want to go take us through the future model with Maantic here?

Yeah. When we talk about the future model, it's all about AI as we heard. So I, I, I. But yeah. So from the customer service perspective, when we talk about the AI, how we can help. Now when we talk about AI, it is not just a generative AI. We have Process AI, we have CDH and then we have generative AI. So I'll probably, segregate into four categories, right.

One is the AI assisted or AI driven agent assistance, where we understand, from the enormous amount of data that we have on the customer. Right. Including the demographics, the past interaction history, the products available, and everything. Do the next best action for the agents. That really helps. The agent doesn't need to, you know, do the brainstorm with the customer and come up with what is the next best action.

The second part is use generative AI on the conversation. So the conversational AI, be it through a call or chat when the transcript comes. Analyze the transcript. Do a summary. Determine what is the next best action for that. Right. And you can deploy it in any channel be it in chatbot, be it in email bot. So all these virtual assistant AI can do wonders.

The second part of it is the, you know, the AI driven self-service. So I think the, the paradigm of, you know, the understanding is when it is not about, the human interaction, that it has to be always a human interaction. And whenever there is a straight through processing capability, we will bring AI. But it should be the other way around, right? So the system should always think of automation when there is a complex or an exception path, then goes to the actual agent so that the CSR or the agents, they can use their valuable time doing more complex work and not these things.

So today we saw the demo how a digital chat can you know you have the AI to process it, understand the customer intent and not only just, you know, categorizing or saying that this customer is looking for that, but taking the action on it. So it might create a case in the background. The customer might, I mean, through the conversation, it might understand you need to also have a task or a follow up task or something. So that can also be done. So this is more of self-service where reduce human intervention as less as possible.

The third option is we often miss out it, but it is also the process optimization. So when we customer is looking I mean for an interaction there is an outcome and there is an action for that right now. So when we talk about an action there is a process that gets triggered. Now how we can optimize the process when we talk about the routing right through an email bot or something, there is a data comes and how we can use that intelligence of AI intelligence to route it in a proper fashion. So put the intelligence in the routing, understand what can be the process bottlenecks. Learn from there and advise to the agents or change in the direction of the process. So that is a Process AI.

And the fourth thing is the CDH that even I was talking about, that is a future model with the AI, future vision with the Primerica as well, that use the CDH and bring the next best action. Do the data analytics with the predictive and adaptive model. So the predictive gives you the next best action. But when the customer takes an action out of that, right, use that as a feedback loop so that the next time that happens the outcome may be different, right. And we we have a lot of use cases for the email bot or the customer interaction. What happens is, you know, the NLP or the machine learning that that actually churns the data of the the entire email message or the the transcript from any channel. Right. The outcome may vary after few of the interaction. It determines that, you know, with that adaptive model and the learning and feedback that it might have to take a different action. So that is the entire data analytics we're going to put in.

So I mean, Pega being the AI based platform, I think there are enormous opportunities for the agents, for the customers, and for obviously the CSRs who are handling the day to day activities.

So while we do have such an incredible platform, which is, very AI enabled right now, we do believe in a crawl, walk and run approach where we, we are going to look at our predictive and analytical and process models first before we get to a generative, landscape of that.

So with that, I really would, on behalf of all of us, we would like to thank Pega for this opportunity. And thank you, Carla, for making it happen. Thanks a lot. Thanks, everyone. Thank you everyone.