Where AI Fits in the Insurance Lifecycle, Stage by Stage

Welcome

Jill Zakarian, BevayaHi everyone. Thank you for logging on for today's session on how AI supports every stage of the insurance lifecycle. We welcome back those of you who've attended our sessions in the past and if it's your first time with us, we're glad you could join in. I'm Jill Zakarian and I will be your host for today.

And with that, I'm thrilled to be joined by our co-founder and CEO Chaz Perera. So Chaz will walk us through the insurance lifecycle stage by stage, looking at what AI does at each point, and what it hands off next. So without further ado, I'm happy to hand things over to you, Chaz.

Most teams know AI has a role somewhere, fewer can point to where

Chaz Perera, BevayaAwesome. Thanks, Jill. So, most insurance teams know AI has a role somewhere in their operation. Fewer can point to where.

The insurance lifecycle as one continuous piece of work

Here's the insurance lifecycle. As you know, a policy is one continuous piece of work. Every stage inherits whatever the stage before it produced. So today, we're going to walk through this lifecycle stage by stage, from a broker's email through to a renewal.

We'll see where AI fits at each point. Then we'll mention what stays the same no matter where you are in it and close on how to pick where it starts.

Submission intake: broker inbox monitoring and ACORD form extraction

All right. Submission intake is where the lifecycle starts. Whatever comes out of that inbox is what underwriting has to work with. So, how can AI help?

AI helps in two ways here. The first monitors broker inboxes, classifies what comes in, and pulls data out of ACORD forms, supplementals, exposure schedules, etc. It also runs a clearance check, checking whether the risk is already in in-house or another broker's working the same account. It screens against appetite, flags anything missing, back to the broker and hands the underwriter a one-page risk summary along with a clean data set.

The second is ACORD form extraction. It reads any ACORD form, checks the fields against your own rules, and hands off clean data ready to use. I separate these two because one's about the mailbox and one's about the form. Most teams, by the way, have a problem with both.

Through monitoring inboxes and capturing data, one of our US property casualty carrier customers doubled their submission volume they could handle, without actually adding any headcount, and cut document processing times by 87%. Their underwriters didn't get faster. The work in front of them just changed. If your underwriters start the day sorting through email instead of reading risk, this is a strong stage to focus AI efforts.

It's also a good place to focus because errors here compound. A limit typed wrong in the inbox is wrong in the quote, wrong in binding, and wrong on the renewal comparison a year later. Nobody catches it because everyone downstream assumes the person upstream got it right.

Underwriting: loss run normalization and exposure schedules

A clean submission becomes a risk to evaluate. Picture the underwriter opening the file. Nothing's missing. Nothing needs to be chased down.

They're not starting by fixing the file. They're starting by deciding what it's worth. In underwriting, AI does two things before an underwriter even opens the file. First, it cleans up the loss history.

It reads loss data across carriers, sorts out the trends, does the math on totals, total incurred, frequency, severity, and flags big claims or gaps. If you've ever watched someone rekey five years of losses out of three formats, you know why this matters. Second, it reads the exposure schedules on the file, say the Statement of Values, hazard schedule, drivers, fleets, etc. in whatever format they arrive. It pulls out the details on each, cleans them up, and flags anything unclear for a second look.

So, both surface the numbers that drive the quote. Beyond that, AI can predict the risk using patterns and past data, sometimes real-time data like driving habits to give the underwriter a starting point. and it can look at the property itself using photos or aerial photography to catch things a form alone would probably miss like roof damage or site hazards. So, do files arrive incomplete and get worked twice at your organization? If so, that's worth addressing with AI.

Quoting: where AI stops and the underwriter prices the risk

Now, we move into quoting because AI already cleaned up the loss history and the exposure data. Quoting starts from numbers ready to price, not data still being assembled. We don't recommend AI price the risk by the way. The underwriter owns the price, the terms, and the appetite call.

Think about where AI stops and a person picks up. That line matters because of accountability. A price is something your organization has to explain and stand behind and that belongs with a person. There's still opportunity to use AI at this stage though.

AI can predict a price using historical trends as an early estimate and updating as new information comes in. It can also sort and follow up on leads, pointing out which ones are worth an agent's time and speeding up early conversations. And, it can generate a quote through conversation, letting someone describe what they need in plain language, and skip the transactional or traditional form.

Binding: policy comparison and contract drafting

So, the underwriter made the call on price. AI helped get the numbers ready. With that, let's turn to binding. At binding, there are three places AI does real work.

First, it can check policies against each other, comparing terms side-by-side and flagging material differences before anything gets locked in. Time matters here, by the way. A difference caught after binding means an endorsement, a coverage dispute, or an E&O conversation. Caught before, it's an avoided cost.

If you've ever had to unwind a misbound policy, you know what that's worth. It can also draft the contract itself from the accepted terms, and review the language against required clauses before the commitments are finalized. Do differences between what was quoted, and what's about to get... .. do differences between what was quoted to bind get caught after the fact? If that's the case, that's a strong place to prioritize AI.

Because any difference has already been caught and fixed back at bind, issuance can generate the contract from a record that doesn't need double-checking. With that, let's actually dig into what that issuance process looks like.

