The 8 Ingredients for a Successful Claims System Implementation

As your company migrates to a new system, keep in mind these 8 ingredients to ensure your claims system implementation is a success.

#1 – Choose Correctly – Popular Vs. “Right For You”

The first place to start is with system selection. Choose software that is right for your organization’s needs. Every claims department has a unique profile. Consider factors such as:

1. the kind of exposures handled
2. the volume of pending and new claims
3. the number of users
4. intake and coverage review processes
5. the degree of outside access

The interplay of these factors determines what is right for you. Specific questions should be answered in detail, such as:

• Are we a quick turnaround processing shop?
• Is each claim a complex project that involves sophisticated tools of investigation and analysis?
• Is speed our primary objective or is it critical that we get every aspect of coverage, investigation and legal analysis correct?
• Are we a self-insured organization about to purchase a commercial carrier claim system? If so, why are we doing that when there are systems that cater to the self-insured?”

These are important considerations.  The choices of “off-the-shelf,” custom tailored or home-grown systems should be made carefully and depend largely on your organization. The smoothest implementation of the wrong system is just a giant step backward.

#2 – The Right Project Team with Sufficient Time

The challenge here is that many organizations with a need for a new system are hampered by a lack of time. And, the lack of time is often caused by a bad system. If your internal point-person and others responsible for working with developers are pressed for time because they are working a claim load at 120% of capacity, the project may fail. The project team needs sufficient time to think critically.

A new system offers great opportunities to put a superior process in place and support the process with tools and information to guide claims adjusters. A team pressed for time may simply make decisions to “get through it.” Or, they may not have adequately addressed the details needed for developers to design the best solution. Some companies hire outside parties to assist in this important area because they lack the white space to spare key people for prolonged projects.

Perhaps equally important is forming a team that has input from underwriting, marketing, accounting, and risk control. Creating a cross-functional team will ensure that the system’s inputs and outputs spread the advantages across the company.

#3 – Internal Staff With “Know-How”

In addition to the time resources needed, the internal team must have a near mastery of the company’s claims department. This is one of those cold and harsh truths. If the lead person does not fully understand how the claims system must operate efficiently to serve not only the claims department but also underwriting, accounting, subrogation, litigation management, and the agent network, the system is not going to live up to expectations.

An implementation is challenging for even the most experienced and knowledgeable claims professional. The sheer number of issues to be adequately addressed is daunting. The depth of detail of many of the issues is enough to make you wish you got into rocket science. A good project team must have the deep knowledge to see the project through to the point of universal success.

#4 – Internal Buy-In

Knowledge and time are necessary but not enough. The internal group responsible for the implementation must be fully committed and hungry to go through the process. The “buy-in” is necessary because perseverance can only happen when the person quarterbacking the implementation believes in it. System implementations fail when the lead person simply does not see the benefits of a new and improved solution. There is no faking your way through a project like this.

#5 – A Software Vendor That Understands Your Specific Business

It’s not just the internal challenges that can sink your implementation. The project manager on the vendor side must take painstaking steps to fully and completely understand the industry, the business, the people and processes that surround the contemplated new system. This requirement is not an easy task. Everything counts here. The vendor should perform a thorough review of the organization’s departments, processes, forms, and templates.

Conversely, the software buyer must be willing and able to educate the vendor by highlighting the fine grains of distinction that separates their business from the generic. The process takes time and should not be rushed to meet a deadline.

#6 – Project Momentum Management

Some projects are truly massive and take a long time to complete. But if a project lingers too long with little or no direction or progress, the chances for failure rise. Multi-year projects are not uncommon. If they involve the focused effort of 10 to 20 key people, staff turnover is a real risk.

System implementations can be like surgery where you don’t really know what you have until you open things up and look around.  For that reason, initial planning and mapping can be helpful but will not necessarily prevent issues of scope-creep, indecision, miscalculations and delays.

#7 – Consider Recent or Future Business Changes and Direction

Was the goal of the new system to solve yesterday’s problems?  Be sure the system being implemented has the capacity to move the company forward. Some implementations replace an old data storage system with a new data storage system that holds more data. A small step forward but not exactly the system of the future. Rethink the workflow and business processes that are currently in use.

Do this before you imagine your new system’s features and not after.  Then, you will have the freedom to create and implement a high impact system for the business you want to become instead of the business you were 5 years ago.

#8 – Think Deeply About the Proper Scope and Limits of the New System

