Plan claims systems for the fortnight after the typhoon

Every September, the technology teams at Japanese non-life insurers watch typhoon tracks as closely as their claims departments do. The questions asked in those rooms are about the first night. Will the contact centre's lines hold? Will the website stay up when tens of thousands of households try to report a damaged roof within a few hours? Can the telephony provider add capacity in time? I have sat in those rooms at two insurers. The questions are reasonable, and they are the wrong ones to plan around.

The first night is a front-door problem. It is visible, easily measured and largely something that money can buy. What decides whether policyholders trust an insurer after a storm is what happens over the following fortnight, when reported claims must be assessed, approved and paid. That is a throughput problem, and spending on the front door can make it worse. It lets us accept more reports than we can process, and it tells customers we are dealing with their claim when the claim is sitting in a queue.

The first night is the easy part

When the September 2018 typhoon crossed Kansai, Kotonami's systems mostly held. I was not at Kotonami then; I was running technology at a direct motor insurer in Tokyo, dealing with the same storm through flooded cars at the ports. When I joined Kotonami two years later I read its review of the event. The reporting website had failed twice on the first evening, and those failures took up most of the review. One table near the back told the more important story. Kotonami received about 61,000 claims in three weeks, against a normal month of roughly 9,000, and took 74 days to pay 80 per cent of them.

Almost none of those 74 days was caused by the website. Claims waited for an adjuster to be assigned through a spreadsheet the claims department kept by prefecture. A loose roof tile waited in the same queue as a collapsed warehouse. Staff lent by other departments could not log in to the claims system for nine days, because their access had to be requested, approved and set up through the ordinary process by the same small team that was keeping everything else running. Payment files to the banks came out of the nightly batch, sized for an ordinary month, which overran into the morning.

Each of these was a technology problem, but none of them appears when a board asks whether the systems stayed up. They appear when it asks how long the oldest unassigned claim has waited, the number of people able to work on claims each day, and the time from approval to money in the policyholder's account. Those are the numbers I now ask for first, before the availability figures.

Capacity is people who already have permissions

The main lesson I took from that review is that catastrophe capacity in an agency-based insurer is mostly people, and that the job of technology is to let more people do useful work safely within hours rather than weeks. Between 2021 and 2023 we built what we call surge mode. It has four parts, and only one of them is about computing power.

The first is a short reporting form, hosted apart from the core claims system, that captures what we need to begin: the policy, the address, the kind of damage and photographs. It feeds the core system in controlled batches, so that a flood of reports cannot slow the screens on which adjusters and payment staff depend. The second is a desk-assessment route for small claims, below a limit set by the head of claims, through which an adjuster can settle a damaged roof or a broken window from photographs and a repairer's estimate without a visit. That decision belongs to claims, not to my function; our job was to make the route auditable. The third is about 900 surge accounts for staff from other departments, retired adjusters on contract and selected agency staff, created in advance, restricted to defined tasks and kept switched off. The fourth is a payment run that can be repeated during the day when the disaster headquarters asks for it.

The surge accounts caused the hardest argument. Our head of information security pointed out, correctly, that dormant accounts are a favourite route for attackers. We agreed that the accounts would exist but could not be used until two named managers activated them after a disaster headquarters had been declared, that every holder would carry a hardware token issued in advance, and that access would lapse automatically after 45 days. We rehearse activation twice a year, and the rehearsal is the expensive part: it takes a day from several hundred people who have other work to do.

The test came at the end of August 2024, when a slow typhoon crossed Kyushu and then Shikoku. Kotonami received about 38,400 claims in three weeks. The surge accounts were active within six hours, the oldest unassigned claim was never more than four days old, and we paid 80 per cent of claims within 23 days. I should be honest about the comparison. The claims department changed its own procedures over the same years, and the 2024 storm was less severe for our book than the one in 2018. But the difference was not luck, and the cost of the programme was ¥640 million over three years, a third of what we had been asked to spend on a larger mainframe configuration and an overflow call centre.

Five questions after every storm

I am wary of advice that turns one insurer's programme into a rule, so I offer boards questions rather than an architecture. After every significant event, a board or its risk committee can ask management five things.

How many days did it take to pay half and four-fifths of claims, and how does that compare with the last comparable event? How old was the oldest unassigned claim at its worst? How many people were working on claims each day, and how long did it take to give the extra ones access? Which step held claims up longest, and was it a system, a rule or a shortage of people? And did anything done to go faster create a risk that has not yet been measured?

The last question matters more than it sounds. After every large storm in Japan, some roofing contractors visit households offering repairs that insurance will pay for, and some of the resulting claims are inflated. Faster settlement makes that easier to exploit. We sample photograph-settled claims after each event, and after the 2024 typhoon we reopened about 2 per cent of them. A faster process that does not check itself is only a faster way to pay the wrong claims.

None of this replaces resilience at the front door. Websites and telephone lines must stay up, and we test them every year. But I would ask any insurer's board to look past the first night. The policyholder whose roof was torn off does not remember whether our website was slow on the evening of the storm. She remembers how many weeks her family lived under a blue tarpaulin, waiting for us.