By Doug Grant CIP, Principal, Insurance-Canada.ca
(as published in Alberta Broker, April/May 2003 issue)
In late February, Insurance-Canada.ca held its fourth annual P&C Insurance distribution seminar. In retrospect, these events provide a way of monitoring actual progress in broker-company communications. For the future, presenters bring opportunities, plans and predictions.
Both insurers and brokers, being members of our competitive and entrepreneurial culture, have always sought better tools to remain competitive or gain an edge. Computer applications represent a continually evolving array of functions. Insurance firms now depend on computerized data to run their business.
Within firms, different business processes are being linked and extended to reduce the number of transaction hand-off’s bringing fewer errors, improved transaction times, lower costs and higher customer satisfaction.
Broker-company Interface occurs when a computer process in a broker’s office communicates with one in a company office. This becomes seamless when there are no manual hand-off’s or steps between the two firms for that process, be it a quote, piece of new business or first notice of loss. People are still involved even after initial capture of the transaction, handling the exceptions which skills, judgement and further action.
Fewer manual hand-off’s reduces transaction times, but does not make them necessarily immediate. We have only to look at new business transactions using EDI. The CSR may gather the required information in fifteen minutes on the telephone or in a face-to-face meeting, or it may take several days. Interface to the company typically happens overnight. A simple piece of new business could be returned to the broker after the over-night new business processing; or could be delayed for several days while risk assessment information is gathered, and/or the transaction is referred to an underwriter for processing and approval.
The ultimate objective is an immediate transaction. With customer on the telephone or across the desk, the CSR’s submission, directly from the Broker Management System, will be transferred and processed instantly. Unless intervention is required, coverage is immediate, with policy paperwork on the spot or delivered later.
The technologies exist and are being used today in the USA to process some transactions this way. To get Canadian participants to that level will require a number of steps, and parties at both ends being willing and ready to conduct business accordingly.
Let’s analyse a simple payment inquiry transaction scenario in which the insurer processes a monthly PAC premium payment. The customer wants to know the status a day or two later.
The inquiry sequence will be customer to broker to company person. The company would have sent a request to their bank before the first of the month requesting the PAC withdrawal. The customer deals with a different bank, and the turnaround time on the withdrawal request could be days.
If there is an error condition, such as an NSF, the insured’s bank notifies the insurer’s bank, which in turn informs the insurer.
Without errors, the insurer will know that the money has actually been received when a reconciliation is done, which may not be daily, or even weekly. Thus the gap between the request for withdrawal and the reconciliation could be several days. During that gap, they only know that the request for money has been made, not that an error occurred or that withdrawal was successful.
With the insurer and bank exchanging information electronically, presumably the accounting information will be updated automatically when data is received. If the accounting system is an older one, the data presented to staff may be somewhat cryptic. With the right training, they can understand and explain what the data means, but without the training, it would be easy to misinterpret the data also.
In the scenario thus far, customer calls broker CSR who calls company support who provides the status.
Let’s Go On-line.
For efficiencies and better service, the company decides to give brokers access to the data online, thus reducing phone calls. Hardly praqctical to educate the hundreds or thousands of broker CSR’s who could ause the online inquiry. So the insurer spends a year or so modifying the accounting system data and adding an inquiry screen with a much more detailed and specific explanation of the meaning of the status information.
Wider access raises privacy and security issues, which generates another round of investment in policy and tools. The system is implemented. The broker CSR can now provide payment status while the customer is on the telephone with them. Phone calls to insurer support are reduced along with customer call-backs. But the CSR now has another set of logon id’s and passwords, a procedure, screen formats and data unique to one company. For our example the Broker has access to four such companies with online payment information; one dragon slain, but another on the scent.
CSIO Insurance Portal
CSIO has developed common screen formats for payment inquiry. On the Phase II wish list is a common log-on and perhaps payment inquiry.
Using single logon allows a CSR to access any authorised function from any authorised company – a much easier time and the benefits calculated by CSIO are dramatic.
For payment inquiry, a single common screen format or user interface at the portal level removes much of the usability issue. However the companies now must accept an XML data request from the CSIO Portal and respond using the standard data layout, and with data in that layout having consistent meaning. If the online access described above was well designed, the transition for a company to this new environment could be trivial; otherwise more work. A translation or transformation capability in the Portal could help companies implement too.
Life for our CSR is easier still.
Back to the Future
Finally, BMS vendors are sophisticated and XML and web services tools are getting better. If companies communicate with the CSIO Portal using XML, then BMS vendors and their users can too. In this scenario the broker CSR uses the BMS functions to request payment status. The BMS passes the client and policy information, with the CSR identifiers, to the CSIO Portal. Authorisations are verified and the data reformatted to the company’s needs, with responses going back. As the data arrives as a data record to the BMS, it could be displayed, and if appropriate, stored as part of the client record.
But why not have the Broker’s BMS communicate directly to the companies. The intermediate switch, as found way back in ICEnet days, allows each participant to be at different levels of standards, or to use different communications technologies. Each participant communicates with the hub in its own way without being concerned about the capabilities of all trading partners – it is an easier way.
Its Being Done Today.
Is this possible? Yes. In fact it is being done in the USA today — almost. The environment is the same with IVANS Transformation Station being the alias for the CSIO Portal. The transaction flow is the same too. The response to the inquiry however is not a single formatted response to the CSR on a common screen as suggested above, but comes back as an attachment. As seen in a demo recently, these attachments vary widely company to company, from simple text files to nicely formatted pages in a pdf suitable for printing or faxing to a customer to html pages with hot-links for transactions which could follow. The philosophical question: which response is better?
The point of the discussion is that all participants, insurers and brokers, will never have the same functionality at the same time. From a company’s perspective, they probably need all access points. Internal support staff and outside non-CSIOnet users need browser access; Brokers with BMS’s which do not support a transaction using XML could use the CSIO Portal browser access, and Brokers who have full BMS capability can stay within their own workstation. And many brokers have companies which may stay outside the CSIO Portal, and others with varying degrees of functionality across a wide portfolio of transaction types.
Those who invest will reap the reward. There will be some arrows along the way, and sometimes a step backward for every two forward. But that is the nature of pioneering and risk-taking. The rewards from this online service capability are there for the taking. It takes two to dance; a whole bunch to have a party. We all have to invest, move forward, and cajole others to stand up to the partnership too.
(note: Canada’s leading Insurance Internet Resource Centre provides current information for you at www.insurance-canada.ca and can help you reach your target audience)