The insurance industry runs on relationships. That is not a flaw or a complaint because it is largely why the sector works as well as it does. But that same instinct, when applied to technology buying, can quietly lead brokers into decisions that cost far more than they should.

This is not about brokers making poor decisions. Most procurement processes are thorough and involve the right people. The issue is more about the habits and assumptions that shape those decisions before the evaluation has even started. And from our observations, these three patterns recur.

1. Choosing from familiarity, not from evaluation

Resistance to change is real in this industry, and it is not always irrational. Senior teams who have worked on the same system for years have built their workflows, their processes and their institutional knowledge around it. They are familiar with it. Switching carries genuine disruption, and they are right to weigh that carefully.

But there is a more interesting version of this pattern. Sometimes a broker stays with an older system not because of habit, but because it does one specific thing very well. For instance, deep integration with a local market is something that a newer platform cannot yet replicate. In that case, staying put is a rational decision, not a failure of ambition.

The question worth asking is whether your evaluation process can actually tell the difference between those two scenarios. Are you staying with the familiar because it genuinely serves a critical need, or because the alternatives were never seriously looked at? The two can look identical on the surface, but they lead to very different places over time.

2. Choosing based on current pain points, not future ones

When brokers evaluate technology, they typically build a requirements list. Current pain points, existing workflows, and what the team needs right now. Vendors are scored against it, and the one that fits best tends to win. It is a sensible process. It is also one that only reflects the present.

The problem is not the process itself. It is what the process cannot capture. You can only score a vendor against requirements you already know you have. So the system goes live, performs well, and two years later the business wants to move into a new product line or launch a different distribution model. The vendor quotes a significant project, a timeline measured in months and a cost that was never part of the original plan. That is not a vendor failure. It is a buying decision that optimises for day one and defers the cost to later.

McKinsey, in its analysis of core system decisions in insurance, makes this point clearly: vendor selection is a strategic decision, not a procurement exercise, and growth readiness is a defining criterion, not a secondary one.

The practical fix is asking different questions during evaluation. Not just what this system can do today, but how the vendor has supported clients through changes they did not anticipate at the point of signing. What the roadmap looks like. What a significant scope change actually costs. Those answers will tell a decision-maker far more about long-term fit than any feature list will.

3. Treating go-live as the finish line, not the starting point

This does not happen because brokers make bad decisions at the point of purchase. It happens because the technology decision gets filed away as complete the moment a system goes live. The implementation wraps up, the business settles in and nobody owns what comes next. The vendor keeps building. The market moves. The gap widens quietly until it becomes a problem too large to ignore.

The brokers who avoid this tend to share one habit: someone internally owns the platform after go-live as a business responsibility, not an IT task. That person tracks what the vendor is releasing, identifies what is relevant and revisits the setup as the business changes. That is not a complex process. It is simply treating the contract signing as the beginning of the relationship rather than the conclusion of it.

Before signing, it is also worth evaluating what that post-sale relationship will actually look like. The vendor support model, how actively they develop the product and how customers feed into the roadmap matter as much as anything on the feature list. A system that is slightly less complete on day one but actively developed and well supported will, over time, outlast one that was impressive at demo and ignored thereafter.

None of this requires a more complex procurement process. It requires a different approach to what that process is actually for. The brokers who get the most from their technology investments tend not to be the ones with the biggest budgets. They are the ones who treat the buying decision as the start of something, not the end of it.