Cycle Time is Determined Long Before A Claim is Reported

In my most recent blog post, “Don’t Turn Your Claim Department Into Sanitation Workers” I wrote about the hazards of working with bad data, and why it has such a significantly negative impact on claim departments. If we want to improve claim Cycle Times, we must begin with good data (at the source – usually that is the policy profile). Sadly, such is often not the case and claim handlers are left to clean up the mess. 

When measuring Cycle Times, the clock starts to tick when the claim is first reported – the First Notice of Loss (FNOL). From the “Reported Date” until file closure (and sometimes, later), claim departments and individual adjusters, and other stakeholders are judged by how quickly their files churn. Typical CT reports are:

• Front End: Reported Date to Adjuster Assignment 
• Field Team: Adjuster Assignment to Insured Contact/Inspection/Setting Reserves/Estimate Submission/Reporting
  
• Review Staff: Field Report to Claim Review/Disposition/Initial Payment or Denial/etc. 

Pick any two touchpoints during the life of a claim and Cycle Time performance is measured by a benchmarked, expected number of days (or hours, or even minutes). 

Independent Adjusting firms live and die by performance ratings, the most important of which, in the eyes of their carrier clients, is Cycle Time. But is Cycle Time really within their control? Let’s examine the process (of course, this process of reporting claims and assigning vendors has many, many variations, but the point is clear): 

A) Insured calls to report the claim (almost always not to the IA); The clock on Cycle Time  

B) Claim transmitted to the carrier – ideally, this is automated and instantaneous. Unfortunately, we don’t yet have “ideal world” processes in insurance, so let’s take a bad case scenario, which would be the call center/agent operator emails or faxes (yes, this is still a thing) the FNOL to the carrier claim  Add a day. CAT claim, add 2, 3 days, longer – sure, I see this all the time, trust me. 

C) Carrier re-enters FNOL data into the policy system to create a new claim. Assuming this happens timely, we’re still a day or two post FNOL. 

D) Carrier transmits the FNOL and Dec Page to the Independent Adjusting Firm. Add a day. CAT claim? Add a couple. Sure, this transmission can be near-instantaneous, with connected systems and a good dispatching platform, but it is often not so great. So, let’s call it a day, on average... 

E) IA firm receives the claim, and the new claim is automatically (using EDI) created in the IA Claim Sys But wait, what is this EDI you speak of? If you don’t know, there’s a decent chance your office still has a fax machine around – oh my! Sending and receiving claims via fax? Add 2 days. Think email is the way of the modern world? Sorry, you just got dinged ANOTHER day.  

I’ve seen carrier assignment processes (yes, recently), where the FNOL is sent as a PDF in an email. Sounds great, right, what if the carrier system outputs multiple claims in a single PDF? Well, it’s up to the IA to separate those out into each individual file – hope you have an OCR platform. No? Ding, ding, ding – add more delays and likely more data entry errors. Sound familiar? It doesn’t have to be this way! 

F) So, after some number of days (ridiculous, I know, but not at all uncommon and easily avoidable), the IA firm finally has the claim set up in their CMS and ready for the Field Adjuster (FA) to be assigned. Let’s assume the adjusting firm has an efficient process for claims dispatching, and the FA receives the claim the very same day. Don’t forget, it’s already been 2 (best case) to 4 or more days (common), or longer since the claim was reported. Already the insured is anxious and perhaps on the verge of being angry.  They should be… 

G) Next, FA calls the insured. Wait, the cell phone field is NULL. The home phone doesn’t work because the lines are down. What now? Well, let’s send an email while the office tries to track down a reliable phone number. Uh oh – that’s weird, the insured’s email is none@none.com; wait, that’s the same email on all my claims – WTH? How am I supposed to reach the insured? They’re probably already angry – I would be, heck, it has been 5 days since I reported the claim. So much for our goal of contacting the insured within 24 hours. 

Ah, wait, look here, the “Cause of Loss” field has some notes, and I see a phone number and an email address – alas! Well, the number is busy right now. Let me send a text so they can reply. Wait, I don’t have the insured’s permission to send a text. We have laws against that, even outside of California. Should I risk it? What’s the fine for sending an SMS without an express opt-in? How many claims am I risking this way? Let me call my boss…  

If this all sounds goofy, it’s because it is. Unfortunately, this is not rare. In fact, it is quite common – more than we would like to think. Eventually, someone talks to the right people, who have the right contact information, and that all-important Insured Contacted box can be checked – only it’s 5 days later than our benchmark target! Forget about a good CT rating on this claim! Well, we will make it up with a quick inspection, for sure… Oh wait, the Loss Location address is missing! How can this be? Trust me, it’s common – especially when duplicate data entry is necessary.  

I could go on all day about data challenges and examples of why the claims department is consistently rated poorly with Cycle Times? What is wrong with our vendors? Well, probably nothing – it’s your policy data. If claim handlers are not provided complete, accurate, accessible data from the very start, how can we possibly hold them accountable for slow Cycle Times? It’s not right and not fair, and not addressing the issue – the blame here needs to be owned by the folks who are responsible and accountable for the data, at the source.  

In one of my next blogs, I will discuss more of the typical data issues and how these can easily be corrected. This should all happen at the data source, in the policy system, BEFORE the claim is reported. It should be built-into the core system and scheduled to update at least daily. It really is not that hard – it just takes an awareness, a commitment, and a willingness to stop blaming the claim department for Poor Cycle time reports. The problem started way before they got involved…