I hear it all the time: “Brokers are lazy.” It’s almost always said by an underwriter who’s disappointed that a specific broker hasn’t done something that the underwriter wanted them to do.

Quite often, brokers are accused of laziness in response to the realisation that none have submitted risks through the judgemental underwriter’s amazing new, custom-built, (incredibly expensive) quote and bind portal.

Let me say from the outset that, after a long while in our industry, I’m certain that brokers are no more prone to idleness than anyone else in EC3. For the most part, they are simply very, very busy. And whilst they’re now only very rarely made to queue in the Room for the privilege of speaking with an underwriter, they still have a great deal to do.

It is therefore understandable that brokers do not wish to enter the same information 20 times into 20 quote-and-bind portals in 20 different formats to suit 20 varying sets of data requirements. It is vastly more efficient for them to send a single e-mail to a score of underwriters, amending only the recipient’s name each time.

For brokers to deliver top-notch client service, speed is critical. They are assessed, among other factors, based on their swiftness of response. Clunky portals slow them down (which is why aggregators rule the internet space in the UK consumer market).

Further, brokers clients – the insurers’ clients – don’t care why it can take weeks to complete coverage. They see the intermediary, the underwriter, the carrier, and anyone else in the chain simply as ‘the insurance people.’ Slowing down the broker makes everyone look bad.

Of course it also makes sense for brokers to get submissions off their desk and transformed into coverage as quickly as possible. Every moment a proposal spends on their desktop is money wasted. It’s not lazy to wish to maximise returns. It’s good sense.

Yet still it happens. I am asked to build broker portals all the time, but unless they’re for an underwriter with a highly specialised product, in our syndicated market I almost always advise caution, because I know what will happen:

• The MGAs or carrier will spend a small fortune to build a Q&B portal from the ground up, thinking it will save them time and money because brokers will enter all the risk data they need directly into their platform in exactly the format they want.
• They will launch their shiny new Q&B to a nonplussed broker market with much fanfare and hoo haa, often at a reception where the intended (not lazy) users consume the proffered high-quality hospitality copiously.
•  

Sorry, there’s no third bullet point, because nothing happens next. Brokers don’t log on. Even the ones who registered at the launch cocktails do little more than have a poke around the portal the next morning.

The problem isn’t laziness, it’s platform design.

Attempting to reduce your rekeying costs by enlisting brokers to format your risk data is not the way forward (and in any case, one real and very helpful forthcoming application of AI is to facilitate disparate data ingestion into multiple standards. That, mercifully, is set to make redundant the endless song and dance about data standards. But that’s another story.)

It’s more fundamental. To get their clients’ insurance technology right, developers need to understand and respect the functions, roles, processes, needs, goals, and wants of all the actors in the relevant chain.

Underwriters need to ensure that the developers they use will make it a no-brainer for all relevant brokers to send them every submission, because it is so incredibly simple to do so. No more effort than changing the name on an email.

Failure to do so is liable to lead at least one player to reject the script and walk off the stage. Then the whole production is usually cancelled. The producer – the underwriter who paid – has no choice but to blame others on a massive wasteful spend.

Usually some brokers are lazing around nearby to take the hit…