ADOPT AI PARTNERS
Insights / insurance

AI for customer support operations in insurance: answering from the policy in force, not from a knowledge base

1 October 2026  ·  8 minute read  ·  Adopt AI Partners
laptop and papers on a wooden desk
Photo via Unsplash

An insurance service desk answers to three audiences through one queue. A policyholder rings to ask whether their cover includes a thing that has just happened. A broker emails for a certificate a client needs before a site visit tomorrow. An agent chases an endorsement submitted last week and still not showing in the portal. Different channels, usually the same small team, and one shared property: the answer lives in a document or a record, not in the head of whoever picks up.

That is why a support agent for insurance cannot be built the way a retail one is. In retail the product is identical for every customer and a help article is the source of truth. In insurance the product is different for every customer, the source of truth is a wording bound to a schedule bound to a date, and the gap between reading that document back and interpreting it is a line your conduct obligations draw rather than a matter of tone.

What the queue is actually made of

Code a month of contacts honestly and the shape is consistent across personal and commercial lines. Document requests dominate: a copy of the schedule, the current wording, the renewal invitation, a certificate, a claims experience summary, a statement of account. Then cover questions, phrased as situations rather than as clauses. Then claim status, which is usually a request for a date rather than for a decision. Then payment: when the collection leaves the account, why it changed, how to move the date, what happens after a failed attempt. Then mid term adjustments, from a change of address to an added vehicle or a revised sum insured.

Almost none of that is a judgement call. Nearly all is retrieval from a record somebody else owns.

The answer is in the schedule, not in an article

A general article about accidental damage cover cannot answer whether this policyholder has accidental damage cover, because that depends on a section selected at quotation, an excess printed on their schedule, an endorsement applied at renewal and a limit that may have been altered mid term.

So the retrieval design has to invert the usual pattern. The primary source is the document set attached to the specific policy: schedule, statement of fact, wording, endorsements, and the administration record holding current state. Generic material has a narrow role, for process questions rather than cover questions. Where schedule and wording disagree, the precedence order is itself a fact the system must hold, since a human applies it instinctively and a model will not unless told.

team meeting around a conference table
Photo via Unsplash

Which version of the wording was in force on the day

This is where most proofs of concept quietly break. Wordings are revised. A policyholder asking about an incident from the spring is asking about the terms that applied in the spring, not the ones published last month. A commercial client who took an endorsement mid term has two sets of terms inside one policy year, separated by an effective date.

Retrieval therefore has to be scoped by policy number and by date, not by product name. The question is not what does the motor wording say, it is what did this policy say on the date the caller is asking about. That means a document store where every wording and endorsement carries an effective period, and an index that will not return a version outside the window. It is unglamorous work, and the difference between a system you can put in front of policyholders and one compliance stops within a week. Every answer should name the document, the version and the date range behind it.

Reading cover back without advising on it

A policyholder asks whether to claim for a cracked windscreen given their excess and an imminent renewal. Two answers sit inside that question. One summarises the excess, the no claims terms and what the policy says about glass. The other recommends a course of action, which is advice, and advice is permissioned work with a different standard of care behind it.

An automated agent has to stay firmly on the first side and refuse the second in a way that is useful rather than evasive. That means a written boundary list, built with the people who own your conduct obligations, covering what the agent may state, what it must hand over, and how it declines. Refusal has to be the trained default for anything resembling suitability, adequacy of cover, whether a limit is enough, whether a loss will be paid, or what the caller ought to do next. A useful refusal still carries the facts: here is what your schedule shows, here is the relevant section, and a colleague will talk you through the choice.

Stating what a wording excludes is reading. Saying a loss is covered is a decision, and decisions belong to claims.

Where is my claim

Claim status calls are driven by silence. The file is progressing, the policyholder cannot see it, so they ring, and a handler stops to read a history aloud.

Status suits automation precisely because it is factual. What stage the claim sits at, what was last received, what the file waits on, who the appointed supplier or loss adjuster is, what payments have issued. Done properly it removes work upstream too, because it tells the caller what the claim needs from them, not only where it has reached. What it must never do is forecast: not when payment will arrive, not whether the claim will be accepted, not what the settlement will come to. Those are handler judgements, and an estimate given on the phone becomes an expectation the file has to break.

