The most important thing we learned building commercial lines API's with 12 insurers


12-API-learnedThere's been a renewed interest in commercial lines data exchange over the last year, and it has us excited. Since 2007, Policy Works has worked with 12 different insurers to build various commercial lines data exchange API's (integrations). We've learned a lot along the way and we want connectivity to succeed as much as anyone else. So we're sharing some of our experiences.

What's the most important thing we learned?

Don’t change user behaviour.

CSRs, marketers and account managers use BMS (personal lines) and CMS (commercial lines) systems to manage their policies. They get efficient and effective at using these systems. Which is a benefit because they are put under a great deal of stress every day to perform: processing renewals, marketing for new business or creating multiple certificates. System efficiency means brokerage productivity.

In the early days of commercial API's, we introduced "bridging" solutions from Policy Works to insurer portals. This altered the user workflow, especially for quoting new business. Although a good portion of data captured in our system would upload, the integration went against well-formed habits. Usage of the bridge-to-portal solution was low.

Why? People don't like to change their behaviour. Unless, of course…

The user experience is way more compelling (than what it currently is).

If you want to change behaviour, the new workflow needs to be more compelling to even have a chance at succeeding. When we created API's to portals, the user experience was not great. More fields had to be filled out on several portals, and often different fields for each one. So if a marketer was trying to get three quotes on a piece of business, they ended up going to three portals.

This wasn't a more compelling experience than emailing, faxing or calling an underwriter. And usage told that story.

So working with AXA, we launched AskBack (which was a great vision and idea), where we tied in directly to their back-end underwriting system. The AXA system would machine the submission data entered and "ask" further qualifying questions in an interface we built into Policy Works.

The goal was a real-time quote. But that almost never happened because the underwriting rules were so stringent that marketers and CSRs got caught in an seemingly endless loop of Q & A.

Better experience? Nope.

We refined this process with other insurers. The solution worked (from a technology perspective) but still failed to get lift from a broker perspective because:

  1. The underwriting rules were overly constrictive;
  2. There was too narrow a box around the types of risks that could be automatically underwritten, ending the real-time process; and
  3. Because of points 1 and 2 too often the workflow resulted in "referred to underwriter".

A broker spends time completing a bunch of questions only to be referred to an underwriter. After a couple of tries, who would continue to do that? No one.

The end-user experience still didn't match what had already been in place: email fully completed PDF's to multiple underwriters directly from the broker's system.

Which lead us to understand that if you can't beat it, leverage it.

Leverage existing behaviour.

This brings us right back to where we are today. To what ORBiT, IBAO, IBAC and CSIO have been preaching for the past decade: data exchange/connectivity needs to start and end in broker systems.

But this is incomplete. The second part to this principle is:

Any connectivity solution needs to be invisible to the end user; seamlessly integrated into existing workflows.

No sidetracking. No modifying behaviours. No additional dialog boxes. The connectivity solution needs to be invisible to all users.

Eating our own dog food, we've found success is what we call Smart Doc technology (you can read more about it here). Users of Policy Works send their submissions to their markets of choice. Using a web-service the data in the submission is pulled into the underwriter's quoting system.

The process is seamless to existing Policy Works users; it requires zero changes to workflow or user behaviour. Underwriters don't have to re-type data into their underwriting system. And they still have a physical submission document, complete with images, that can be used to assess the risk.

RSA is using this now, along with SGI Canada, Coachman, L'Unique, and Promutuel. (There's one more insurer using this API in a test environment, soon to be released to the industry.)

The intent was not to promote our Smart Doc solution but to share that, after 12 years of commercial lines connectivity and 12 integrations, we've learned that for data exchange to truly be successful, solutions must 1) start and end in broker systems and 2) they must be invisible to the end user.

With a strict adherence to these two principles we may just see lift in broker connectivity.

Analytics for principals

Commercially focused brokers need to know what's happening with their book. We've developed an analytics eBook roadmap to help.

Get the e-book

Topics: Commercial_lines, API, connectivity, data exchange