Automating Policy Changes: Bringing Life To Change

Policy change is arguably the most complex insurance transaction and represents a weak link in the efficiency of the traditional broker distribution channel. Automation challenges associated with policy change/endorsement for both broker workflow and insurer technology are real and numerous. Future efforts will likely involve a much tighter integration between broker management system (BMS) vendors and insurance companies. Might there be an industry-wide solution? Many are not putting much weight on it.

One curious irony in the technology arena is the transactions that brokers conduct most frequently in their daily business are also the least automated. Policy change/endorsement has been a consistent stumbling block on the path to single-entry, multiple-company interface (SEMCI), leading to frustrating data re-entry, delays and callbacks. The difficulty in synchronizing policy change requests between varied broker management systems (BMS) and insurance company systems (front-or back-end) has derailed attempts to gain an industry-wide solution.

POLICY CHANGES

On the face of it, policy change doesn’t sound that complicated. A client calls a broker and asks to add a driver to an auto policy or to note a change of address for a home policy. The broker makes the change in the BMS and sends a policy change request to the insurance company. However, depending on the nature of the changes, a policy may need to be re-underwritten and re-rated. Given the level of automation of underwriting and rating processes at the insurance company, that process can take days, even weeks. Then, the change has to be incorporated into the BMS. Meanwhile, the client wants to know from the broker how much his or her new policy is going to cost.

It is hard to overstate the importance of policy change and endorsement in the typical broker workflow and communication to insurance carriers. For brokers, it is a crucial part of the service offered to clients — a service for which, at least in part, they are paid commission. For insurers, it increasingly represents a strategic point of differentiation for those keen to bill themselves to brokers as “easy to do business with.”

“While insurance companies have traditionally handled this function, we want to educate brokers on the benefit of doing their own policy change to improve service turnaround time,” says Colin Simpson, president and CEO of York Fire & Casualty. “I think brokers in general struggle with how they can compete effectively with direct writers. But everyone focuses just on price, not the other element of service. If we can get the back-end systems to communicate effectively, brokers can operate just as efficiently as a direct writer, with the huge added value of person-to-person contact.”

Brenda Rose, vice president of Toronto-based brokerage Firstbrook Cassie & Anderson, says brokers “really need policy change because it has to be done in order to service the client properly.”

Rose has been pressing this point home as a ‘technology champion’ with the Insurance Brokers Association of Canada. “It is an intensely costly transaction from the broker point of view, yet it is revenue neutral for both brokers and insurers,” she says.

Sheldon Wasylenko, assistant general manager with Saskatoon-based Rayner Insurance Agencies, is another technology champion at IBAC. “Policy change/endorsement does represent the majority of work that is done in a typical brokerage,” he observes. “There is new business, for sure, but looking after existing business, whether renewals, changes, endorsements, that represents a good chunk of our day-to-day work. So because of that, historically, it has always been seen as the difficult one to tackle from a technology perspective.”

Technology vendors are keenly aware of this desire to automate policy changes. “Endorsement is really the Holy Grail of where we need to get to, because that is where so much of the cost comes in the life cycle of the insurance policy,” notes Doug Johnston, vice president of partner relations and production innovation at Applied Systems.

Some studies point to how much of the work in a typical brokerage office is dedicated to policy change. In one report, Keal Technology estimated policy changes alone account for more than 40% of an average brokerage’s transactions. Glen Piller, president and CEO of iter8, says his company’s “research with brokers shows that policy change and billing make up more than 80% of their transactions with carriers, yet the ease of doing these transactions is the least.”

FROM CONCEPT TO PRACTICE

Unfortunately, policy change is also the most complicated transaction, with a history of workarounds and some confusion. “The technology to get it done is more complicated than simply pushing new business or policy inquiry,” notes Pat Durepos, president of Keal Technology. “Technology is certainly an issue. Nobody has been able to crack it just yet in the true XML real-time transaction.”

