Insurance Edge caught up with Geoff Webb, (below) Vice President of Product and Portfolio Marketing, at Conga Connection 2026 in Amsterdam. The event was a chance for Conga staff, customers and third party partners, to gather in the EU zone and share the latest knowledge on AI powered software.
There’s so much that platforms and systems can do for insurance brands, regardless of their size and international set-up. IE Editor Alastair Walker wanted to learn more.
IE; Conga has a new MCP ( Model Context Protocol ) server, how can that help insurers get deeper insights when it comes to renewals, say on Commercial cover?
GW; So I think two things there. One is the role of contract lifecycle management as a whole, like as a discipline and as a technology. And the second then is the access to the contract insight, information, intelligence, whatever you want to call it, that you get through something like an MCP server. I think you saw some of the commentary this morning around the slightly haphazard way that many organizations have traditionally stored contracts in the past. They’re all over the place.
IE; I’m sure Lloyds of London have still got original contracts on parchment, written with a quill pen, but times change and even legacy system digital contracts need updating don’t they?
GW; For all companies today the problem is you’re often locking away all of the information that is in those contracts in a form that is extremely difficult to then subsequently access, search, understand, analyze and extract some insights from.
And that’s one of the two big things that’s really been driving change at Conga. One is this move towards much more structured contract lifecycle management overall:
How do I take all of my contracts and put them in a way, store them in a way that’s consistent, rational and available in digital so I can extract information from them.
And then the second thing that we’re seeing, is this sudden rise and almost explosive rise in interest in highly specialized AI related tools for contract search and analysis. You know, they’re essentially both being driven by the same thing, which is the commercial markets in which organizations are operating have become very, very complicated, very fast. But worse than that, they become very unpredictable and volatile.
You know, unpredictability is extremely painful and expensive for pretty much any business. No matter what you do, it’s painful at the moment. And so what’s happening is that companies are saying well, okay, if something’s going to change, what levers, can I pull in order to change direction fast? What am I allowed to do? What are the commitments I’ve made?
What are the commitments that other people have made to my business?
I’ve got vendors out there, can they suddenly change the price on me?
EVOLVING CONTRACTS
GW: And so the thing about contracts is we tend to think of them as a document, you sign it and then you store it. Somewhere, somebody goes and reads it. And the reality is it’s not anything like that. We have customers that have a contract with 50 amendments or more to that contract over time.
So figuring out what is actually agreed and enforceable right now is very, very different from opening up some kind of SharePoint site and just scrolling through a bunch of contracts. So that pressure to sort of say, okay, something is happening, I need to understand, can I respond? If I can respond, how do I respond? That’s driving this desire to digitize things in a rational way.
And the second aspect to this process is then I want to use AI related tools to access what’s in there. So I can then go, this is what you’re able to do. Do this, don’t do that. This is possible. Here’s the risk element. The beauty of MCP servers is that they are essentially providing an open door to get to that sweet spot where contracts can be amended, or renewed, taking all considerations into account.
IE; So the contract is much more of a living thing, it adapts to market conditions, or the client’s needs if their market changes suddenly?
GW: Absolutely, yes. The Conga system is open, so that third parties can come in, in a very controlled way, to get access. That’s the other big thing, by building through an MCP server, you’re able to control access rights you have – you can control who can see what exactly, you have a sort of roles based access system.
So you’re not simply throwing open the door and saying, come read all of our contract.
What you’re saying is this person can see this kind of contract, for this region, for this period of time for this kind of customer. It’s very granular. So it does provide a pathway to extract information for the clients themselves, but for also other organizations coming in.
IE; I can see how that would be useful for insurers in Marine. Say you were insuring cargo, then you would just want certain people to read that contract to do with that specific cargo and that one port of entry insurance, because that’s the only part of the voyage, really, that they have any responsibility for. Correct?
GW; Yeah it’s access to policy wording, okay, that’s a crucial thing for insurers, of course.
DRAWING REDLINES
IE; So in the presentation, I heard the word redline a few times. How can that help insurers, brokers, agents and so on?
GW; So obviously redlining is something lawyers do all the time. They look at contracts and they’re like, no, no, no. But it’s just an expensive, slow process. It’s very manual, requires a very highly trained person. You don’t want somebody making stuff up.
When you’re redlining contracts, it’s also the area where you’re going to get the most initial contention between you and whomever you are agreeing with, because you will not want to agree to certain things that they will, and vice versa. What we’re doing is using the AI tools to essentially do the redlining first for you.
You can set the rules and parameters. Again, if you’ve got that foundational layer, it can understand what has been agreed to in the past, which is huge. So what happens is you can bring a contract in and the AI tools, in our case, it’s a single agentic framework, but whatever tool it is, can read the contract and go, okay, I’m looking for certain things. I found those. I’m going to redline those because they are things that someone needs to go look at.
And typically what you want is that process. You want to say, here are the areas of risk and why do I think these areas of risk? And then you want a lawyer or somebody in our contracts section to review that and make some decisions. However, to speed that process up our system is saying but in the past you have agreed these things with this customer in this environment, again with these sort of things.. So it enables you to very quickly sort of get to a point of agreement, which is the whole purpose of a contract anyway, right? To document a point of agreement where you say, okay, this is what is actually going to happen.
So redlining becomes really important because it helps you eliminate risk, obviously, and manage risk. It also, the process helps you do it much faster and more in a more sort of. I’m trying to think of the right way, a more documented way, a more proven way.
IE; So that redlining process is also going to fit in with local compliance regulations too, isn’t it?
GW; Yes absolutely. That’s the other thing that we see; compliance mandates vary wildly and regulations vary across all areas. And so you want something that can read it and say, well, actually, you’re signing it, you’re a company in this country, the customer is a company in that country. We’re delivering services in both these markets or countries. Therefore, the following things have to be true of this contract.
We’ve seen this work really, really well for complex contracts. It works great. It’s interesting. It can also work really well for very simple contracts. What we’ve seen is customers who have a lot of very Basic Contract Information, or Non Disclosure Agreements, can save time with Conga, sometimes save the deal.
So let’s say, before I can proceed in this conversation with you, somebody’s going to have to sign an NDA. The sales team in that case just pull their hair out because they then have to send an NDA to a legal team that’s already overworked and say, please can you review this and see if I can sign it before I can even have a conversation about the actual contract.
And what we found is we have customers that have done this, but now they can automate that first step. Because the software can very reliably read an NDA. It knows there might be two things it needs to look out for on an NDA. It will highlight them if it needs to be escalated. If not, it can say, this is perfectly fine, proceed.
It’s a huge time saving and for the customer, it’s a much better experience because you can imagine your frustration too. You’re trying to sign up and engage with an organization, you simply want them to agree to an NDA and then they tell you it’s going to be three weeks before I can even look at your NDA because our legal team is swamped with something else that’s super frustrating.
IE; Okay, the Conga compliance screening tool looks useful. How does that integrate with a varied regulatory environment? I’m thinking like Gibraltar or Malta where you’ve got this dual passport system for insurers.
GW; Again what you’re doing is you’re taking the rule set that applies in that environment and you’re looking for certain specific things that will trigger any red lines. The system can be taught any set of rules: This is what you should look for, how things apply, what triggers it in both jurisdictions. And it’s very much the same sort of thing as when you’re teaching it anything else. You should never agree to this. If you see this, you have to flag it. If you see this, it’s okay.
It really comes down to the environmental configuration that you put in place. You’re essentially teaching a system to look for certain things and respond in a certain way. So let’s think of the difference in regulatory requirements between business operating in Texas with an office in California and another office in Illinois, those three are very different in the world of insurance. They have to get approved state by state.
And so as long as you know the environments in which you’re going to be operating, you can set the system such that it understands the State differences, it’s reading, it’s consuming regs and learning both the content of contracts and the environment in which those contracts are operating. So you can absolutely handle that.
AUTOMATED DOCS
IE; Great stuff. Last question, any insights on document automation? How’s does that Conga feature help companies make mid contract adjustments or add extra T&Cs for example, which is something insurers will have to do from time to time?
GW; We see a couple of different uses of document automation. Probably two or three uses. One is the sort of the basic use, which is I create something as an electronic format. You probably saw the example earlier today at the Conference.
If I create a quote, I create a contract and a service agreement and I can then pass that through to a document automation system. It will then create an actual document which will then get sent out as part of an automated process. So it becomes the next step of simply communicating that information.
Now let’s say if you’re insuring a fleet and that fleet had two locations where they stored diesel fuel, for example. So the value of the diesel that’s going to be written off if there’s like a flood has obviously vastly increased in the last two months. So, yeah, so you can just kind of bake that into an existing contract basically and then it’s automated – it can be done in seconds.
Automation is the last step in the process. The really important stuff is I need to pull information from multiple sources. I need to bring it all together and then deliver that in a format that’s compliant. We also see. It’s funny, insurance is one of those areas where we see this issue a lot. There’s always a need to send out large volumes of highly personalized, complex documents.
That can also happen a lot in the healthcare industry. That’s one of the other use cases, which is where you might need to trigger something that says, go send a document to everybody that is a customer about some change that they really need to know about, and that is probably personalized for them. That’s the sort of the more complex use case and that’s what we’re seeing emerging,
So you’re a travel insurer and an airline goes bust, right? So then you’ve got to contact all your customers very quickly and say, that airline’s collapsed, but there’s a plan B and this is it, this is how you’ll get home. You don’t want to do that via what looks like some horribly formatted email that looks, you know, something dashed off at the weekend. But you want to send a professional document that is 100% accurate, auditable and compliant.
AI IS NOT A QUICK FIX
GW: One of the interesting things that we’re seeing is a trend of using AI as a quick fix. Can I assemble this myself from bits of software or data all over the place. I think it’s it’s a dangerous path because it’s using AI as, as a sort of glue to stick things together that weren’t stuck very well together in the first place. And AI is not a glue. AI is an accelerant.
If things are bad, AI will make them worse, very much quicker. So you have to build the glue, the infrastructure, correctly and compliantly in the first place and then you can use AI to then go faster.
You know, it’s funny, we also offer this advice regularly to organizations:
They will tell us, I want to take all of my contracts and put them into a contract lifecycle management system and then teach the system to read and understand my contracts. And we will often say, do not do that. Because you will likely have contracts that you wish you had never signed, that you definitely wish that the salesperson had not agreed to. Or you didn’t review it properly or whatever.
The last thing you want to do is take that very poor information and teach a whole bunch of large language models. The AI will think that’s actually a good contract. You don’t want to do that. So you need to have two things. You need to think very carefully about what kind of contracts you bring in. You can store them sure, but what contracts do I teach the system then?
The second part is, and obviously this is where we feel quite strongly, you can’t simply throw general purpose language models and other tools at contracts and say learn the contracts. Our perspective is what you would expect it to be, which is you build domain expertise in first into the technology so that it can quickly identify that this is not good or you can tell it this kind of thing is bad and it will understand exactly why and how, and therefore how to not use that information to recommend changes in the future.
So again, simply stitching things together by throwing LLMs at them or some kind of agentic platform or whatever it is is a risky approach because when it goes wrong, it’s your problem. Whereas domain expertise built in from the day one is a really effective way of avoiding a lot of the risks that this sort of rapid acceleration. New technologies likely to bring with it.
IE: Geoff thanks for your time, lots to learn in the future for all insurance brands.
Be the first to comment