RPA in Insurance: 6 Tips for Success

It’s not hard to understand the appeal of Robotic Process Automation, or RPA, in insurance: by automating mundane, repetitive tasks like data entry, it can reduce costs and cut cycle times while freeing employees to focus on providing better service to customers.

Over the past few years, I’ve talked with, advised, and worked alongside insurance companies as they implemented RPA. All of them have benefited, but few have gained as much as they expected.

Why is that? Here are the mistakes that I’ve seen—and six lessons that all insurance companies should keep in mind as they embark on RPA.

Lesson 1: Build a Clear Business Case for RPA

You’ll be told that RPA is now a well-proven approach, delivering sizable financial benefits quickly. While that’s a reasonably fair statement, I counsel you to view the business case with a degree of skepticism.

Strong financial returns rely on multiple key assumptions, including that:

• The processes being automated are well-understood
• The processes being automated don’t need to be changed in order to deliver benefits
• Implementing the technology will be straightforward
• RPA can indeed automate the process

In practice, I’ve seen:

• Insurers who don’t know what their existing processes are, or who don’t realize that different individuals or teams use significantly different processes to achieve the same ends. These insurers must therefore undertake a significant process-mapping and/or process rationalization exercise before they can automate anything.
• Operations in which the activities are divided between individuals at such a low level of granularity that there’s rarely more than one person carrying out any given task. So even if a bot could take over all the work, the savings would only amount to a single full-time employee.
• Insurers who lack a sufficiently stable systems environment to efficiently test bots and put them into production. These companies found that the bot build-and-test phase of each implementation was significantly longer (and more expensive) than anticipated.

Even if none of these problems apply to you, RPA still isn’t a panacea. RPA bots do certain things extremely well. But they’re not miracle-workers. If, for example, a key step in a process requires reading a handwritten document, extracting meaning from it, and branching the process accordingly, then an RPA bot alone is unlikely to be able to handle that. We’ll return to this theme later—but it’s another reason to be slightly wary of the ‘slam dunk’ business case for RPA that you’ve likely heard from others.

This doesn’t mean that there’s no business case for RPA. Often there is, and it’s compelling. You just need to adjust any overly optimistic assumptions to fit your own realities.

Lesson 2: Designate a Single Point of Accountability Across the Enterprise

Even a very small Insurer will have multiple areas in which RPA could be applied. They include, but aren’t necessarily limited to:

• Underwriting
• Policy issuance
• Renewals
• Admin/operations
• Claims
• HR
• Finance

That’s a lot of managers who can see the potential benefits of RPA and decide to pursue it.

Such enthusiasm is to be applauded, but it can also lead to multiple separate initiatives springing up across an Insurer. Often, they’ll have similar objectives, but they’ll take differing approaches, trial different technologies, and set up multiple project/program infrastructures to manage the effort.

So the first risk of a ‘laissez faire’ approach is overlapping activities—wasting time, effort and money.

The second risk is the exact opposite. With multiple uncoordinated initiatives, it’s entirely possible that, in addition to overlaps, there will be significant gaps. If one team is at least aware that other teams are working on RPA, they may assume that one of those teams is, for example, ensuring that appropriate tweaks are being made to the IT infrastructure to enhance the likelihood of RPA success. But it may be that several independent teams have thought of this, without anyone actually doing anything.

Both of these risks have the same remedy: ensuring that RPA projects/programs are coordinated across all parts of the Insurer.

But I’d advise going even further than that. Coordinating initiatives across a business often means little more than communicating what various groups are doing. That doesn’t always lead to better, or faster, decision-making and delivery.

In order to bring real focus to RPA across the enterprise, I recommend that one single individual be given responsibility and accountability for RPA, across the enterprise. RPA doesn’t have to be that person’s only job, but they must know that the majority of their performance rating and bonus eligibility depends on the Insurer’s RPA success.