One reason for the complexity is that data transfer has to be coordinated between two distinctly different systems — the broker’s BMS and the company’s front-or back-end system. “Policy change is a complex area that people tend to oversimplify,” says Kevin Campbell, president of Policy Works. “There is a spectrum of problems that go from just plain difficult at the low end to practically unsolvable at the top end. The issue is that you are trying to synchronize data on two different systems, which in itself is a difficult problem.”

Other issues also make policy change a challenge, particularly “out-of-sequence” events. Jack Ott, chief information officer for ING Canada, says this is a special concern for insurance companies — especially if it involves brokers first reporting changes to branch offices. Client changes, especially for larger commercial policies, may not come in chronological order to the broker, creating a potential patchwork of changed policy documents that need constant revising.

“The issue of ‘out-of-sequence’ is a big one,” says Ott, whose company is actively working with vendors on enabling broker technology. “Many companies have gone to great lengths to ensure changes are kept in sequence. When it comes to policy change, we offer a very rich, fully functional product with multiple features — really, anything can happen with that policy when it comes to changes.”

For Johnston, the root of the policy change conundrum lies in the fact that broker and company systems were built for fundamentally different purposes. “It comes down to the different architectures of a broker system and carrier system, in that a carrier system was based upon a transaction model, whereas a broker system was based on a submission model,” he notes.

What that means specifically is that insurance carriers and brokers have a different “view” of the data in a policy. A company has a quite detailed view of a particular policy and can see what changes have been made to a policy over time. The broker, on the other hand, has a relatively static view of policy data. He or she can send a policy change request but that is what Johnston calls “just a piece of paper.”He adds: “to open a version of a policy and turn it into an editable document is not something that most broker systems were designed to do. We need to change that. In my mind, that is the big deal.”

Broker management systems were designed primarily as a “push” of information, says Piller. “When a policy change is required, you have to pull information, make the change, and then push it back. From a technology point of view, given the different BMS and different company technology systems, that makes the process very difficult.”

SEEKING THE SAME PAGE

Understanding the complexity of policy change is fundamental to any technology solution that tries to bring brokers and companies on the same page. Should the policy change be driven by the BMS, the brokers’ primary business tool, or the insurance company’s back-end system (traditionally the repository of ‘official’ policy documentation)? Is the technological challenge associated with policy change the result of inadequacies in the BMS or the company system? The answers to these questions, and the solutions that are emerging, depend on your perspective.

“From a broker’s perspective, it would be incredible to have SEMCI policy change,” notes Steven Kaukinen, president of the Centre for the Study of Insurance Operations (CSIO). “The BMS can handle it, but the issue really resides with the insurance companies and their legacy systems. It is incredibly expensive for an insurance company to allow this to happen.”

Steve Zylak is the president and owner of Zycomp Systems, which offers the Power Broker BMS. “From what I can determine,” he says, “there has never really been the will at the insurance company level to entertain receiving CSIO standard policy change transactions from BMS systems.”

The ideal scenario for brokers is the so-called “round-trip” transaction that begins in the BMS, is carried out seamlessly via the carrier through an XML transaction and then returns to the BMS with no company portal connectivity, sign-on or involvement.

“The solution has to be management system-neutral, and it has to work for all the systems and for all the insurers, up to a minimum standard,” says Rose. “It has to conform to CSIO standards and it has to meet certain principles. For example, the workflow has to start in the broker management system, and end up there, in order to avoid double entry, and to avoid brokers entering information only into an insurer system and not their own system.”

That is not necessarily a pipe dream, but it is not a near-term solution either, according to several sources. “I think it is actually a quite difficult process to get that kind of integration between a BMS and the carrier in a uniform manner,” says Katherine Evans, the chief financial officer of York Fire & Casualty. “The problem being that brokers do not use their BMS in a consistent way from broker to broker, or even from user to user. It is not clear necessarily when they have fields in the BMS what that is going to translate into with the carrier.”

Instead, in the short term, technologically inclined insurance companies have invested in their own Web portals to process the bulk of policy changes.