printed documents beside a keyboard
Photo via Unsplash

Premiums, direct debits and the money questions

Payment queries look simple and sit on the messiest data. A collection failed, a premium changed mid year after an adjustment, a credit agreement runs alongside the policy, a refund was netted against a balance. The caller wants to know why the amount differs from the one they remember.

A reconciled account view, read back in plain language with the dated movements behind the figure, resolves most of these in one pass. The restraints are specific. Moving a collection date, cancelling a mandate or deferring a payment affects whether cover stays in force, so those are actions with consequences rather than questions with answers. Let the agent explain and prepare; let a person commit. Cancellation for non payment is not an outcome to reach through an automated conversation.

Mid term adjustments and certificate requests

Adjustments arrive constantly and almost all need a rate before anyone can answer. The caller wants a figure, and the figure comes from an underwriting rule that may carry referral conditions. The honest division of labour: the agent captures the change completely, asks the questions the adjustment needs, validates the effective date, lists the documents to be reissued, and states that a revised premium follows. Pricing commitments stay with the system of record and the people who operate it.

Certificates run on somebody else's deadline, which is why they generate chasing. Most requests are reissues of a document that already exists in the correct form, which is clean automation. Requests that change what the document says, naming an additional interested party, extending a territorial limit, confirming a liability limit for a contract, are underwriting questions in a service costume and should be routed as such.

Hearing a complaint while answering something else

Complaint language rarely arrives labelled. It appears in the middle of a document request: this is the third time I have asked, nobody called me back, I was told something different at renewal. The obligation attaches when the dissatisfaction is expressed, not when somebody classifies it, and the exposure sits in the contacts that were answered helpfully and never recorded.

Detection should run across every channel alongside whatever else is happening, and when it fires the behaviour changes immediately: stop attempting resolution, acknowledge, route to the people who handle complaints, and pass the full contact with the triggering passage quoted. Set the threshold to over detect and let a person dismiss with a reason, because a dismissal you can see is defensible and a complaint nobody logged is not.

Serving brokers and agents on the same desk

Intermediaries contact the desk differently: across many clients, in portfolio terms, wanting documents in bulk, and asking where a submission has got to more often than what a policy covers. They also hold different entitlements, which makes identity and permission the first problem rather than a detail: resolve who is asking, which agency they act for, and which policies that agency may see, before retrieving anything. Chasing falls away faster here than anywhere else: a broker who can get the document and the submission status without waiting stops sending the follow up emails that fill the mailbox.

Where AI fails here

It fails when retrieval is pointed at generic product material rather than the specific policy documents, because the answers sound right and belong to somebody else. It fails when the document store has no notion of effective dates, because it will confidently quote a wording that was not in force. It fails on the deliberately fuzzy question, where a caller describes an incident in a way designed to extract a coverage view, and a model trained to be helpful gives one.

It fails on identity. These conversations expose medical history, claims history, addresses and payment details, often with third parties involved in the same claim, and an agent that answers before verifying who is speaking is a disclosure incident rather than an efficiency gain.

It fails on the long tail of policies written on legacy systems, acquired books and schedules that exist only as scans of varying quality, where the data to answer from is not reliably present. And it fails whenever a confident tone stands in for a cited source. If an answer cannot name the document and the version behind it, the right output is a handover with the file prepared, not a sentence that reads well.

Scoping a first deployment sensibly

Start where the answer is unambiguous and already recorded: document reissues, claim stage, account position, portal access. Keep cover questions in a read only mode that quotes the schedule and the section, then hands over. Keep adjustments, cancellations, payment changes and anything resembling advice as preparation work for a human, with the file assembled and the questions already asked. Then measure handovers that arrive complete rather than deflection rate, because a handover that spares a handler a long retrieval beats a conversation that ended without the policyholder being helped.

Tell us what your teams keep redoing

One conversation is enough to say whether there is a system worth building, and what would make it fail.

Describe your process