Lesson 3: Think, and Act, Holistically About RPA in Insurance

The vast majority of insurers I’ve talked to or worked with have begun their RPA journey with teams that are focused exclusively on RPA.

Sometimes these are IT teams, who are looking to explore the latest software capabilities and assess how they might help the Insurer. Other times they are business teams, perhaps exploring RPA because a manager has heard that RPA is a good way to remove process cost from operations.

More forward-looking insurers have appreciated that the ‘Insurer of the Future’ requires more agile outcome-delivery models, and have put together a combined Business and IT team to explore the possibilities available from RPA.

And all of those approaches are probably fine for the very initial exploratory stages. But the insurers who have then continued their RPA initiatives with the same focus have often run into difficulties.

Here are 3 examples I’ve come across:

1. Having experimented with RPA, one business unit within an Insurer embarked on a significant program to develop and implement bots in its Sales and Marketing function. Unfortunately, the team was unaware of an enterprise-level program that was already selecting a new Sales and Marketing platform for use across the Insurer. The RPA team spent time, effort, and money building bots that were soon replaced by functionalities that were already present in the new system.
2. An RPA team analyzed their Insurer’s Claims function, looking for RPA opportunities. But Claims hadn’t been subject to any work re-design initiatives (such as process improvement, process re-engineering, and/or Lean) in the previous decade. Because of this, the group divided activities between individuals at such a low level of granularity that it was impossible to build business cases for bots. In hindsight, it would have been a much better use of funds to analyze a function that had already been re-engineered with process efficiency in mind and leave Claims until later.
3. When looking at customer query resolution, one Insurer’s RPA team found that only 30% of the contact center rep’s time was spent actually resolving the query. The other 70% was needed to understand the query in the first place. That meant it was hard to construct a viable business case. If only the Insurer could use an artificially intelligent (AI) chatbot to understand the customer’s query, the business case for automating the end-to-end process was sound. The good news was that the Insurer was already experimenting with AI chatbots. The bad news was that AI was in the hands of a completely separate team, who had no interest in contact center processes.

The root cause of these insurers’ difficulties is the same in each case. When RPA is looked at in isolation, at best, the insurer loses out on viable opportunities. At worst, the company spends money without getting a return.

The solution is simple to state, though often less easy to implement in practice. When assessing opportunities, the Insurer shouldn’t look at RPA in isolation. Instead, it should examine how a combination of process improvement techniques—Work Re-Design, RPA, AI and Core Automation—could be used to deliver greater operational efficiency and better customer service.

The key is to take a holistic approach to process improvement: planning and delivering a comprehensive short, medium, and long-term program, enterprise-wide, under a single leader.

Lesson 4: Don’t Prolong Technology Decisions

Robotic Process Automation is at an interesting point in its development. Though the technology required is no longer bleeding edge, no clear leader has emerged in the field.

Most of the best-known names in RPA software are relatively small organizations. Some of the big players have taken steps to add RPA capabilities to their offerings, but there’s a sense that it’s all a bit ‘me too’ at the moment.

Without a clear software leader, it can be tempting for insurers to take no action at all. That’s especially the case if their software procurement processes are particularly risk averse, requiring them to buy only from long-established brands.

And even where ‘big brands only’ rules aren’t a barrier, setting up and running a software selection exercise can be both time consuming and challenging. How, for example, do you compare a more limited offering from a more established player with a much broader product offered by a relative minnow?

I’ve seen too many insurers take ages to make decisions about RPA software—thereby increasing the overall cost of the automation program and extending the time to value.

In my view, companies in this position should recognize the problem and deal with it head on. With so much digital disruption in insurance, insurers must be able to make fast decisions. They must be agile enough to explore new capabilities with one brand of software, but able to switch rapidly to another provider when it makes sense to do so.

Here, then, is an ideal opportunity to take a speedier approach to selecting your RPA software:

