Contents
If you run a claims operation, you have almost certainly been told you can build this yourself. You have an IT team. You have a telephony vendor who would happily sell you a voicebot. The conversation is the visible part, it demos in a quarter, and it sounds like the future.
I want to be honest about that, because we have spent a decade building the part that does not demo. The AI that talks is the easy 20 per cent. The 80 per cent that makes it safe to put in front of a real claimant is the project. Getting that ratio wrong is the most expensive mistake a claims leader can make this year.
The 20 per cent is real, and it is genuinely easy
Let me not undersell the conversation. Modern speech and language models are extraordinary. A capable team can wire a large language model to a telephony stack, give it a few tools, and have something answering FNOL calls in a quarter. It will read back a reference number, capture an incident, and sound human doing it.
That part is easy because the hard work was done by someone else. The model was trained by a frontier lab. The speech-to-text and text-to-speech are bought in. The telephony is a vendor API. You are assembling components, and the components are excellent. This is why every demo looks finished, and why every claims-AI pitch sounds the same.
The trouble starts the moment that conversation has to touch a real claim.
A claim is not a conversation. It is a regulated decision.
A claim is a regulated decision with a named owner, a customer who can complain to the Financial Ombudsman, and money at the end of it. The moment your voicebot is talking to a real claimant, it needs a great deal more than a good conversation. It needs:
- A workflow engine to route the case, run the automation, and move the claim forward, not just talk about it.
- An immutable audit trail that records every action, every actor, and every timestamp, so a Consumer Duty review or a FOS request can be answered from the file.
- Approval queues, so nothing the AI drafts is ever auto-sent. A human reviews, edits, and approves before anything leaves the building.
- Authority limits, so no action settles or commits above its mandate, with hierarchical sign-off where the value demands it.
- Escalation rules, so a frustrated or vulnerable customer, a low-confidence answer, or an error state routes to a named person with full context, not a cold transfer.
- Identity verification, so the AI never shares case detail with someone who has not verified, on a proper session boundary.
- Channel parity, so voice, SMS, WhatsApp, web chat and email behave identically from one definition, instead of five inconsistent bots.
- Provider failover, so a model outage does not drop a customer at 2am. Our platform fails over between providers mid-conversation; we wrote about why in AI resilience.
- Per-tenant isolation, so data never crosses a boundary it should not.
None of that demos. All of it is the project. And every item on that list is the difference between a clever conversation and a claim you would defend to a regulator.
The 80 per cent is a multi-year build and a permanent team
Here is the part that gets underweighted in build-versus-buy spreadsheets. The 80 per cent is not a one-off build cost. It is a multi-year build followed by a permanent team to keep it alive.
Models change. Channel APIs change. Security patches arrive. Compliance rules move. The conversations happen at night and at weekends, so the reliability bar is 24/7. An in-house build does not finish; it acquires a standing engineering team whose job is to keep the foundations intact while the rest of the business waits for the next feature. You have not bought a claim assistant. You have committed your roadmap to becoming a claims-software company.
That is the real question behind build versus buy. It is not "can we build a voicebot?" You can. It is "do we want to become a software company in order to deploy one claim assistant, while our competitors configure a platform and ship?" We laid out the full decision framework in our guide to building versus buying claims AI.
The model is the cheap part. The moat is your operation.
There is a deeper reason buying usually wins, and it has to do with where the durable value actually sits.
The language model is the cheap, swappable component. It gets better and cheaper every few months, and you should expect to swap it. The durable asset is your configured operation: the workflows, the audit history, the authority structure, the integrations, the decade of edge cases encoded into how the platform handles a messy claim. That is the moat, and it is the thing that does not arrive in a quarter.
When you build the conversation in-house and wire it to one model provider, you have invested in the part that depreciates and skipped the part that compounds. When you configure a proven platform, you get the moat on day one and treat the model as the replaceable layer it is. That is the right way round.
What a decade of hardening actually buys
We have processed more than 11.8 million cases since 2015, across 40,000 users and seven industries, with claims the deepest. One customer runs 384 active workflows on the platform. The reason that matters is not the number. It is that the hard part, the engine, the audit, the approvals, the failover, the isolation, was solved and hardened long before we pointed it at a claim.
You can see what that hardening produces in the specialist motor insurer case study, where more than 600 users at a UK specialist motor insurer run on the platform, and at Laird Assessors, where the agent layer handles out-of-hours intake, supplier chasing and total-loss conversations in production today. None of that is the conversation. All of it is the 80 per cent.
How to test the ratio for yourself
If you take one thing from this, make it an exercise rather than a belief. Sit down with your compliance officer and write the inventory: every capability a claims AI needs beyond the conversation. Mark which ones you have today, which are production-grade, and who would own them. Most teams find the conversation is the only box they can confidently tick.
Then prove the alternative on one workflow. A 30-day pilot on your noisiest conversation, deployed on your data, measured against your own SLA and cost-per-claim, tells you more than any business case built on assumptions. If a configured platform earns its place in a month, you have your answer about the multi-year build.
The AI that talks is the easy 20 per cent. Telephony answers the phone. A claims operating system runs the claim. Be precise about which one you are building, and which one you actually need.
Further reading:
- Build versus buy: the real cost of building claims AI in-house: the full decision framework
- Everyone wants AI to decide the claim. We built the platform that runs it: the 2026 positioning
- AI resilience: provider failover, mid-conversation
- Timeline: the audit logger: the per-case, per-agent, per-second evidence trail
- The ILC ClaimsTech 2026 hub: the platform behind the pitch