In this session, we will discuss how to:
- Reshape your aspirational claims journey.
- Improve straight-through-processing potential across commercial and specialty lines to drive down costs.
- Orchestrate work between multiple disparate systems and teams.
- Decouple core system architecture to deliver faster time to value.
Chirag Jindal (00:10):
First of all, thank you for the opportunity to hear the ServiceNow perspective. You must be wondering why ServiceNow on stage, talking about claims, talking about underwriting is in ServiceNow, the ITSM platform ticketing platform. I am here to kind of dispel that myth over the next 30 odd minutes with Eric and John. My name is Chirag Jindal. I lead the insurance go to market for ServiceNow and in my role I have the opportunity and the privilege to talk to carriers globally. And even when we look at our own portfolio, more than 50% of our customers are using us outside of IT for IT, using us in underwriting ops, claims orchestration, customer service, local automation, employee experiences, and so on and so forth. So what does ServiceNow have and how do we do it? I will quickly touch upon that for the next two minutes.
(01:17)
The best way to think about the ServiceNow platform is we are a complex workflow orchestration platform. We have modular composable capabilities that have been productized for insurance and we apply those capabilities to solve and end-to-end claims journey. When you think about a auto physical damage claim, which sounds like a simple claim, it becomes a bodily injury claim because you had a whiplash reported and then a week later an attorney called and becomes a litigation claim with sub elements. that is the complexity we are solving in the marketplace. Similarly, in underwriting, a Bop policy is a Bop policy, but when you apply a surplus liability endorsement and slap on a Bop, complexity of that underwriting experience is what we are solving in group benefits. We see a lot around evidence of insurance status checking census data, how do you put it all together in a fragmented technology landscape and take that journey end to end. Those are the kind of problems we are solving for. So how do we do it?
(02:26)
This works, this is a blank side, it is a buildup. Let us take an example of a claims technology stack, right? You will have your systems of record, they might be on-prem, they might be the legacy stack, they might be cloud. You have data and analytics layer. What you are really solving for is solving for your insured, solving for the policy holder. And at the same time you are solving for the claims professional engagement layer, the appraisers, the adjusters. You have your Insure Tech and you have third party data. It could be statistical models, it could be gen AI, but what is happening is when you find that the slates are damaged on your roof of a customer,
(03:10)
Images are being manually sent over emails uploaded to core platforms, uploaded to databases, there is no real time orchestration of that notification to the right personas. The parties involved in that claims journey. That is primarily because it is a tightly coupled architecture. It might be a monolith, it might be a fragmented landscape. ServiceNow is really focused on where the system of action, we sit on systems of record and we are abstracting logic, ingesting logic and pushing that logic up the experience layer to the claims professional or to the policy holder. I threw a few nebulous words there. System of action, usually coupled complex workflow orchestration. I will spend the next 25 minutes with Eric and John going through what we actually mean by that. Before we do that, Eric, John, you want to introduce yourself?
Erik Roen (04:10):
Sure, thanks. Can you all hear me? Alright, great. Thanks for having me. Erik Roen with Travelers, I have been with the company for 25 years and with the unique convergence of data and technology and ai, I have a unique role within the company both leading the technology organization for claims, so all the technology supporting our 13,000 claim professionals. And I also have accountability for all the analytics that we build to support the entire claim lifecycle. So all of our data engineers, all our data scientists, all of the data that we use throughout the claim lifecycle. So spending a lot of time both with on the business side of the house, building out all of our AI capabilities and then with our technology partners, the implementation and supporting of it.
John Ball (05:03):
John Ball, I look after what we call customer and industry workflows, so that is customer service management, field service management, and then all the industry specific solutions that we build, including insurance, banking, telecoms, etcetera, come with the company about three years.
Chirag Jindal (05:21):
Alright, I have a few questions. I will start with Eric. It claims, when we think about claims, it is really a moment of empathy. It is a moment of distress to the policy holder who is calling and there is a lot of discussion around no touch claims, right touch claim. What do you think about the balance between no touch straight through and right touch and claims?
Erik Roen (05:44):
Yeah, I think it is a great question to start with because I think for insurance companies, a lot of times, whether it is the customer, whether it is a claimant, a policy holder that the only time they interact the company may be when they have a claim and it is really where that promise comes to really comes to fruition. And so I am incredibly proud of everything that our claim professionals do on a daily basis of striking that right basis of empathy, a real understanding of their craft and being there in a very stressful time in a situation. And I think those things are really important when we think about lower or no touch claim handling of what are some of those kind of guiding principles that we need to keep first and foremost in the front of our mind as we are thinking about transforming the claim process. And so it really, there is really three aspects of it.
(06:51)
I think the first is you always have to focus on paying what you owe based upon the policy coverage. It is our accountability to pay what we owe every single time that is not paying more, that is not paying less. And that is a really important tenant to remember when you think about introducing changes to the claim workflow, whether they are no touch or low touch or just automating parts of the process even on the most complex claims. So it is really ensuring that we are paying what we owe right up front. The second piece is provide a great experience but not at the detriment of not paying what you owe. So we could do a lot of things to speed up the claim handling process to maybe delight the claimant and give them a really great experience within the claim process, but we could unintentionally end up underpaying or we can end up overpaying.
(07:59)
So again, that is the second principle you got to keep in mind. And then the third is we want to do these things and the most efficient and effective way internally, but not at the detriment of providing a worse experience for the customer. we are not paying what we owe. And so those three things are sort of the mindset that as we are thinking about transforming that claim handling process, we kind of keep in the front of our mind. And so some other things that become really important to that, obviously understanding the customer journey and what's important to them, having a really robust experience design also becomes really critical to really understanding which of those activities do you really need a human involved that are value add or needed and which aspects of the process where you are not really adding value by participating or may not be needed. And so those are the ways we are balancing it as we are going through this transformation.
Chirag Jindal (09:04):
Thank you for that. And I want to touch upon what Deepa said about being agile, but about being nimble, driving value, and we talk about a loosely coupled architecture. What does loosely coupled architecture mean to you and how does it help with agility and nimbleness?
Erik Roen (09:22):
Most of the carriers out there, we've been around for a long time and so we have a lot of legacy systems and some of the challenges that we have, I would say from a claim perspective is our current platform. it is a bit of a monolith, it is a very tightly coupled architecture where that system of engagement and that system of action and that system of record has really gotten pretty tightly coupled over the years. And so when we think about transforming parts of the process, you can just imagine what I describe as a bit of the coral reef syndrome. You don't know what's underneath the water level. And as you start to pull things out and you start to try to plug new things in, that could become really complicated. And so what we are really focusing on is a more loosely coupled architecture as you just described in the slide, that really sort of separates those key components of that work of that architecture.
(10:25)
So that system of engagement that really facilitates and provides a different set of experiences for that customer or claimant across a variety of channels that is very personalized, that system of action that really allows us to leverage whether it is our AI models or our rules that can orchestrate and automate parts of the process, whether they are in a no or low touch or even just parts of the process that may be on a more complex claim, you are going to need to have a more senior claim rep, get involved in certain parts, but not all parts of it. A system of flexibility, which is basically just our a p I layer that really kind of allows us to respond very nimbly to different business conditions or changes, but also allow us to interact in a lot of different ways both internally and externally. And then obviously you have things like our system of insight that will continue to develop and build, deliver all of the descriptive and diagnostic reporting, but also that predictive and prescriptive analytics that we are looking for. And then you still always have that system of record, but that system of record and our operating platform plays a much smaller role in that new ecosystem because we've been able to decouple parts of it. So it is not all tightly coupled together, but a little bit more loosely connected.
Chirag Jindal (11:49):
John, anything to add on the loosely coupled?
Erik Roen (11:51):
Yes. So
John Ball (11:52):
First I couldn't agree more with Eric. Loosely coupled, that is approach. that is good up here. Yes. Well we'll find some area to debate. it is actually, it is something I see across all the industries. It is really having a loosely coupled architecture is one of the best ways to be able to deliver on the promise of both improving customer experience and either reducing cost or at least keeping a lid on cost that doesn't go out of control. And really kind of the common theme is you always see some sort of monolith, some system of record and telecoms and manufacturing and banking and shipping and logistics even in public sector. And that monolith, what happens is it is typically not super flexible. it is often legacy. It could be an old mainframe system, it could be whatever. And because we are asking that monolith to do more than it knows how to do, what you end up having is shadow processes pop up and the shadow sort of processes, they tend to be manual, tend to be unstructured.
(13:02)
It tends to be what I call swivel chair human middleware where Bobby's talking to Susie, talking to Jimmy to get the job done with sticky notes, with shared email boxes, with informal conversations, chats, phone calls, and that is typically where the customer experience falls down and it is where your costs skyrocket. Again, unstructured, it is not being fully optimized. So that is the best way that I have found to sort of solve that problem is to go with a loosely coupled architecture because not chucking out the old system of record, it is still super important, but it gives you more agility and being able to react to market changing conditions. It gives you agility to then have continual process improvement. You see where the bottlenecks are, you see where the problems are occurring, whether it is a no touch, a low touch or a very complex claim. And I, I have seen it where a large it turns out healthcare insurance provider is dealing with a hundred million complex claims a year, a hundred million. They deal with a lot more claims, the complex ones, and it is due to law business process, various things. Those complex claims require lots of coordination across systems, often departments the one and done simple request is not where the cost is and it is not where the pain is.
Erik Roen (14:40):
Maybe just to add to that, we had a lot of conversation within travelers within claim around where the future of claim handling is kind of going and we came to the conclusion pretty quickly, there is not a single platform out there that is going to do everything it we a re going to have to apply an approach that allows us to take advantage of new capabilities that may come on the market deeper. Talked about generative AI and some pretty exciting things there that we are going to want to be able to plug in and take advantage. There is also going to be things that we are going to lean into building that we want that we think are really differentiating that we want to be able to move a lot more quickly nimbly on. And embracing that more loosely coupled architecture we think positions us to be a lot more nimble in responding to either changes in the market, but also just taking advantage of newer capabilities that are coming online than if we were kind of tied to our monolithic kind of current stack that we know would take us a lot of time to figure out how we are going to integrate those things into it.
Chirag Jindal (15:50):
Yeah. Well thank you for that. I want to go back to what both and you said you kind of start with a legacy stack. You kind of start with a legacy stack and you are solving a problem of customer experience. When you think of future claims stack tech stack, what are your top three considerations? How do you think about it, how you do prioritize it?
Erik Roen (16:14):
Yeah, I have more than three, but we have an entire set of modern architecture principles that are driving this, but I think first and foremost it is got to be cloud first. We just think about, and that is whether we are building it or whether we are partnering with somebody, it has to be, we have to be cloud first because there is just so much capability that gets unlocked when we are leveraging things from a cloud perspective. There are capabilities that we can actually take advantage of. Think about just documents and the ability to pull insight off of those documents in real time to actually keep a claim in a straight through processing path or potentially to escalate it to a nurse or to an investigator or to somebody else. Those things would not probably be possible if we were not actually in the cloud. So cloud is the first one. Two obviously API, data-driven domains become absolutely critical to what we re doing there.
(17:18)
Another really important piece for us is just an event paper capability, the ability to publish and to subscribe to events throughout the claim process. We haven't quite frankly done a great job of publishing all those events that are happening throughout the claim process. And so if we were doing that and we are kind of going forward, that really I think enables whether it is other parts of the claim organization or potentially other products to actually subscribe to those events to actually decide what's that next action that now needs to be taken. Having that discipline around that publishing and subscribing becomes absolutely critical.
Chirag Jindal (18:04):
Thank you.
John Ball (18:05):
And I will add on to that both the loosely coupled architecture and the published subscribe. One of the things that I have seen across all industries is that transparency really matters. Making sure that the customer knows what the status is of the request, that all of the employees in your company know the status of the request. they are not calling you or contacting you to have a conversation. They have a request. That request gets broken down to a series of tasks needs to get executed because that is really where customer experience matters, not just the inbound request process. it is until it gets resolved. One of the best ways to really irritate customers is to not let them know where their request is On some of these, we are talking about very complex long running insurance claims and then making sure that the front office and the middle office in the back office are all in sync.
(19:03)
It makes, it reduces your costs, but it dramatically improves the experience of the customer. And crazy stat here, but the most predictive thing of customer loyalty is level of effort for the customer and their interaction with customer service. It is more predictive than net promoter score. it is like lots of different studies from lots of different big brained organizations have done this. It is literally the number one predictor of loyalty is how much effort the customer has to put in to resolving the request. So transparency is really important and it is really hard to do when you are dealing with a monolith.
Erik Roen (19:41):
Absolutely. My CISOs listening to this, I have to put a fourth in there. So security and resiliency, whether it is building IT or partnering with any of the partners out here, as I think about our tech stack going forward, that security and resiliency becomes absolutely critical.
Chirag Jindal (20:02):
Absolutely. I think that is very critical. A kind of through system of action. When we were talking about it, you referenced it solving for customer experience, you are solving for your adjuster experience and you have your stack. How is a system of action allowing you to solve for those experiences?
Erik Roen (20:23):
And so John kind of alluded to it, when you just think about the claim process today, there is a lot of activities that happen that we can lose sight of, whether we may send it to a body shop and they are off doing something or may go over to a SIU investigator or it may get assigned over to a nurse to do something and there is a bunch of activities happening there or maybe somebody in operations has to, they are running some reports and things like that. While we may have a platform that people are working to support some of those things, there is a lot of activities that have the opportunity to go radio silent for a period of time. And that is both on the claim professional side of the house, but it is also on the customer side of the house. So think about it may be in their court to be going and getting an estimate, having a contractor out and maybe we haven't heard from them for 14 days and where are they in that process there.
(21:36)
So when you think about the future of claim handling and if you want to think about low or no touch claim handling, you have to have a pretty good understanding at all points in the process. Where is that claim and who has it and where is it stuck? And that becomes really critical if you are then going to start thinking about making changes to that process. And so we are kind of the system of action. I really don't think you can fully transform that claim handling process without having a really good appreciation and orchestration engine for that customer journey. So things that allow you to, that are configurable for all types of claim processes, the ability to have intelligent assignment of those tasks or claims, the ability to automate certain parts of that process, the ability to do simulation of different processes that you want to change, that is think of how much time we do today with time studies of saying, Hey, if we make this change to the process, how much time are we going to take out of that?
(22:51)
That can be really hard to do today. So those things become really critical. You think about work assignment, if we are start starting to think about automating certain tasks or entire processes, there is people doing those things today and we employ a lot of folks that are really trying to make sure we have really robust workforce plans. We have enough individuals with the right skills to handle those types of tasks. So the ability for workforce management and workforce kind of planning become absolutely critical. And I think of all those things as being really, really critical components of a system of action.
Chirag Jindal (23:32):
John, you speak to customers about system of action beyond insurance. How are they thinking about it? What value do they see from that concept?
Erik Roen (23:43):
It really
Chirag Jindal (23:43):
Is
John Ball (23:45):
Taking the same exact talk track and then adapting it to the industry specific processes that they are faced with. I mean, at the end of the day, I talk to chief customer officers, VP of customer care all day long. And without exception, everyone asks me the question, I need to improve customer experience. I either need to reduce cost or keep a lid on it. And in order to do that, a system of action is absolutely essential. I will add that. I would argue it is also important that the core technology, whatever core technologies you are using, you want it to be as low code, no code as possible, or at least not writing proprietary code. And the reason is what Eric just mentioned about continuous process improvement. You want to find out where those bottlenecks are. You want to find out where a specific business process can be improved.
(24:38)
If you are going to bare metal and writing custom code, it is really hard to do process mining if you've got a more content driven approach. If you can model your business and your business process, like claim types, I mean, sorry to get geeky here for a second, but having types of claims, guess what, when you are dealing with a car insurance plane, it is a different process than a house insurance claim. So being able to model that through content and configuration then allows you to do the process mining. And usually what happens is when people see the result of process mining, they then say, oh, well that is obvious, but it is only obvious after you see it. And you have literally tens of millions of dollars of savings and customer improvement process that is enabled through that. So I just think that having sort of low code, no code ability to model the business, it is important for the continuous process improvement. And it is super important for agility, which we've heard about a lot today. You never know what's going to happen. You never know when there is going to be another major event and you need to change your business process without a two month or six month or 12 delay.
Chirag Jindal (25:50):
I have time for one more question and I will pass. If I step into the shoes of an insurance executive, I see two right in front of me and I have two paths, I can modernize my entire core or I can think about driving time to value faster, easier. How do you prioritize? What do you think about time to value? Why is it important and why is business knocking at your door all the time?
Erik Roen (26:14):
Yeah, yeah. One thing I actually, having grown up on the business side of the house within travelers, I have seen kind of how some of these conversations have been brought up previously that was more from the lens of it was a modernization conversation and technology organization was speaking to the business really more from the standpoint of we need to do it to modernize. And the approach that we took from a claim perspective, spent a good year and a half educating the business around what our current platform looked like, served us really well, what were some of the constraints, why were some of the things going to be really hard, if not impossible as we thought about how we wanted to handle claims in the future in that current stack. And then also spending a lot of time on educating them on what a loosely coupled architecture looks like, right?
(27:26)
All of those components that we've talked about today, we spent hours going through with the business leadership, let them actually understand it, ask questions about it and put it in context of how that would actually enable them to deliver on some of the business capabilities that they were looking for. And I think that went a long way when we got to some of those conversations that were really hard around asking for additional funds or shifting some of the investment portfolio from one value stream to another. They had the right context and that became absolutely critical for that. I think the other thing that we really also spent a lot of time doing was, if you are familiar with just steel threat exercises and it wasn't about integrating or implementing a single technology within the stack, but we really shifted the conversation within the tech organization to say, this new ecosystem, we are actually going to be testing out a number of different capabilities and those capabilities have to be able to work with each other.
(28:41)
So ServiceNow and a whole other things that we were focusing on, it wasn't just a conversation around testing and making decisions around any one individual, but it was how all these things were going to interact in this new ecosystem together. And you would think, well, should not that always be happening? But there is a little bit more of a subtleness to it around the mindset shift that had to happen for everybody to think differently that we weren't just buying something new and trying to plug it in. But really building a new ecosystem that would really position us for that did not all have to be there day one, would allow us to extend it and scale based upon the speed at which the business wanted to go. Yeah.
Chirag Jindal (29:28):
I think I am getting the 45 second warning, so we'll pass it to the group here. Any questions from the crowd here? Is that okay? Any questions we are taking or are we off on time? Alright, thank you. Thank you.