An insurance chatbot earns its keep in five jobs: answering policy and coverage questions, taking first notice of loss and reporting claim status, qualifying quote requests for an agent, handling renewals and policy changes, and explaining insurance jargon. It works when it answers only from the insurer's own policy wordings and help center, shows the source on every reply, and hands the conversation to a person when the documents do not cover the question. It fails as a scripted menu, and it fails as a general model guessing at cover. Start with questions and intake. Leave transactions and decisions for later.
Done that way, the chatbot answers at 2 a.m. on a Sunday, gives the same answer to the same question every time, handles hundreds of conversations at once, and leaves licensed staff with the conversations that need judgment.
Why the obvious insurance chatbot fails
The obvious approach is a menu bot: five buttons, a dozen canned answers and a phone number at the bottom. Customers try it once. Policy questions do not arrive as menu options. They arrive as "Does my homeowners policy cover a laptop stolen from my car?" and the menu has no path from that sentence to page 14 of the policy wording.
The second obvious approach is a general language model pointed at the website. It answers the laptop question fluently, and sometimes wrongly, because nobody showed it the policy. In insurance a wrong answer about cover is not a poor experience. It is a complaint with a transcript attached.
There is a quieter failure, and it is harder to spot. The failure Wonderchat's support team sees most often is not invention. It is retrieval pulling an archived policy and answering from it correctly: the citation is real, the answer is wrong, and nobody notices for weeks. Insurers revise policy wordings regularly, and every revision leaves an older version somewhere in the content pile. Those superseded wordings are the most dangerous documents an insurance chatbot can read, and the first thing to remove.
None of this is a capability problem. Across 1,309 complaints in reviews of 18 vendors, pricing was the biggest theme (211), then setup (197), then UI and bugs (166), trust (128) and stale knowledge (38). Buyers do not fail because the model cannot read. They fail on what they pay, how long setup takes, whether they can trust the answer, and whether the content stays current. Plan for those four and the reading takes care of itself.
Five jobs an insurance chatbot does well
Each of these is a question or an intake. None of them is a decision.
1. Policy and coverage questions
This is the bulk of the volume: what is covered, what the deductible is, whether another driver can be added, what the cancellation terms say. The chatbot answers from the policy wording, the product documents and the help center, and shows which document the answer came from so the customer can read the clause. When the wording does not cover the question, it says so and offers a person. That one behavior separates a usable insurance chatbot from a liability.
2. Claims intake and status
A chatbot cannot settle a claim and should not try. It can take first notice of loss: what happened, when, where, which policy, photos or documents, and a contact number. It collects the same fields in the same order every time, which is exactly where a hurried phone call misses things, and hands the file to a claims handler with the transcript attached. Connected to the claims system, it can also answer "where is my claim?" without a phone call. The decision stays with the handler.
3. Quote requests and lead capture
Prospects ask the same questions as policyholders, but they leave if nobody answers. The chatbot answers the coverage question, then asks the qualifying ones: vehicle, property type, cover level, ZIP code. The details go to an agent or into the CRM. It should not quote a premium unless it is wired into the rating engine. A chatbot that invents a price has created a complaint before the policy exists.
4. Renewals and policy changes
Address changes, adding a vehicle, switching payment dates, requesting a copy of the ID card. These are the requests that fill a contact center and need no judgment. The chatbot explains what the change involves and either collects the request for the policy team or, where the policy administration system allows it, submits the change directly. Renewal reminders belong here too, with the chatbot ready for the questions a reminder triggers: why did the premium go up, and what changed in the wording.
5. Explaining the jargon
Deductible, indemnity, endorsement, subrogation. A customer who does not understand the words cannot buy with confidence or claim correctly. The chatbot defines each term from the insurer's own glossary, in the customer's language, and links to the page that explains it. It is the cheapest of the five to set up, because the glossary usually exists already.
What to leave out of the first version
Lists of insurance chatbot uses, including an earlier version of this guide, often add fraud detection, risk assessment, underwriting decisions, wellness coaching from wearables, compliance advice and personalized product recommendations. Leave them out. Fraud and risk scoring run in the back office on data, not in a chat window. Underwriting is a decision an insurer must be able to defend, which a chatbot cannot do. Telling a customer which product suits them is advice, and advice is regulated. Keep the first version to questions and intake, and add more only when the first version is clean.
How an insurance chatbot works
The mechanics are the same across vendors, and knowing them makes the demo questions obvious.
Retrieval, not training. The chatbot does not learn the policies. It indexes the policy wordings, help center, website and uploaded files, retrieves the passages that match the question, and writes an answer from those passages only. Ask any vendor to show the retrieved passage next to the answer.
Source on the reply. Every answer should name the document it came from. In a regulated product this is the audit trail, and it lets the customer check the clause themselves.
A clear "not in the documents". When nothing matches, the chatbot says so and offers a person. A chatbot that always answers is guessing some of the time.
Handover with context. The conversation moves to a person by email, live chat or as a ticket in the help desk, with the transcript attached so the customer does not repeat themselves.
Connections to the systems of record. The CRM for leads, the help desk for tickets and, with more work, the policy administration and claims systems for status and changes. The chatbot sits on top of these systems. It does not replace them.
Security that matches the data. Policyholder data is personal data at minimum, and health data for health and life products. Ask for SOC 2 Type II, GDPR terms, where the data is hosted, and whether a HIPAA business associate agreement is available.
One thing a vendor may claim that is not true of these systems: that the chatbot "learns from every conversation" and improves on its own. It improves when someone adds or fixes the content it answers from. Everything else is marketing.
How to roll one out in five steps
Pull the repeat questions. Export three months of tickets, emails and call reasons, and sort them by frequency. The questions that repeat are the chatbot's first job. The rare ones can wait for a person.
Assemble the content and retire the archive. Current policy wordings, product documents, the help center and the glossary go in. Superseded wordings come out of the index entirely. Do not rely on the model to prefer the newer version.
Write the handover rules. Decide which topics always go to a person (complaints, vulnerable customers, anything about a decision), which become a ticket, and which the chatbot resolves. Test the handover path end to end before launch.
Test with real questions. Take 50 questions from the export, in the customer's own words, and check every answer against the policy wording. Count the ones where the chatbot said it did not know. Those are missing pages, not bugs.
Measure resolution, with the denominator. The industry's usual rate counts every conversation that did not become a ticket, including the customer who gave up and phoned. A rate without a denominator is a guess wearing a number. Count conversations resolved end to end as a share of conversations evaluated, and read the list of unanswered questions every week.
That list of unanswered questions is the whole maintenance plan. Missing pages show up as unresolved conversations. Out-of-date pages rarely do, because they show up as confident answers, which is why step two matters more than it looks.
Insurance chatbots already in use
Three insurers and one health vendor show the pattern in production. Each description follows the company's own public account.
Zurich UK: Zara
Zurich UK launched Zara, its claims chatbot, in 2018, built with the insurtech Spixii. It takes first notice of loss for motor and property claims at any hour and passes the details to a human claims handler. Zurich later extended it to SME and commercial customers. It is use case 2, done as intake only.
GEICO: Kate
GEICO added Kate, a virtual assistant, to its mobile app in 2017. It answers policy and billing questions and points the customer to the right place in the app. Its value is routing: the customer reaches the right screen without a menu.
SWICA: IQ
SWICA, a Swiss health insurer, put its chatbot IQ live on its website in July 2019 after a pilot in 2018, according to SWICA's own announcement. IQ answers questions about SWICA's products, health insurance basics and the company. When it does not understand, it asks, and it offers live chat with an employee or a callback. That is the "not in the documents" behavior from the list above, shipped by an insurer.
Sensely
Sensely is a vendor, not an insurer. Health plans license its voice-and-avatar assistant so members can check symptoms and find covered services.
For patterns outside insurance, the collection of customer service chatbot examples covers retail, software and services.
Where Wonderchat fits
Wonderchat's AI Customer Service Agent is built for the first job on this list and the intake parts of the others. It answers from the insurer's help center, policy documents, website, uploaded files and past tickets, shows the source on every reply, and says so when the content does not cover the question. It hands over to a person with the whole conversation: as a ticket or by email on every plan, to a teammate in live chat from the Basic plan, or into Zendesk or Freshdesk if you keep them. The questions it could not answer land in the review inbox, and once you answer one, it answers it from then on. For quote requests, the AI Sales Agent asks the qualifying questions, routes the lead and sends it to HubSpot from Basic, with a calendar link inside the chat for the prospect who wants to talk to an agent.
The unanswered-questions list matters more in insurance than in most markets. In September 2026 Wonderchat read every promise on twelve competitor homepages. On 10 September, none of the twelve promised to show the questions it couldn't answer. For a regulated product, being able to see the source behind every answer, and the questions it couldn't answer, is the difference between a chatbot you can audit and one you hope is right.
About 75% of evaluated conversations on Wonderchat are resolved without a person. The number that matters to an insurer is its own, measured on its own conversations with the denominator stated.
It works in 40+ languages. Security: SOC 2 Type II, GDPR, EU-hosted in Frankfurt, HIPAA BAA available. SAML single sign-on is on the Enterprise plan, and PII redaction and a Salesforce connection are available too. Pricing starts with a free plan that refills 50 AI replies every month, no credit card needed, then paid plans when you need more. The meter is AI replies, not seats. 80% of Wonderchat agents that go live do so the same day. The work that takes longer is retiring the archive in step two, not the setup.
Where Wonderchat is the wrong choice
Wonderchat answers and hands over. It does not complete transactions inside an insurer's core systems: it will not bind a policy, change a deductible on the policy record, move a payment date or read a live claim status out of the claims platform. An insurer whose first requirement is a chatbot that completes those transactions should look at Ada, Decagon or Sierra, which take multi-step actions against back-end systems, with an integration project and a price to match. And an insurer already running support in Zendesk with a short list of questions may find Zendesk's own AI answers them well enough, because it is already installed and the tickets are already there.
Verdict
Start with questions, not transactions. Put the chatbot on policy and coverage questions and claims intake first, where the content already exists and a wrong answer is caught by showing the source. Retire the archive before launch. Measure conversations resolved end to end, not conversations that did not become tickets. Add transactions only once the unanswered-questions list has stopped growing, and buy an actions platform for them if the volume justifies the project. For the questions-and-intake layer, Wonderchat is built for exactly that scope, and the chatbot pricing guide shows what the alternatives charge for the same layer.
Frequently asked questions
Can an insurance chatbot process claims?
It can take first notice of loss, collect the details and documents, and report status when connected to the claims system. It should not decide a claim. That decision needs a handler who can be named in a dispute.
Is an AI chatbot allowed under insurance regulation?
Rules differ by country and product line, so check with compliance first. The safest pattern: answers only from approved documents, the source shown on every reply, every conversation logged, and no advice on whether a product suits the customer.
How much does an insurance chatbot cost?
Wonderchat starts with a free plan of 50 AI replies a month, and paid plans for more are metered on AI replies. Other vendors bill per seat or per resolution. Compare the pricing models before comparing the headline prices.
Can it handle health insurance data?
Only on a platform that will sign a HIPAA business associate agreement and can redact personal data. Wonderchat offers a HIPAA BAA, is EU-hosted in Frankfurt and provides PII redaction. Keep health data out of any chatbot that cannot do both.
What should the chatbot do when it does not know?
Say so, offer a person, and log the question. That log is the list of pages the insurer still needs to write. A chatbot that answers every question is guessing on some of them.
Before choosing a vendor, the guide to AI knowledge base chatbots explains how retrieval from your own documents works and what to test in a demo.
