In Blogs, Claim Automation, Claim Management Software, Cloud Computing

By Leo Corcoran, CEO 

 

Just to set the record straight – I am not an expert in software development, but I have been selling software solutions and working with implementation teams for over 30 years. I have seen the good, the bad, and the ugly, and I wanted to share some of my experiences with you.

For the past 22 years, I have been selling and implementing both underwriting and claims software systems within the insurance industry. Ten years ago, we switched our approach to product development. Rather than building custom solutions for each customer, we developed a core product, based on industry expertise and insurance expert input. For each implementation today, we start by implementing the core product, which is configured (rather than customized), to meet the needs of each customer. From here on out I will refer to our core product. Of course, we occasionally develop custom code which is integrated with the core to meet specific requirements.

Reinventing the WheelCyborg hand holding a gear wheel interface 3d rendering

I have worked with insurance carriers, third-party administrators (TPAs), and employers. While these are very different markets, in my experience, they do share common characteristics when it comes to purchasing software systems. These three scenarios present some common themes we’ve experienced with our implementation approach:

What they say: “We have unique requirements where we need to modify your core product or build custom code to meet our specific requirements.”

What they really mean: “We want to take your core product and reimplement our current legacy process.”

What they say: “We want to implement your core product – but we have just defined our requirements and need to be able to implement these to meet our business partner’s needs.”

What they really mean: “We know exactly what we want to do, but we do not what to rebuild our system – we will just modify your core and create a new legacy system.”

What they say: “We have selected your software. Now we will spend the next 3 – 6 months developing our requirements internally, and we will get back to you.”

What they really mean: “Great, we have selected a software solution. Now we will go back to the business to define the requirements.”

There is no need to reinvent the wheel – focus on your core competency, to provide exceptional customer service – and let the vendor focus on building a world-class solution that will bring you in the insurance industry of the future.

 

Core Vs. Custom CodeProgramming code abstract

Over the past 12 years at ClaimVantage, we have both listened to the customer and followed their lead, but this has often led to issues later on.

While software companies do preach delivering core functionality, they will often acquire third-party systems for areas outside their core competence, such as accounts, sales management, etc. and what do they do? They will customize it because they think they are unique! So we can’t blame the insurance industry, as we all tend to customize what are perfectly good software solutions. We may need some enhancements to the core, but no one typically needs the level of custom work we all dream up.

However, after delivering over 50 project implementations, I would like to share some customer survey data and feedback I’ve heard from insurers globally after implementation:

  • “If I knew then what I know now, I would have done it differently.This customer is telling us that they should have spent time up front learning the core product capabilities before getting into project delivery.
  • We should have had better training and clearer communications up front before we created custom code.” Sometimes a customer will rush into a project without training, and this is a big mistake. The core product functionality is usually much better than they think it is, and the software vendor should push back to encourage customers to review the core before implementing custom code.
  • “We want to be told how to implement best practice and be guided through the process.” On reflection, customers often look to their vendor for guidance. I mean, why buy a product if you are not going to leverage the vendor’s knowledge of the market and the best practice processes that have been built up over time?
  • “We don’t feel that we have a good enough understanding of the core software capabilities.” Occasionally customers will realize they don’t understand the core capabilities that well and will often have manual workarounds to do things they think the system can’t do. Switching to an ‘inside out’ learning approach is key to ensure the core product is implemented and set-up correctly, and that your claims department is using it the way it was intended.

 

At the end of the day, if the insurance industry is to stay ahead of technological advancements – which are coming quick and fast – insurers need to have a strategic plan for ensuring they are equipped to deal with these changes.

Now that we have identified some roadblocks to adopting InsurTech initiatives, next week I will provide some suggestions for you and your team to consider before jumping into a claim transformation project.

Recent Posts
RPA Robotic progress automatisation concept illustration. Humans vs Robots. Robot surprising businessmen with idea.Automation Software Technology Process