• Recognize upfront that you may need to revisit the decision in future years—that’s okay
• Seek advice on who the ‘best’ players are currently
• Delete any from your shortlist who break any genuinely inviolable procurement rules
• Run a speedy process (ideally a conference room pilot) to assess which software you like best
• Negotiate pricing with your top two or three preferences
• Make a decision and get on with it

This whole process needn’t take more than a month—two at most. And you can be setting up other elements of your program in parallel.

The key is to focus on the need to try RPA and deliver some concrete wins, not to find the ‘perfect’ RPA software—especially when the pace of change means that today’s best option may well not be tomorrow’s.

Lesson 5: Get Ahead of People Issues

In the excitement of applying a powerful new technology like RPA, it’s all too easy to forget about the people involved, and change management in particular.

Here are some real-world examples I’ve seen:

1. An Insurer was embarking on a significant digital insurance / automation program. Sensibly, it was being led from the top, with clear messaging to senior leadership about the reasons for the program and the potential consequences of not carrying it out. Senior leadership cascaded these messages to middle management. At that point, the Insurer’s “immune system” kicked in to kill the program. The problem was that the Insurer had a very paternalistic culture, jobs in the area were scarce, and middle managers often had relationships with their employees outside of work. The last thing those middle managers intended to do, therefore, was implement something that might put their friends (and sometimes relatives) out of work.
2. Another Insurer didn’t have the same issue of intertwined relationships. But it did have a culture in which executives’ power was measured by how many people they were responsible for. Without a change of culture, it was unlikely that a powerful leader was going to find many roles to automate.
3. A third Insurer was growing, year on year, faster than its staff attrition rate. Automation wouldn’t typically lead to job losses, which was helpful. However, because of the high growth, managers had always been very focused on onboarding new talent and quickly getting them productive, while fighting the administrative ‘fires’ that cropped up daily. Most managers had never been asked to step back and consider potential process efficiencies, and they had neither the tools nor the time needed to do so.
4. In my final example, none of the problems above were applicable. However, despite a claim that honesty was a core value, management shied away from giving staff harsh messages. Because the managers realized that the RPA program would lead to some lost jobs, they resisted discussing the subject with their team. This left an information vacuum—which was quickly filled by rumor and conjecture. In many cases, these imagined implications were far, far worse than the reality. But because communications had been mishandled, the Insurer was at risk of losing good people—people with skills they would want to keep—to competitors.

None of these challenges was impossible to solve. In all cases, a properly constructed Change Management program, including stakeholder management, communications, training and, in some cases, culture change, would have meant a much greater return on investment from RPA.

Lesson 6: Don’t let Perfection be the Enemy of the Good

If you’ve read this far, you’re probably thinking that implementing RPA in Insurance is an enormous challenge. And you’d be right.

But that doesn’t mean that you should succumb to paralysis by planning.

As with software selection, so with the overall process: speed is almost always more important than attaining some notion of perfection.

Assuming that you are senior enough in the Insurer to make RPA happen, then you are ideally placed to:

1. Take a realistic approach to the overall business case for RPA
2. Appoint a single leader with enterprise-wide accountability
3. Ensure that the leader’s scope includes all process improvement tools
4. Make sure the team doesn’t prolong software selection unnecessarily
5. Put appropriate change management elements in place to maximize the chance of success

With these points in mind, you’re ready to start your effective Insurance automation program—and to start now if you haven’t already.

This post first appeared on LinkedIn.

Get the Skills You Need

Thousands of independent consultants, subject matter experts, project managers, and interim executives are ready to help address your biggest business opportunities.

Get Started

About the Author

Alan Walker is an interim executive and consultant who has helped some of the world's largest insurers respond to new technologies and changing customer demands. Previously a Partner with EY and an EVP of Capgemini Invent, Alan has delivered both growth and operational improvement, with a particular emphasis on transforming distribution, underwriting, claims, and operations.

More Content by Alan Walker