Data Exchange 2.0

In recent months, brokers have not been shy about putting their tech cards on the table. Whether it is the Insurance Brokers Association of Canada (IBAC)’s ideal electronic workflow initiative, or the work done by Ontario Real Time Brokers in Transition (ORBiT), the message is clear: “All transactions must start and end in the broker’s systems.”

We couldn’t agree more. However, the path ahead is not necessarily that simple or straightforward. Insurance companies have invested significantly in their Web portals and these will not go quietly into the night. And let’s face it: some commercial brokers receive benefits and workflow efficiencies through portals. For a small brokerage with a limited book of commercial business — a brokerage that simply cannot justify adopting a full-on commercial management system (CMS) like Policy Works or comXP — portals provide a cost-effective alternative. But for serious commercial-lines brokers who have invested in automation, portals complicate the workflow and introduce duplicate data entry.

THE END OF ‘BRIDGING’ SOLUTIONS

So should the industry get rid of company portals? No. The trick is to ensure we don’t throw the baby out with the bathwater. Let’s make portals part of the solution, instead of the only solution.

Today, data-exchange integrations between broker systems and company portals are bridging solutions. These integrations reduce the friction of dealing with those company portals by automatically filling them with data from the broker’s CMS. The broker merely needs to complete the missing fields and hit ‘submit.’These bridging solutions eliminate duplicate data entry, reduce the corresponding problem of re-keying errors and streamline account and password management.

But bridging solutions are not ideal. First, although a bridge fills in as much data on the Web portal as possible, the user must still find and fill in any missing data fields. That entails hunting through the portal’s online application form, trying to pick out the missing information from the fields that are filled in. In addition, the variations between insurer portals, such as different sign-on procedures and unique workflow processes, in- crease complexity and require brokers to train staff on multiple systems. Further, some portals won’t accept all of a broker’s business, forcing users to choose different workflows depending on the business at hand. And Web portals will never fit the needs of users who prefer traditional workflows like email, faxing or call centres. All of these limitations add up to friction in the broker-company distribution channel.

The important thing to recognize about these bridging solutions is that they represent the first generation of Web solutions. We like to refer to them as Data Exchange 1.0. Bridging solutions are far from perfect, but they are the foundation on which we can build an even better future. That future is something we’re calling Data Exchange 2.0.

Data Exchange 2.0 is about improving the communication between people. The goal is to foster the relationship between the broker and the underwriter, using technology to assist them in their preferred workflows. Brokers can choose from multiple workflows — email, fax, call centre, Web portal, or straight through — depending on their needs and preferences. And technology will support them by providing information in the richest possible formats. It sounds like a much better platform, but what does it mean specifically?

RICH DATA

Let’s start with how information gets represented. One goal of Data Exchange 2.0 is always to provide the richest data possible. For the computers that are involved in the workflow, CSIO XML is the common language. It enables one computer to understand what another computer sends. But when people need to get involved, XML is not a friendly format. So Data Exchange 2.0 provides human-friendly formats too. PDF documents are the obvious choice, because of their ubiquity. If an underwriter and a broker both have a copy of the same PDF submission, they can use it to improve their communication. The underwriter, for instance, can say to the broker, “what is the meaning of the note on page 3 of your submission?” and the broker can see the same document. In cases like this, the PDF literally lets them be on the same page.

But rich data is not just PDFs. It can be any supplementary information that will help brokers and underwriters communicate. So, if there is scheduled information in Excel spreadsheets, inspection reports or even photos, these will be shared. Through rich data formats, we will be able to send and share all the information that both people and computers need.

Another goal of Data Exchange 2.0 is supporting multiple, flexible workflows. Brokers choose different workflows depending on many conditions: the kind of business, the urgency of the task, their personal preferences, and more. Technology will support people as they go about their work, regardless of which workflow they choose. And in each case, Data Exchange 2.0 will provide the richest data possible.

Let’s look at some of the possible workflows, starting with the richest, most flexible ones that Data Exchange 2.0 can enable. The ideal is no-touch, straight-through processing, in which a broker prepares a submission in a CMS like Policy Works and uploads it straight to an insurance company’s Web services. Note that the broker does not send it through a portal, but rather directly to the insurer’s back-end system. If the insurer’s system can rate the submission automatically, it sends back a quotation to the broker in real time. If the insurer’s system requires additional information, it can use AskBack technology to send questions back to the broker’s CMS, so the broker can answer these questions in their own system. Again, this communication exchange does not require the broker to go outside their CMS.

For business that cannot be rated automatically, a Data Exchange 2.0 system would have the flexibility to refer the submission to an underwriter. In this case, the submission has still gone straight thru, but it’s no longer real time. Here’s where the people get involved. The underwriter needs to review the submission before quoting. With rich data, the underwriter gets a PDF copy to review, and the insurer’s system gets XML so there’s no time wasted on data entry. If required, the underwriter talks to the broker and resolves any questions before completing the quotation. Then the broker downloads the rich-data quotation– PDF and XML–into their system.

Other workflows will also benefit from incorporating rich data. For example, let’s say a broker prefers to email submissions to their underwriter. In this case, the PDF is the focus of the communication. But to avoid errors and reduce turnaround time, we want to eliminate duplicate data entry at the insurer’s end. So a rich-data submission incorporates XML into the email, so the insurer’s systems can populate it right into their underwriting tools. Again, when the quote is ready, the broker can download it directly into their system.

What about traditional kinds of submissions, whether through fax, paper or call centres? Some brokers may want to use these methods for certain types of business. Again, Data Exchange 2.0 supports whatever workflow the broker chooses with the richest possible data. In these cases, the broker has not yet entered anything into their CMS, so there’s no data to exchange in the first place. Fine. Data entry will begin at the insurer’s end, as it does today for these workflows. But the broker can pull this information back into their own system–without having to enter or re-enter data.

DATA EXCHANGE 2.0

Much like the Web moved from version 1.0 to 2.0 in its evolution, data exchange in the insurance industry is poised for its own transformation. Data Exchange 1.0 was all about getting computers to communicate. Data Exchange 2.0 is all about helping humans to work better togethe r.