Should this system be all things to all people?  Or, do we unbundle and create the perfect claims system that integrates with the policy system?  Is it more or less problematic and secure to share this platform with external users?

There are many important scoping questions that should be thought out in light of what your business needs. Everyone talks about scope, but few truly know how to contain it properly.  Limits of the project cannot be chosen arbitrarily. It’s not helpful to build just the front half of a car. If that one extra module in the system will complete a workflow loop so that there is a common location for related information, by all means, build that module into the system.

A good example here is the implementation of a coverage analysis module inside of the same claims system that holds information about the facts of the claim, the claim notice and the policy details. Inclusion of this module inside the claims system eliminates needless duplication.

Conclusion

System implementation is delicate. The project’s requirements should be defined clearly while also leaving room for flexibility. Most systems end up requiring far more customization in both number and degree. It is important to develop a strong relationship among the people involved. Your RFP may prove out who’s best at a beauty contest, but your company requires accurate function and elegance.

The post 8 Ingredients for Successful Claims System Implementation appeared first on Direct Claim Solution.

Before you answer this question, think about your organization’s claims system design. Does it properly highlight the important information you need? And, does it present that information in the right order?

Scorebug Graphics

One of the most watched television networks in the world changed its scorebug graphics for college basketball. In 2017, ESPN introduced a new scoring banner in its lower third. This change caught my attention immediately. By the way, who knew the banner on the screen was called a scorebug? This banner is incredibly important to anyone watching sports. It is hard to imagine how we watched sports before these were introduced. Just the same, I wonder how claims were handled before software gave us a proper screen display.

ESPN’s new scorebug graphic is a reminder to software designers and system buyers. The new graphics heavily highlight the score of the game in large bold font. What’s wrong with that you ask? Well, there was a simultaneous decision to put the team names in a smaller and less prominent font size. So, the thing that pops most visibly is the Score.

The Argument

I have no doubt there was a heated conversation about this change. One side of the argument probably went like this: “The score is what people want to know most!  We must bold and “biggie size” the score of the game. The score is critical.”

It would seem like a great argument. No doubt that the score is really important. It’s the item on the banner that likely changes the most other than the ‘time-remaining’ in the period. It is probably the most frequently sought information while watching.

The other side of the argument which clearly lost the battle at ESPN probably went like this:

“Wait, yes, I agree the score is really important and should be prominent and visible. But, here’s the problem. The score is only meaningful once you know what teams are playing. The ‘who is playing who’ question is the first question. Only when that is known and held in one’s memory does the score matter. Score is only important when you know who is playing. We cannot throw two large numbers at a viewer like a hot potato and ask them to hold that information in their head before they have a place to put those numbers. The question of ‘who is playing?’ is primary. If I just hand you the numbers “48” and “36”, you will drop them to the ground unless I first give you a place to put them.”    

I have no doubt this argument was faced with a seemingly valid, but flawed response by the more powerful personality in the room. The response likely went like this:

“Once you know the teams playing from your first inquiry, you then only need to know the score from that point on. So, the graphic of enduring value, as viewers flip channels, is the score. We are going with a large, bold font that shouts over the team names and that’s that.”

Something about the new graphics definitely bothered me. And, from the feedback I observed online, it bothered others too. I did not immediately connect the dots on why, but I was bothered. It was an ‘interior and abstract discomfort’. Then, it hit me. ESPN got it wrong. As my 9^th grade English teacher would say, “the actor comes before the action” when writing in active tense. That may seem philosophical and even biblical at some level, but the world is right when we first know “Who”.

Order Matters

In software design, the principle holds true.  When you look at your organization’s claims software system, you get so much more than just information. You get a glimpse into what the designer felt was most important. You learn about order and importance with regard to functionality.

If your claims system was not designed by a person intimately familiar with claims handling, they would tell on themselves with a poor layout. They will design a system with fields out of order. They will fail to prominently display key information leaving an impression of equality between the primary and the subordinate topics. Use of the program will be awkward, causing wasteful navigation.

Getting It Right

The proper ordering of information to facilitate function is the ultimate sign of intelligence. It would have been interesting to be in the room at ESPN when they debated the new scorebug graphics. Does order matter? Tell me what you think or send me an example of your system design success or failure.

The post Scoreboards and Claims Systems Design – Why ESPN Got it Wrong appeared first on Direct Claim Solution.