“I think we have made progress on our Web portals, but we realize this is not necessarily the ultimate solution,” Ott says. “It is disruptive to the broker workflow, especially if they have to sign-on, key in URLs and look up the policy numbers again. Brokers have said to us: ‘We want a solution that works with our primary BMS and we can make changes from there. Is that askpg12- ing a lot?’Well, in terms of where our systems are, it is not easy to do that.”

Brokers don’t want to train their staff to deal with 10 different company Web sites and portals, says Wasylenko. “Brokers across the country have paid huge sums of money to invest in their BMS, and they want to access information there,” he says. “I think the good news is that BMS vendors have already experimented with the kind of technology that could easily adapt to the broker’s workflow or model. They can all feed policy change data. It is a question of whether what we are feeding is what the other side can handle.”

Indeed, what seems to be emerging is a series of individual vendor-driven solutions that involve a close working relationship with insurance companies, data-testing and validation. These include solutions such as Brovada’s nexisys, Applied Systems’ WARP solution and Customer Software Solutions Inc.’s I-Biz (efforts to contact the latter were unsuccessful).

“For nexisys, we work closely with the insurers to provide this functionality to the brokers,” says Michael Wright, vice president of business development at Brovada. “It is unique in the sense that we sit in the middle between the broker and insurer. We work with the broker to understand their workflow but, at the same time, we are working closely with the insurer to get that information into their back-end system or Web portal.”

CHANGES IN THE INTERIM

Although currently no vendors offer a real-time, round-trip XML transaction for policy change, sources say there is significant progress made in facilitating data transfer between broker and carrier. Whether this involves such technical marvels as scripting, screen scraping or data bridges between BMS and insurer portal, there are real-life examples of “once-and-done” policy changes that provide fast upload, give brokers quick access to information and eliminate data re-entry into the BMS on the download.

“With the Web portals, the broker can push their data through to the portal using solutions like nexisys, do the policy change on the portal and get it back through regular CSIO standards,” notes Zylak, whose Power Broker users can now access nexisys through a working agreement. ” It is better than we have had before, but it is not a real-time XML transaction.”

Wright says brokers who have access to nexisys perform a single sign-on and inquiry transaction in the particular carrier’s portal, but can take it a step further. “We place the user in amend mode in that portal, allowing them to manually make the change. It brings it right to the doorstep and the user is able to make the change. We are offloading that effort on the front half of the transaction, but we also offer the capability of doing the full-blown endorsement on the insurance company side as well.”

So far, Applied Systems has used its WARP technology to achieve real-time XML policy inquiry for York Fire & Casualty. Applied’s Johnston says there is not as much of a leap between inquiry and endorsement as people think when it comes to the data elements.

“Today, within our broker system, we can do an endorsement by clicking on the (WARP) button and in six or seven seconds be transported into the carrier’s Web site,” Johnston notes. “That policy is opened for endorsement; whether you want to call it a data bridge or deep link, or whatever, it is an official workflow. If the broker has a customer on the phone and he or she can get an answer, that is critical. It may not be the paradigm we are after, but it is sure is a nice development.”

Johnston says both York Fire and ING Canada are experimenting with ‘pop-up windows’ in the BMS to streamline access to company Web portals for policy change. “If brokers could open up the window, come out to us, automatically sign on, find the policy and open the correct screen for them, access time could be a minute or so,” says Evans of York Fire. “We are looking for incremental time to shorten the turnaround; that is where we are in Canada right now.”

In the longer-term, Applied Systems is embarking on an ambitious re-architecting of its BMS, which is scheduled to launch in 2009. That effort will include “versioning control and a data audit trail,” according to Johnston. “It is a major overhaul, but at that point we will have the real-time transaction in the BMS that we can send to the carrier. So [carriers] will get the full policy image, stating: ‘This is what the policy should look like as of this date,’ plus flagging what has actually changed. We are trying to meet what the carrier actually uses for data to process an endorsement.”

Others aren’t so sure there will be much in the way of broad longer-term solutions for policy change transactions. Some sources worry the emphasis on ‘real-time’ transactions might take away from the importance of ensuring policy changes are ‘once-and- done,’ which includes the tangible benefits of no data reentry and fewer errors. In other words, these sources say, “don’t let the perfect be the enemy of the good.”

