The Achilles Heel of Insurer Technology

Migrating the technology infrastructure supporting insurance underwriting to “digital” has substantially different meanings depending on who has the floor. For some insurers, it is simply the ability to put a product on the web and offer on-line quotes to prospective policyholders. For others, it is the ability to quote, bind and issue a policy on line. The more sophisticated platforms offer a complete digital marketplace for consumers to shop, obtain pricing, buy, bind, pay for and have policies delivered for a variety of products, offered by multiple carriers, into a secure web-based account, using familiar, digital, “shopping cart” tools and techniques. Still, many carriers need to examine their current systems, which were not built for speed to market or a high degree of automation. The issue for many carriers attempting to go digital is the burden of having web-based sales integrate seamlessly with their legacy systems. I’ve had numerous conversations with executives who bemoan the fact that they can’t offer a product in a different channel because the systems “can’t handle it.” So, carriers are turning away business (and doing their customers a disservice). The Achilles heel for most insurers is that insurance product systems design theory of the '80s and '90s was component-based. It made sense at the time, but it doesn’t any more. The typical carrier legacy system configuration involves a different systems component for practically every function along the product continuum, starting with account acquisition and continuing through agent licensing, underwriting, compliance, rating, quoting, binding, policy issue, premium collection, commission administration and claims payment and ending with financial reporting. Along the way, account data is input into each separate system (sometimes manually, sometimes automatically), resulting in multiple silos of redundant account data. How many employees do you have going through a monthly reconciliation process just to determine you are not double counting business? Wouldn’t it be great if those employees were helping to generate revenue, not figure out if the revenue you think you have is actually revenue? Component-based systems are further complicated because they are often programmed in different languages, come from different vendors, require separate support and maintenance personnel and in many cases rely on programmers who become experts in a very narrow section of the code. (“Don’t ask me about the commission system; I do the billing system.”) The complexity gets compounded with acquisitions of companies that have deployed a similar, component-based approach. Carriers that are serious about a digital transformation need to take a holistic view of the product sales, underwriting and policy administration continuum. Instead of looking at a new component for the underwriting function, a new policy administration system, a new document management system, carriers need to view the entirety of the product process, create a single, relational database and work with a “product agnostic” platform. The ability to put all products on a single system with capabilities to automate underwriting, rating, quoting, binding, policy issue, premium and commission administration is the ideal scenario. Providing access for all users to run all applications from a single system eliminates redundant data entry, programming and maintenance requirements of component-based platforms and enables you and your company to concentrate on the strategic initiatives you’re supposed to focus on.