Our latest Unstructured Unlocked podcast fired on all cylinders, as we touched on issues ranging from how to automate insurance claims processing – even when lawyers are involved – to who owns automation models, and how to cost-justify intelligent intake automation efforts.
My co-host Michelle Gouveia and I welcomed as our guest Stacey Brown, who is a lead organizer of event producer InsurTech Hartford and, until recently, head of Global Technology Innovation at the specialty insurance and reinsurance firm AXA XL. Gouveia is VP at the venture capital firm Sandbox Industries, where she likewise focuses on insurance technology. So, it’s safe to say we had significant insurtech experience on hand for our discussion.
Listen to the full podcast here: Unstructured Unlocked episode 16 with Stacey Brown
Intelligent intake: beyond the limits of RPA and OCR
Among the first topics was how to make the most of intelligent intake technology to automate underwriting submission and claims intake processes. The goal, as always, is to both reduce loss ratios and increase quote ratios.
Brown talked about the investments insurance companies have made in automation technologies including robotic process automation (RPA) and optical character recognition (OCR). But he quickly got to the nub of the problem, which is the abundance of unstructured data inherent in both underwriting submissions and claims, which neither RPA nor OCR handles all that well.
While that’s an issue we’ve certainly covered before, he hit on one element that was new, at least to our podcast: claims coming from lawyers.
“Somebody hires a law firm because they don’t want to talk to the insurance company first,” he said. “The law firm’s not going to log on to your company portal to submit a FNOL [first notice of loss] request. They’re going to write a 12-page document and stick it in the mail, send it certified return receipt and all that.”
At that point, you need an automation platform that can read the document, determine that it’s a claim from a lawyer, extract the appropriate entity names, including the policyholder and law firm, and so on. “It gets pretty complex to automate that process,” Brown said. “And over the last several years, I’ve seen a number of initiatives with different technologies trying to figure that out.”
One approach is to apply OCR to read the document, then attempt to put the data into sentences, using sentence fragmenting technologies to identify various components.
“Ultimately trying to extract the data, it’s just been a real slog,” Brown said. “AI and natural language processing technology is required to do that kind of extraction.”
Related content: Why RPA falls short for insurance claims process automation
Specialization and model ownership questions
The reason that approach can be successful is that by focusing on a single use case an AI provider can accumulate enough data to successfully train a model. Vendors that specialize in that way are likely to claim ownership of those models and all the intellectual property they represent, he noted.
That’s a bit of a double-edged sword. Insurance companies contribute (anonymized) data on their customers, which helps make the models better. And each company does benefit from other insurance carriers doing the same. But the vendor ultimately owns the model.
I would argue that AI technology has come far enough that you no longer have to make that tradeoff. The Indico Data intelligent intake solution, for example, can achieve a high degree of accuracy with any use case after training on a relatively small amount of data. Just 200 samples of a document is enough to train a model for production, and its accuracy will improve over time from there. And you own the model, not Indico. (By the way, Indico’s technology has its roots in the Generative Pretrained Transformer AI models, or GPT. Yes, the same technology behind ChatGPT.)
Related content: GPT-3: Hype, reality, and the Indico generative AI origins story
Cost-justifying insurance automation projects
Another point Brown discussed – one that any insurance company must grapple with – is how to make the business case for an automation project.
The main alternative to automating the processing of claims or underwriting submissions is to throw more people at the problem. That is indeed what many insurance companies do, by outsourcing the job to overseas companies that supply cheap labor.
“If you’re paying somebody $8 an hour and they’re able to process 30 emails an hour, that’s a lot of productivity for pretty low cost,” he said. Unless you have a tremendous number of emails to process, it may be difficult to justify an automation investment on cost alone, the thinking goes.
What starts to tip the equation in the favor of automation is a discussion around quality.
“One of the downsides of using the low cost labor approach is quality,” he said. “Because people type and they make mistakes when they’re typing. And computers make mistakes when they’re using OCR for reading. So you can never get to zero in terms of error rate.”
But computers do better than humans, he noted, especially when humans are under constant pressure to go faster, whether because it’s renewal season or the ranks are thin or what have you. “When pressure happens, error rates go up,” Brown said. “Computers are consistent.”
True enough. With a human-in-the-loop approach, computers can also be trained to improve their performance – consistently.
Opportunity cost is another factor to consider, Brown noted. You’ve got lots of people who have been working on processing submissions for years. They’ve learned quite a bit about the business. If you can automate at least some of their jobs – the repetitive bits they probably don’t much like anyway – you can free them up to contribute in more valuable roles. That will also help you address the talent shortage that is plaguing the insurance industry.
Find the full transcript of the podcast here.
Lots of food for thought there. To learn more, check out our full conversation on YouTube or on your favorite podcast platform, including:
Subscribe to our LinkedIn newsletter.