What Connected Sensors Change About Property Insurance

A supply line behind a washing machine starts leaking at two in the morning.

In the ordinary version of this story, nobody knows. The water runs for hours, or for days if the house is empty. By the time somebody sees it, the floor is gone, the ceiling below is going, and what happens next is a claim — handled competently, paid promptly, and entirely after the fact. Everyone involved did their job well. The outcome is still a wrecked kitchen.

The connected-property version changes one thing: a sensor on the floor notices the water within seconds, and something has to happen with that fact.

I have spent a good deal of time building the software in the middle of that sentence, for a home-telematics provider whose sensors reach policyholders through property insurers. The sensors are the part everyone photographs. They are not the part that decides whether any of this works.

The alert path is the product

A sensor that detects water and reaches nobody has done nothing at all. It has converted an undetected leak into an undetected leak with a log entry.

So the engineering that matters is the chain: sensor to hub, hub to network, network to platform, platform to a notification, notification to a person who can turn off a stopcock. Every link is somewhere the thing can silently fail, and most of them are unglamorous. Connectivity that holds up in a basement. Push infrastructure that delivers at 2am. A hub that reconnects on its own after a router reboot, because nobody is going to re-pair it.

The parts that break in practice are almost never the sensing. They are the delivery.

Onboarding decides how many sensors are real

The second unglamorous truth: a device that will not pair is not in the programme.

A carrier can distribute a hundred thousand sensors and have a materially smaller number actually monitoring anything, and the gap is almost entirely onboarding. The policyholder is not an engineer. They are standing in a utility room with a phone, and the interaction has a short fuse — if it does not work, the box goes in a cupboard and the programme paid for a device that watches nothing.

This is why connectivity issues on new phone hardware are worth treating as urgent rather than as a support ticket. We had exactly that: hubs pairing normally on Android and failing on the newest iPhones, caused by a vendor library that had no fix available. Every week that ran was new policyholders — the ones with new phones, so disproportionately the engaged ones — unable to activate a sensor their insurer had already paid for and shipped.

One address is not one property

The third thing, and the one that most often limits a programme's reach, is the data model.

A platform built for houses tends to assume one address means one hub. That holds until somebody wants to cover an apartment building, a school or a commercial site, where one hub cannot physically reach every place a sensor needs to be. If the model ties a hub to an address, covering a building means registering it as several addresses — and then it is no longer one property to anybody looking at it.

That is not a feature gap. It is a relationship that encoded an assumption about who the customer was. Fixing it is what lets a programme move from single-family homes to the multi-unit and commercial property where a lot of the exposure actually sits.

What the evidence looks like

The honest answer to "does this reduce claims" is that the evidence is promising, it is worth reading properly, and you should be suspicious of anyone who states it more confidently than that.

The client I work with has published a multi-year actuarial analysis of their own programme, run with a major insurance consultancy across six carriers and more than 175,000 policy years, reporting fewer and less severe water-loss claims among households with an active leak sensor, along with a modest retention effect. That is a real piece of actuarial work rather than a vendor claim, and it is the right shape of evidence to want.

It is also a study of one programme, by the people who run it. It is a reason to take the category seriously and to run the numbers on your own book. It is not a number to put in a business case as though it were yours.

What this actually asks of an insurer

Very little of the difficult part is insurance.

It is device onboarding that survives a real utility room. It is an alert path engineered for the notification arriving rather than the reading being taken. It is a property model that can describe a building. It is the integration that gets an event out of the platform and into the systems where underwriting and claims can see it — because telematics that never reaches those systems is a customer-experience programme wearing a loss-prevention badge.

The interesting shift is smaller than the marketing around it and more durable. Insurance has always been the business of knowing about risk before it becomes a loss. Connected property changes when you find out — and the engineering between the sensor and the person who can act is where that either happens or quietly doesn't.