Issuance: document assembly and checking the contract against the bind

At issuance, AI shows up in two places. It assembles the final paperwork, pulling the bound terms into the official format and producing a contract ready to send. And, it checks the final documents, reading the issued contract back against what was bound and catching any mismatches before the customer sees them. If issued documents are still checked against the bind by hand or with tools that need constant reconfiguring, AI is definitely worth a closer look here.

Now, because AI already checked the issued contract against what was bound, servicing and claims starts from a policy record they can trust right from day one. So, let's talk about servicing and claims which as we know run at the same time.

Policy servicing: certificates, endorsements and premium audit

We're going to start with servicing. Endorsements rekeyed by hand out of an email is an example of servicing. Premium audits that come out differently depending on who worked them are an example of servicing. So, if you are running servicing, none of that should be news to you.

What changed is AI can now handle it reliably, not with rules-based tools that break the moment a format shifts. AI shows up in a few places. It creates certificates from policy data, it's validating the additional insured language, and delivering that to brokers and insureds. It's reading and validating endorsement requests, drafting the change, and routing it for approval.

And, in premium audit, it's classifying all the audit documentation like the payroll and classification data and it goes back to the policy holder for what's missing. So, by automating certificate creation, a top insurance broker we work with, cut manual COI processing efforts by 80%, and hit a 97% accuracy. Essentially, they eliminated over $2 million in annual BPO costs. Beyond that, AI can chat directly with the policy holder on things like billing and coverage anytime.

It can also help your own staff find answers faster from company knowledge instead of searching manually. If certificates are piling up, changes depend on someone manually retyping them, or audits depend on who's working them. In these instances, AI can be especially helpful. All right.

Claims: loss notice through payment

Claims touches every part of a loss. From the moment it's reported to the moment it's paid. When a claim comes in, AI can read the loss notice, and whatever documents come in with it, it sorts and classifies them, catches duplicates, and confirms the policy was actually in force on the date of loss. Anything time-sensitive like a legal deadline gets flagged immediately, instead of sitting in a queue.

From there, it's about figuring out what's actually owed. AI can check the claim against the policy to confirm coverage. It reads through the medical bills and vendor charges, looking for errors and catching legal demands before their deadlines slip by. It can even use past claims to estimate how costly this one is likely to get.

And, instead of handing the adjuster the entire file, it hands them a short brief. Once it's time to pay, AI can match each invoice back to the claim. It compares that against your rates and approved limits and catches anything that smells like over-billing or a duplicate before it's routed for approval. Since everything downstream depends on getting the file assembled correctly, using AI for claims indexing can make a big difference as well.

By automating that, our customer, Eastern Alliance, cut the process from five days to under an hour. 100 times faster with 60% fewer items their team has to review, by hand by the way. If your adjuster spends more time assembling the file than deciding on it, a claim use case is worth putting near the top of your list for AI.

Renewal: package assembly and at-risk accounts

Now, because AI already tracked every endorsement and claim against the live policy, renewal starts with a complete loss history, not one that you have to rebuild from scratch. And, AI helps in a few ways during the renewal process. It prepares the renewal package, it pulls the expiring policy data, refreshes exposures and loss runs, and assembles it for the underwriter. It compares expiring terms against what's being written and shows what the differences are year-over-year.

It also predicts who might not renew, identifying at risk accounts and suggesting ways to keep them, like a rate review, or added coverage. Renewal needs the same thing intake needed by the way, just with a year of history behind it. It's the same exposure and loss data submission intake produced 12 months ago now with a year of experience added to it. There's a practical benefit here.

When the renewal package assembles itself, your underwriter gets more time on the accounts that you're at risk of losing. And that's usually where the money is. If renewal gets rebuilt from scratch every year instead of building on what's already known, then that's a real AI opportunity.

What stays the same: confidence scores, traceability, audit trail, human in the loop

Okay. So, whenever AI is doing the work, it works the same way every time. Every result should come with a confidence score. Every answer should be traced back to its source.

Every action should be logged, and a person should still be making the final call. Here at Bevaya, this is what responsible AI looks like in practice. Specific features, it's not a slogan. Every result carries a calibrated confidence score so you always know how much to trust it.

We have this concept of Highlight Mode which shows you exactly where on a document or where within a page an answer came from. So nothing is a black box. And, we provide a full audit trail of every action the system took, so that you can always reconstruct what happened and get perspective on why and Human-in-the-Loop review is built into our platform. Not something we decided to add afterwards.

So, a person is always positioned to catch and correct things before things go out the door, before something can go wrong. So, if you want to learn more about these features or have a full library of AI Agents, we've dropped some links in the related content widget for you to check out. That consistency, by the way, is what lets you start anywhere in the lifecycle, and trust what's underneath.

How to choose where to start

So, where do you start? You don't have to tackle the whole lifecycle at once, and frankly, you shouldn't. Most teams start with one piece of one stage, and build out from there. We've done this over 120 times across carriers, brokers, and TPAs, and all of them started small.