REAL TIME OR ONCE-AND-DONE?

“We should look at what works on the automation side of policy change,” says Durepos,”Brokers who have been able to change their workflow start with the idea that when y ou touch a transaction it is done once and right. The upload in real time from the BMS to carriers that have committed to it is quite possible today, whether inquiry, new business or policy change. At Keal, our systems support download from the carrier back to the BMS in batch mode through CSIOnet. It works well. It is efficient. The advantage gained by having the return trip in real time will cause other problems. In fact, it does not bring a lot of added value to the relationship.”

Campbell questions the value of advocating automated policy changes to the detriment of other tech projects that could make brokers’ lives easier. “If you look at all the tasks that brokers do, and how much money and time it would take to solve this policy change problem, would [brokers] be willing to trade that off against all the other easy places we could streamline their workflow — the so-called ‘low-hanging fruit?'” he says. “This could include things like policy inquiry, binding a policy, downloading renewals 60 days prior and downloading a book of business. We can either do all of those things over the next two years or we can focus on policy change. It is a good question to ask: is that focus a good use of everyone’s time?”

One thing for certain is the prominent and necessary role of XML standards in facilitating any policy change data transfer between insurance companies, brokers and vendors.

“This is really where the CSIO comes in,” says Kaukinen. “We call policy change/endorsement ‘change status’ here, which means we do have the standards in place for this to happen. But the insurance companies have to come to some agreement that they want to allow this. I wouldn’t want to step out there and say: ‘You have to do this now.’ But we know many companies are renewing their legacy systems, and they are using the standards. For the brokers it would have such a huge benefit.”

Wasylenko, who is also a member of CSIO’s board of directors, says he wants to make sure the industry’s investment in those standards through CSIO continues. “It is very important — not to take away from the individual investments vendors have made in their own technologies — that at some point when the transaction is defined and sent to the company, it is up to the company to say: ‘I can accept that transaction.'”

Zylak notes the CSIO standards exist to break down any barriers in these kinds of communications. “We are all supposed to subscribe to the exact same data transaction,” he says. “If we all do, there is not as much of an issue with respect to data interchange.”

For Rose, the CSIO standards may lead to the kind of broad solutions all brokers and insurers need for policy change. “I would like to think that our industry still has the capacity to work together, because that is what this would require,” she says. “Just because the CSIO portal was not successful doesn’t mean that the urgent need for that SEMCI solution has disappeared. If anything, the need is becoming more and more urgent now [because] both company and broker expense factors are under pressure. Certainly, there should be motivation for all of us to put aside our differences and come to the table.”

Others disagree with the ‘industry solution’ notion. They believe the time is right for finding individual approaches that work. “This industry tends to look for the silver bullet, but we need to spend more time rolling up our sleeves and working more closely with individual vendors on real solutions,” notes Ott. “We need to work on getting a tighter connection between the broker systems out there and our Web portals.”

“It is really interesting that carriers are now thinking of the strategic importance of policy and billing change,” says Piller. “What is amazing is how powerful the voice of the broker is becoming. Once you get some differentiation in the types of systems carriers offer, brokers will vote with their feet. For years, there has not been a remarkable difference in the technology offerings of carriers to brokers. Now, you are starting to see some big differences.”

Insurers may not be technology companies, but they can nevertheless create a competitive edge through the use of their own technology, concludes Simpson. “Very few people are going to willingly give that up just so that you can seamlessly transact somebody’s address,” he says. “The same is true for vendors. If one or two mainstream BMS systems can create a market edge by being able to offer more functionality to more markets, the other systems would have to follow or get out of the way.”

———

“If you look at all the tasks that brokers do, and how much money and time it would take to solve this policy change problem, would [brokers] be willing to trade that off against all the other easy places we could streamline their workflow — the so-called ‘low-hanging fruit?’ This could include things like policy inquiry, binding a policy, downloading renewals 60 days prior and downloading a book of business.”

-Kevin Campbell, Policy Works