Ecosystem Q&A: A Conversation with VIPR’s David Sweet

AdvantageGo is excited to partner with VIPR to include its best-of-breed solution within the AdvantageGo Ecosystem. VIPR makes data-driven, business-critical processes for delegated underwriting faster and more effective.

David Sweet is VIPR’s Chief Commercial Officer, responsible for new sales as well as existing accounts. He sat down with David Benyon, asking the questions for AdvantageGo, to discuss how the two insurtech companies came to be working together – and what clients stand to gain through this ecosystem collaboration.

DB: David, thanks for joining me to discuss the rationale behind the Ecosystem relationship between VIPR and AdGo. In your own words, how did this meeting of minds between the two organisations come about?

DS: I’ve been working at VIPR for approaching three years, but I’ve been working within insurtech for nearly two decades. In some ways this is a small market, and you tend to know some likeminded people, even if we’ve previously competed against each other. I’ve known Ian Summers, Global Business Leader, AdvantageGo and Bob Riddler, Account Director, AdvantageGo for a long time, and it really begins with personal relationships.

It’s fair to say that many suppliers have a consistent idea of ‘what good looks like’. However, what has historically not been good is that a typical insurance company will need to buy a number of different platforms to meet their needs. For example, they’re going to need a policy administration system, a claim system, etc, etc, and VIPR provides the data collection, data processing and analytical piece for Delegated Authority (DA) business.

Historically, it’s been left to a client to work out the integration capabilities between different systems, to work out for themselves how two different platforms can combine to deliver on the business challenge that you have. When I say combine I think this is an important point.

First, there’s the technical integration aspect, so that the systems play nicely in an IT sense, for instance, to ensure these systems can talk to each other, so you’re not having to re-key the same data. The other aspect that often gets overlooked is that normally we’re only solving part of the problem ourselves. There’s always a bit – whether it’s 5% or 25% – that falls to another system.

I’ll give a specific example of this problem, relating to what we do. At VIPR, we collect bordereau data. However, at some point, that will need to be compared, if it’s a Lloyd’s business, with what premium and claims messages from the bureau. We don’t have that information, so the only way of meeting that requirement would be for us to send it to a policy admin system, in the case of AdGo, Subscribe. That would then be compared with the messages coming from the market, and finance can use that for credit control purposes.

Conversely, if you look at the Underwriting Workbench that AdGo is developing, it’s focused on open market business, submissions, triage, data augmentation, and analytics, to help underwriters write better business. But in the DA space, it’s not doing the collection of data from third party cover-holders and TPAs third party administrators. Similarly, there’s a gap there. Now, of course you could try and build one massive system or a collection of systems that does everything that the market does, but it would be an enormous undertaking. Which is why the alternative of an Ecosystem partnership works so well.

DB: Imagining there was no Ecosystem, and systems remain fragmented, who would do the brunt of the integration work between two different systems, assuming they can talk to each other, but still need to be linked?

DS: Usually, it means employing a system integration company, as a third business, so another relationship to manage, and more money going out the door for the insurance company client. They will have their own people. That means the risk of a conflict on a big project, as to who’s doing what, that things can fall between the gaps, and suppliers can then point at each other to say ‘it’s not us, it’s them’.

And I think the bit that the market struggles with most is that they’ve also got to work out how these systems combine to do what the client wants, what it is that they need to move their business forward.

The idea of the Ecosystem, fully realised, is that we solve all of these problems. The client can buy something that solves the problem they have, without having to articulate what the solution is to that problem, or how the systems talk to each other to deliver on that value.

We want to be able go to the market to say: ‘this is what we think good looks like’; ‘this is the business challenge we think you have and this is our combined solution to it’; ‘this is how our systems combine to deliver you that functionality’; and ‘you don’t need to worry about how these things integrate, because they’re already integrated’.