One of the things I love about insurance is how well the people inside it understand their customers.

Last week, I spoke with two large insurers – one in North America, one in Australia. Both felt product launches had cost more than they should, and both were looking for a more cost-effective way to launch without weakening controls, adding technical complexity, or creating another pocket of shadow IT.

The conversations were similar until we started talking about billing.

Then they could not have been more different.

Two very different views of a good customer experience

The first insurer was clear that account-level billing mattered. A customer may have several products with the company, and the insurer wants to recognize the full relationship. Even if a new line could be launched quickly, it would still need to integrate with the existing billing system and preserve a complete account view.

That was not a technical preference dressed up as a business requirement. It reflected how the insurer thinks about its customers: as people with a broader relationship, not a collection of separate policies.

The second insurer took a different view entirely. It wanted payments split into as many installments as practical, spaced evenly across the policy term and kept in predictable, round-dollar amounts. Its priority was simplicity: insurance should be easy to budget for, and no customer should face one unnecessarily large payment.

Different markets, different customers, different philosophies — and both made complete sense.

The exception is often the point

Billing can look like a small detail during product design. In practice, it can affect deposits, fees, installments, rounding, mid-term changes, cancellations, refunds, documents, portals, and the systems responsible for the customer relationship. A small difference in product philosophy can reach surprisingly far into the tech stack.

That does not mean the insurer is being difficult.

It means the insurer knows its business.

Insurance products are full of decisions like this. They reflect the market being served, the way the product is distributed, the risks being written, and the experience the insurer wants to create. Those differences are not noise to be removed. They are often where the value of the product sits.

Vendors should not force a choice between restriction and customization

This is where software vendors need to be careful. A platform should not force an insurer to abandon a deliberate business decision because the standard product only supports one way of working.

But the alternative cannot be endless customization. Custom work is expensive to design, build, and test — and expensive to carry. Every upgrade, product change, regulatory update, or platform migration can reopen the same code and the same decisions. What looks like flexibility during implementation can become a permanent maintenance obligation.

Over time, the insurer may end up with a system that technically supports the business, but only through layers of bespoke configuration, integration logic, and manual process. That is not really flexibility.

It is deferred cost.

The better model is structured variation

The goal should not be to make every insurer work the same way. It should be to give insurers a clear way to define where and why they differ.

A product model, in plain terms, is a structured description of how the product is meant to work: its rates, rules, coverages, forms, classifications, billing requirements, versions, and market-specific variations. When those differences are represented as part of the product itself, they can be reviewed, tested, and implemented consistently. They do not need to be rediscovered in documents, buried in system configuration, or rebuilt as another custom branch of code.

Standardization should reduce repetition, not erase difference

There is a useful kind of standardization in insurance: the standardization of how product requirements are captured, reviewed, tested, and implemented. It is not the standardization of the business decisions themselves.

The two insurers I spoke with should not be pushed toward the same billing model. Their choices reflect what each knows about its customers. What should be common is the ability to describe those choices clearly, connect them to the systems that must support them, and maintain them without rebuilding the same logic every time the product changes.

That is the balance vendors should aim for:

Preserve what makes the insurer different. Reduce the cost of carrying that difference.