Please note that due to confidentiality reasons, I can't show the actual screens for this project. If you would like to see samples of wireframes that I have produced, check out my process and deliverables page.

GOAL:

The goal of the project was to shorten the time it took to take a loss report, thereby saving time. 

  • Customer Goal: Get claim filed quickly and get on with life
  • Business Goal: Reduce the handling time of each phone call and reduce the number of person hours required for this function

My role:

Lead Data Analyst and Interaction Designer. I designed and constructed the report process and helped with the flow of the process. 

 Photo from unsplash.com

Photo from unsplash.com

Project Flow:

The team assigned to this project were all somewhat familiar with the claims system used in taking reports, but we needed to get reaquainted with the adjusters who would be using the software daily, so we sat with them, listening to calls to get an idea of call flows. We had an idea of which claim types we wanted to focus on , but this helped confirm they were the right opportunity. We compared notes and decided to go forward with the process.

We next went through the current process, questioning every question, looking to identify those that were truly needed. I pulled the data to see how each question was answered to help inform our decision. 

After multiple rounds, we had the abbreviated set of questions that seemed so feew in umber, but per the data were the critical questions. It was now time for feedback.

We worked with a designer to mock up the new flow to aid us in our focus group conversations. Insurance is a very diverse product and varies from state to state with regards to rules, regulations, and even some terminology used for coverages. We knew we had to keep these in mind, so once we had the mockup and data, we flew to all of our regional office to ensure the new system would meet their needs. We also took this time to start addressing concerns that regional management had about the questions we removed. There was a lot of pre-existing biases and beliefs that we had to overcome. It was great to be able to challenge those beliefs with data. We also talked about the way out of the loss report, in the event that we needed to have a full report taken. 

The adjusters unexpectedly got excited for the new process, helping with the later implementation. There were gaps we did identify in this process and a few regional variances we discovered we would have to include.

We worked with IT to get the system built and decided on testing in two regions, with us being on site to manage the roll out. We were excited to see the performance because according to the testing, we had significantly reduced the time for a certain number of claims. 

The system roll out went eerily smooth. The adjusters picked up the system quickly and after a few minutes of questions, jumped right in. We waited. I pulled reports. We waited some more. 

A floor manager called a meeting with us to see how things were going. I'll never forget him exclaiming "We have no customers on hold! My adjusters aren't busy. This is crazy!" Those are phrases you don't typically hear in a call center.

As we would learn later, the timing of this project couldn't have been better. The plan was for this process to roll out slowly companywide over the course of a year. Sadly a major storm struck, resulting in hundreds of thousands of claims that fit into this process. We had been in 4 regions at the time but the process was rolled out overnight countrywide. It was both terrifying and exciting. 

The roll out ended up saving the company so much time with regards to the storm damage. It was fulfilling to see something I had helped built be released and be successful.

What I learned:

  • Be sure to have data to back you up. Even in an established, ingrained culture, you can overcome beliefs if you have the facts to prove it
  • Include the target customers early. They feel like they've contributed and you get the bonus of generating buzz early.
  • Focus groups can get some answers but they aren't always the best. they are useful for managers in seeing the whole flow, however. For this project, I wish we would have built a prototype to test