A Comeback for Native Mobile Apps in Insurance?

One vendor at ACORD LOMA says insurers should embrace the app model even though it can be difficult to encourage policyholder adoption.

Insurers know mobile is here to stay, but have struggled with one particular idiosyncrasy of the channel: While native apps offer the most robust, differentiated experience possible, policyholders don't necessarily need to store an insurer's app on their phone. Allstate's EVP of technology and operations, Suren Gupta, summed up the issue in an interview last year with Insurance & Technology:

"The frequency of touchpoints with customers is not all that often compared to the banking space. I don't think it will ever hit the same point," Gupta, who used to work at Wells Fargo, says. "But we absolutely need to be there when people want it, with the info they need just in time — for example, if someone gets in an accident and doesn't have their insurance ID card on them."

But the mobile browser might never fully catch up to the capabilities offered by a native app. Sundar Vallinayagam, CEO of Jarus Technologies, says that browser-based experiences "don't have the depth and feature set that a native app can employ." The vendor released a set of standards called Jarus Mobile API at ACORD LOMA that aim to make it easier to deploy native apps across several platforms.

Vallinayagam says insurers should aim to encourage app adoption rather than just settling for a mobile web experience so they can take advantage of the robust feature set when it's most needed.

"When a customer installs an application, that is when they need a transaction," he says. "We need to create features that have to be used."

The largest insurers are creating advertising around their mobile apps, Vallinayagam adds, so it's clear that there is a segment of the industry trying to create that need.

But Ray Shah, director of insurance for Synechron, maintains that the mobile web offers the most flexibility for insurance companies. The company has developed a robust mobile web experience that incorporates image capture and e-signature capabilities through the mobile browser.

"Native apps are how mobile got started in insurance, but there's not much e-commerce going on there," Shah says. "We are talking to our clients about the best way to approach getting agents and brokers to submit new business using the mobile framework."

Nathan Golia is senior editor of Insurance & Technology. He joined the publication in 2010 as associate editor and covers all aspects of the nexus between insurance and information technology, including mobility, distribution, core systems, customer interaction, and risk ... View Full Bio

Relevant services that are worth while to download and store as an app are calculators (for example policies that their rates that are updated frequently), reminders (to file a claim, extend coverage etc.) or -- any kind of utilities that make use of the mobile device's capabilities such as: mobility, accessibility, voice recording, photo storing or location indicators. Take these into any point of contact with the customer or broker and that's an app worth developing.

You are right, a native app can allow to pay bills as well, but there are a few factors to consider if you are a company taking that road -1. For login and specifically payment abilities through a native mobile app, there are more security issues to consider and a longer vetting process as well as the fee for revenues through the app to the mobile platform itself (to Apple, for example).2. Additional development & maintenance costs - for each device type and versions.

Developing once in HTML5 is suitable for all devices, and there are no additional considerations so it is the right choice for most processes such as customer account management, filling out forms or payments.

IMO the native app development is justified only for the reasons mentioned above and if ROI is obvious (for example saving the cost of a surveyor's physical trip).

Thanks Lee. The question is, though, what kind of relevant services create the need to download and store an insurance company's app? The inventory idea is interesting Gă÷ new insurables are often brought into the home, so a consumer might want to keep that app around so they are always up to date on covered items. Many insurers have developed such apps, as a matter of fact. But why can't the same app also allow them to quote, pay bills or manage claims?

The question whether to develop in HTML5 or native arises with every development for mobile. The question you have to ask yourself is this: what is the purpose of my app? An insurance carrier's website and existing online services should definitely be adjusted for mobile browsing and that can be easily done using HTML5, as well as Information input (forms) and output (customer accounts' access).

But, carriers that want to use the additional value that a native app can provide must develop it, with all the expenses and headache it entails. A native app for example can allow you to offer innovations that make use of the touch interface and mobile device functionality in ways that HTML5 doesn't, where the user experience is most important. The same goes for brokers and agents applications. If you have a native app that does that, people will download it without the need to encourage app adoption.

We at MoveInsure have developed both, each development depends on the app's purpose: our native app allows you to create a visual home inventory for a moving insurance quote, and in order to purchase a policy you are transferred to the HTML5 wizard.