A CASE STUDY IN LOW-RISK, QUICK-HIT À LA CARTE STYLE ROBOTIC PROCESS AUTOMATION IMPLEMENTATION FOR INSURANCE COMPANIES OF ALL SIZES
Digitization was the hot trend in insurance not too many years ago, and the efforts continue today. What was revolutionary then—and seems quaint now—was the idea of taking paper forms that customers must fill out, and putting them up on a website, where visitors could complete them online. In the intervening years, that transformation has become the rule; today, customers expect to do things like file their claims online or via a mobile app.
But the digitization wave has left a dirty little secret in its wake: All of the forms that were digitized years ago were not created to integrate with back-end legacy systems. Humans still sit in the back office and move this form-submission data into systems manually, one field at a time. This means that, despite advances in automation, most insurers today don’t have straight through processing.
Are you tasked with reducing and minimizing insurance claims leakage? Find out how to accelerate those efforts here: How to minimize claims leakage with bots
This case study, based on a client engagement with The Lab which we just completed recently, will help you to see how you can transform your claims-processing operation (to name but one function) with a revolutionary à la carte approach to installing robotics. We’ll also take this opportunity to dispel numerous misperceptions about robotic process automation and artificial intelligence that are starting to flood the marketplace.
Spoiler alert: You can start small, with a single robot, and have it speeding along on its job in just four weeks.
Front-End Inbound Data vs. Back-End Manual Data Movement—an Opportunity to Standardize Insurance Operating Data and Process
The insurer we worked with was one of the first movers in digitization. They boldly put all their forms (from quotes to claims) online and helped to transform the industry—and customer expectations—in the process.
When they contacted The Lab, they gave us a quick demo of how first notice of loss, or FNOL, takes place at their company today. We’ll explain the steps here, and we guarantee that each one will ring familiar to you.
When a customer—let’s call him Sam—has an auto accident and needs to file a claim, he visits the insurer’s website and fills out all the fields in the form. While the experience may feel high-tech to Sam, it’s actually very low-tech for the claims processor at the other end; let’s call her Sally.
After Sam has completed the 30-odd fields in the FNOL form online, it basically gets turned into a lengthy email which lands in a group email box in Outlook, which Sally accesses from her desktop.
Sally then places the email window on one side of her screen, and opens a window for the CRM (customer relationship management) system on the other. Here, she looks up Sam by name and policy number and coverage, to make sure he’s a valid customer. Once she validates Sam, she then opens yet another window on her computer. This is the claims system—in this case, Guidewire ClaimCenter. It’s at this point that Sally begins the tedious process that consumes so much of her days: She copies and pastes. Specifically, she reads all of the free-form text which Sam had entered online, finds the corresponding field in the claims system, and pastes the information within it. To process Sam’s FNOL, Sally will spend about 50 clicks, and 20 minutes, to do it.
To get you thinking ahead about the numbers here—and opportunities for turbocharging efficiency—Sally will process 20 FNOL forms on a typical day. And in the home office where she works, Sally is just one of 75 claims processors.
The Non-Standardized Data Field Processing Backlash to Hit Early Adopters in Insurance
If you were paying close attention to the story we just described, one phrase should have leapt out at you. And that was the phrase “free-form.”
Think back to Sam, filling out that form online (or even via his mobile app). He had more than 30 fields to complete, and for 75 percent of them, they were simply open text fields. This may be fine, indeed required, for fields such as “Describe what happened.” But they’re the exact opposite for fields like “Type of vehicle.” Even today, in an Amazon-enabled age, Sam was unpleasantly surprised to discover that he had to type in that he drives a “2012 Mustang” into the field. Where were the pull-downs for “Year,” “Make,” “Model,” and “Trim”? As it stands, Sam drives a 2012 Ford Mustang in the GT trim level. He didn’t
think to type that in. Guess who will have to chase down that information and enter it into Guidewire? You guessed right: Sally.
The root of this problem: The company’s now-outdated digitization effort. Back then, they didn’t think of creating online forms with the minimum possible free-form fields. Today, however, it’s a maximum problem which doesn’t allow for straight-through processing and requires highly paid claim processors like Sally to spend more than half of their days reformatting customer-claim submission data, and moving that data into three or four different systems.
In this case (and perhaps yours, too) there’s a silver lining. The claims-system interface on the back end is populated almost entirely with pull-downs, such as “2012 > Ford >Mustang > GT.” This helped to define what became our two-part engagement with the client.
À la carte Insurance RPA Transformation Part 1: The Front-End Data Form Factor
As you’ve probably guessed by now, we recommended that the customer-facing forms be re-configured to mimic the fields in the existing claims system. The data fields needed to be standardized to allow for eventual straight-through processing of customer claims directly to the back-end system.
The Lab was able to accomplish all this for the customer in just two weeks. Most importantly, all this work was on the front end. In other words, it didn’t touch the back end. At no point did we ever lay a finger on the client’s core claims-processing system or database, both of which were about a decade old, and heavily customized. Thus there’s no risk, zero IT department intervention required, and astonishingly little cost.
À la carte Standardization and Robotic Process Automation Part 2: Configuring the Insurance Bot Using UiPath
We didn’t mention another system in use at this insurer, but it’s one that affects Sally’s day, and the robot implementation. That’s the company’s internal ticketing system, which assigns claim numbers and keeps track of claims aging. It’s what Sally and her manager rely on to monitor flow.
It was thus another aspect of the robotic process automation project. We configured the bot to pull information from the ticketing system, as well as the
completed info from the updated customer web-claims submission form, and processed it directly into Guidewire.
For this client, we used a UiPath robot. But we can work with Blue Prism, Automation Anywhere… virtually any kind of robotic process automation (RPA) platform out there. We are technology-agnostic.
The robot can do what Sally does, in mere seconds. It pulls the information from one system, finds the appropriate places for it in another, and pastes it in as needed. If it finds un-reconcilable data, it spits out an exception for manual processing—now the only work of this type that Sally must do.
The vital underpinning is the standardization of processes and data that any RPA platform requires. Without that prerequisite, robotic process automation will simply move bad-quality data at lightning speed.
Fortunately, The Lab has spent more than 25 years standardizing operational business processes for Fortune 500 clients. Now that RPA is here, the automation technology has finally caught up to our expertise.
How Many Insurance RPA Bots Are Required?
We’d mentioned that Sally is one of 75 claims processors at the home-office claim center. You might think—and most big-name consultancies will tell you—that each person in Sally’s department would need their own bot (along with a purchased RPA license) in order to succeed.
They’ll also tell you that you’ll need to create a costly center of excellence before you can automate anything.
They’ll tell you that extensive staff training is required. They’ll say that all this will take about a year, and a million dollars or so. And they’ll say that the robots will need to be created offshore, say in India, by IT professionals.
All of those statements are, simply, wrong. We can use this client company as an example.
We were able to meet all the needs of Sally’s department with just one robot. We parked it on a virtual server on the client site (or in the cloud, if you prefer), in our revolutionary and disruptive “upstream intercept” model that’s now being embraced as the new best practice.
It serves up completed claim data-movement work for every processor in the department, automatically, in a matter of seconds.
The only training that was required was teaching Sally the new way to handle exceptions. That took her—and the rest of her department—just one day. We handled all the training, remotely from our Houston office, with online meeting software and a few teleconferences.
As for the center of excellence, none is required at this scale. Only when you get bigger—on the order of, say 25 bots—would you need one. And even then, you don’t need to create one. That’s because The Lab offers à la carte COE services as well.
Incidentally, RPA bots are incredibly reliable and dependable: Think of an operation like copy-and-paste. Does it ever fail? Even when bots do go down—say,
because a field in the underlying database has been reconfigured—they can be updated in a matter of hours. In the meantime, the legacy system still works and is available to people like Sally. So there’s a short and minor slowdown, but zero stoppage.
Insurance RPA Project Travel Costs—or Not.
We saved the best part of this story for last. This client was based hundreds of miles from our offices in Houston.
So that required a lot of travel, time, and expense, right?
Wrong. We were able to complete this entire engagement remotely from our USA based offices. None of our work is offshored. And from first phone call to hardworking robots processing claims took just four weeks.
To this day, clients are simply shocked when we tell them that they can start with ten robots, or just one, and be up and running in just weeks. But as engagements like this one prove, it’s not the exception but the norm.
Bottom-Line Benefits of à la carte Bot Implementation and Off-Site RPA COE Service for Insurance Companies
Today, Sally’s life is both productive and rewarding. She doesn’t spend time copying and pasting. She’s processing existing claims instead of choking on the “paperwork” of new ones. Importantly, she’s providing better customer service. She’s doing it faster. She’s helping to slash claim-cycle times, while boosting the company’s net promoter score numbers because she serves more customers daily. Importantly, she’s enjoying her job, now that she’s able to focus on what enticed her to join in the first place: the opportunity to help people.
The company is still running its legacy claims system, ticketing system, CRM, and database. All that was changed was the front end—remotely.
They experienced this revolution in just four weeks. You can, too. ContactThe Lab at (201) 526-1200 or info@thelabconsulting.com to schedule a free, no-obligation 30-minute screensharing demo of how we can help today.
Also be sure to check out this new case study about
RPA in insurance claims processing:
For 2021: We have updated our insurance client offering. Much of these findings and implementation results can be reviewed in the 4-part-series of “Big Rocks for Insurance” below. Find out how to strategically lower costs, increase operating leverage, improve customer experience, and automate what previously wasn’t automatable in your insurance company.
Find them all here:
