Part 2 of 2: Why automation across companies is so hard

In part 1 of this series we looked at why insurance forms are so tricky. We made the case that forms, by definition, have inherent problems which require human storytelling to resolve. We suggested that you emphasize that storytelling step in your business.

But we didn’t necessarily make the case that cross-company automation itself was bad. That’s what we will do now.

Problem #1: The economics of commercial lines

Suppose you sell a motor policy for a premium of $1,000/yr. Your customer service reps get paid $40/hr. If a CSR spends an hour per year on this policy, that destroys 4% out of a potential margin of maybe 10%. In auto insurance, margins are vanishingly tight, so those 60 minutes are a big deal. That is why you see extreme automation in motor.

But what if you are writing a commercial policy for a premium of $100,000/yr, with an expected loss ratio of 60%? You aren’t upset if a CSR spends ten hours inputting data. Straight-through automation probably isn’t on your mind at all! The only thing you want is to keep the customer happy so the account stays with you.

Efficiency be damned. There isn’t an economic imperative to automate the $100,000 policy.

Problem #2: Many-to-many relationships

A typical agency might be appointed with 15 carriers. Each carrier might have 2,000 agency appointments. If an agency wants to automate its submissions, they have to do it 15 different ways. And the carrier has to do it 2,000 different ways. That’s 30,000 unique endpoints!

Problem #3: Huge IT effort per endpoint

Getting two systems to talk to each other is hard, even in the age of APIs. To submit forms from one company to another requires conscientious data structuring, validations, and process safeguards. And it has to be done separately for every product. This does not scale well!

That helps explain why most EDI/bordereaux submissions seem like primitive data dumps. It’s deliberate. If they went any further, the complexity of the exchange would explode.

And besides, a lot of the most profitable insurance professionals — the people you want to partner with — do not have sophisticated tech operations at all.

Problem #4: Loose vs Tight Coupling

The engineering concept of loose vs tight coupling comes to play in this discussion. Briefly: your shirt is loosely coupled to your body, but your skin is tightly coupled. A Jeep is loosely coupled to the road, but a train is tightly coupled to the railroad tracks.

Loosely coupled modules allow one side to evolve and change without affecting the other side. Tightly coupled modules, on the other hand, are fraught with dependencies.

Without getting too wonky here… it is hard to create a loose-coupled API for an insurance product. If one side decides they need to change their product offering, it typically breaks something on their counterparties’ side. That is bad news in many types of insurance, where products and coverages require constant tweaking.

Creating a Zapier link between Freshbooks and Stripe is wonderful. But don’t use it as an analogy for the future of insurance: it’s too easy a use case. Connecting an agency management system to a carrier’s system is orders of magnitude more complex.

Takeaways

Call us cranky. Call us pessimistic. We just think that people who gush about end-to-end automation in insurance are trying to do too much. Think carefully about the costs you’ll incur if you go down that road.

We hope this two-part series helps you understand why we at Risk/R chose to focus on the human interactions in insurance. It’s the only thing we’re out to solve. We are not out to disrupt anything. We don’t want to get you bogged down in a months-long systems implementation. We just want to help you do what you’re already doing — better.