As you think back through everything we covered, ask yourself, where does your team spend time on work that isn't really judgment-based? Where do you find yourself doing the same work twice? Where does a handoff create the most friction? And, what's the one queue that never gets cleared?

Whichever use case comes to mind, that's the starting point. And, whichever one you start with, remember the next one gets easier, since it is inheriting clean work.

Session wrap

Okay. Well, thanks everyone for joining us today. We've covered a lot. So, let's see if we can answer at least a couple of questions before ending the session.

So, with that, I'm going to hand it back to Jill.

Jill Zakarian, BevayaThanks, Chaz. That was great. All right, Chaz, let's dive into some Q&A. Let me pull up our queue.

Q&A: Does the line at pricing move over time?

Okay, Chaz. So, the first question I see is that you drew a clear line at quoting AI doesn't price a risk. Do you think that line moves over time or does it stay fixed?

Chaz Perera, BevayaSo, the thing to clarify here, is that what I was describing isn't really a technology limit. It is much more about accountability. This is not a capability question. Even if a model got good enough to price risk really really well, someone has to turn around and explain that price to the policyholder or prospective policyholder, to their representative, the broker or agent, potentially to a regulator, potentially to a reinsurer.

A person really has to stand behind the price, the decision, the risk. I don't know that that line is going to move a lot. Maybe 10 or 20 years down the future, but right now I think that line would hold, Jill.

Q&A: Slow process or error-prone process, which do you fix first?

Jill Zakarian, BevayaOkay awesome. All right, Chaz. Next question I see is what if two use cases both feel painful but for different reasons, one slow, the other is error-prone. How do you choose between them?

Chaz Perera, BevayaFirst, those are two different types of pain points. Not suggesting they couldn't both be happening at the same time, but to me they are two different types of pain points. Slow suggests a capacity problem, where being error-prone is a focus problem. When we talked about submission intake and getting the data clean so that the quote would be clean, the bind process would be clean, and the renewal a year later would be inheriting clean data.

I think it makes sense to lean towards fixing errors first, because fixing it pays off more than once. It is a compounding thing. Getting it right at ingestion will pay forward in a way that you might not recognize in the moment. Fixing the slow stage helps that stage, but fixing something that is error-prone helps everything downstream and that's just way more valuable.

The balance here is how big a problem those errors are. If they are small, then maybe fixing the capacity problem is the most important thing. The data suggests that for every dollar of premium that's underwritten, about eight cents is left on the table because of errors. So there is high value in getting errors fixed.

Q&A: What happens with handwritten notes and bad scans?

Jill Zakarian, BevayaAll right, next question. And Chaz, it is kind of a long question, so if I have to repeat it, no problem. A lot of what you describe sounds like it depends on documents being read correctly in the first place. What happens when the incoming document is genuinely messy, handwritten, notes, a bad scan, or something outside the normal format?

Chaz Perera, BevayaThis is why we have confidence scoring built into our platform. Insurance documents are pretty messy. Messy from a format perspective, messy from a data perspective. Some of you might be getting handwritten documents still.

Tables don't always line up, or they are nested tables. The thing we found is that a generic AI tool trained on general web data has never really seen that range or that broad a series of problems. So it tends to guess very confidently about what it's seeing. What insurance-specific AI does a really good job of is, because it is seeing real documents, it knows the difference between something unusual and something just worth flagging.

So, if there was a bad scan or handwritten notes, that is not automatically a problem. Messy shouldn't stop it. What changes really with our AI, because it is trained on so much insurance, is precision. We are checking confidence on a field-by-field basis, not a document-by-document basis.

So, something that is unclear in one place might get cleared up later because we saw some other correlation we could make to help inform or improve that particular field. That is the real difference. The system handles what it is confident about in a really rich way, just like humans do. Like, oh, wait a minute, that makes sense now, or that doesn't make sense because of this other thing I saw.

That's the real benefit of insurance-specific AI. If it is not sure, it is going to hand that off to one of your experts to manage and approve. And that becomes part of a richer learning loop.

Q&A: The most common mistake when expanding past the first use case

Jill Zakarian, BevayaAwesome. All right. Next question. If a team starts with one use case and it goes well, what's the most common mistake they make when they try to expand from there?

Chaz Perera, BevayaThis might sound strange, but sometimes folks move too fast off a single win, right? A use case goes really well, so your confidence builds and your immediate instinct is to expand to three or four at once, from just one early success. That makes sense in a way. Early success feels like the proof, and suddenly it feels easy now.

But use cases are different, documents are different, edge cases are different, frankly end user expectations are different. So, if you are going to go from one to four use cases at the same time, you have to think about each of those things. Are the documents different? Are the edge cases different?

Are the expectations different? Are the decisions different? The way to overcome this is that, until you have a few under your belt, and you recognize what the patterns are, it is a simple fix. Do one, get successful with that one, then move to the next one, do the next one, and maybe do one more.

And then if you have three and you have three that you built confidence around, now you can start to duplicate or multiply your efforts and go faster.

Jill Zakarian, BevayaAll right, awesome. Okay, we are going to wrap up here. We appreciate you all making time to join us today. Also feel free to email us any questions you may think of later at resources@bevaya.ai.