Tag Archives: Start-up

Putting Puzzle Pieces Together and the Challenge of Creating a New Claims System

Posted on by
1

Creating a new claims system should be easy with no legacy, right? Not so fast!

One of the great things about going to work for a start-up insurance company with a lot of venture money is the idea that you can build everything from scratch. No legacy of losses, a clean balance sheet, and no system constraints. The problem was the company did so well right from the start that policies were being written as fast as they could print the paper. The company had made the initial decision to buy an old established (green screen) application to handle back office processing. The thought was it was the most robust system on the market and as such should be able to handle multiple lines of business. Nice thought but we were a specialty lines operation and the thing just couldn’t do everything that it needed to do. Individual departments knew this and started to build their own mini-systems to get the work done. Suddenly the clean legacy free environment developed a legacy problem.

So where did this leave us in claims?

Unlike underwriting or finance, we did not have to worry about a huge influx of claims from the start so time was on our side. Despite the time we had, we were not involved in the underwriting system initiative early on. We would later learn what impact this would have on everyone. There is more to this story, but needless to say involving all key stakeholders potentially impacted by a system implementation is critical early in the design process. Nonetheless, we had a handful of claims and time to decide what type of claims system we were going to use.

Option 1 – License a System From Our Vendors – Sounds like a good idea?

The first suggested claims system solution was that building a system would be too costly and we should just “rent” a system from one of our Third Party Administrators. Another nice idea in principal that proved to be a not so nice in practice. While everything seemed usable during the demo and initial discussion phases, it was not until we started to actually get down to trying to integrate the application that problems arose. The system was really designed for a TPA and not for a carrier. The meant it did not handle policy data well and in turn would be difficult to adopt. At every turn the so called “customizable” options were leading us to create work-around after work-around. Unless we wanted to pay for fields to be customized, this option was not going to work.

Option 1 – Scrapped.

Option 2 – Buy a Comprehensive System – Another nice idea that was not going to happen

Simply put, this option was way to expensive, and with no true policy system in place, an implementation was going to be even more difficult than “renting” a system. Additionally, at the time, robust claims systems did not exist on the market as much as they do now and the ones that did were an all or nothing approach. We had a half a dozen claims and buying a system that could handle more than we would could have needed for lines of business we were never going to write didn’t make any sense either. So, needless to say –

Option 2 – Scrapped.

Option 3 – Build Your Own – more a decision by accident than by design

Now time was not longer on our side. Claims were coming in and we needed to do something. Ah the wonders of excel. With a spreadsheet all we could do was keep a record of claims and money spent, but in no way provide a claims management system. The controls, and making sure various required financial reports could be provided, was a continual problem that got worse the more claims and transactions we had. Like other departments in the organization I decided to build my own system out of necessity. This began with my limited skills in MS Access and then continued with the hiring of a an actual Access developer.  I was off to the races now and the claims department could build something it could actually use.

Option 3 – I think we’re on to something…

So now let’s build – It’s time for reality, a plan and a process

Developing is very simple when you have no rules, no team and no plan. It was me and a developer. I told him what I wanted to see and he built it. Life was good.  Now claims were coming in faster and we had more users on the system and people now wanted my data. Developing this way was not going to work and I was in for a rude awakening with the assignment of a business analyst. This was all new to me at the time and my days of walking over to the developer’s cubical and telling him to stop what he was doing to add a new feature were over.  In walked much needed process and structure. The reality was I did not really think we were going to build a system from scratch – I thought I was building a stop-gap measure. The stop-gap was over and the system was now going to have to go to an entirely new level.

With structure came direction and a strategic plan was developed. We had to get the basics taken care of which included a more stable database that could handle multiple users, and a new front end that would allow us to make changes quickly as well create new features and connections to various parts of the organization. A development plan emerged and a procedure for enhancements, development, testing, and implementation took shape. The system was no longer a department database, but a corporate application.

I had to come up with a name for our new application and so the Claims Processing Administrations System, cPAS, was born. The puzzle pieces were beginning to fit.

Start-up – Lets get down and dirty and pitch in on everything

Posted on by
Reply

On day one as Vice President of Claims for Arch Insurance Company I found myself working in cramped space in Lower Manhattan where the CEO shared an office with others and the head of Professional Liability Underwriting found a happy home in an electrical closet. Arch was rapidly growing its underwriting and was binding new policies at a breakneck pace. After getting my credenza in the hall (with a shared phone as there were no more phone lines) I was handed the entire company’s log of claim files to get to work. This consisted of one property loss, and one notification of a casualty incident. It was easy to think that claim counts would be low for a while but that would change quickly. I was hired to manage and concentrate on the administrative operation, which would free the technical claims staff to focus on strong claims handling from the inception.

We needed everything including a claims system, best practices, litigation management, a way to manage and store claim files and methods for making claim payments. Given that we were a public company, all had to be done with strong controls in mind as well. It was a different challenge every day. We concentrated on things at first that would have little impact later. It was easy to go down paths that later became muddied or ones that should never have been followed. It was not known how quickly claims would grow and what types of policies were going to be written. At first we affiliated with Third Party Administrators to handle our intakes and possibly handle claims if needed over time they handled little direct matters and even less as it relates to intakes (they did handle claims our program business which were a whole other set of problems). In some ways we were driving blind as everything changed so quickly all the time. A decision was made that we needed to outsource a call center so off I went to research and meet with various providers. I never believed we would be the type of operation that needed to handle that many calls and over time my belief proved true and that project correctly fell by the wayside. This was common in claims as well as other departments. Decisions were made, paths were followed, change happened, and the path changed.

Trying to connect all the moving parts in the early days was difficult. Each group needed to accomplish tasks quickly and there was no time to stop and connect with everyone. Underwriting needed a clearance and binding system, finance needed a system to bill and account, actuarial needed a way to manage IBNR and rate new clients and we needed all of those things to happen to manage claims. Our path to a claims system also stopped and started. At first we were going to “rent” a system from one of our TPA partners. Then we were going to use a legacy system that had been adopted by underwriting and actuarial as a stopgap (we were a start up with legacy problems already). The path to what would become a home grown state of the art system will be the subject of another posting, but needless to say, like many, we started with a spreadsheet.

Change happened daily but we needed to be ready to handle the technical aspects of running claims. We began to hire heads of claim departments – one for Healthcare – one for Property and one for Directors & Officers. Of course there was no place for them to sit. You knew someone was being hired when someone walked in with a tape measure trying to figure a way to squeeze a new desk in. It was a fun and interesting time for everyone and those who thrived checked their egos at the door and rolled up their sleeves and pitched in where needed. Despite a rich investment, we might as well have been working out of someone’s garage. As they say – it was the best of times.