Every claims leader with an IT team and a telephony vendor is being told they can build this themselves. They can build the part that talks. This guide is about the part underneath it, the part that decides whether the project ships or stalls.
Claims AI has never been easier to start and never been harder to finish. A capable engineering team can wire a large language model to a telephony stack and have a voicebot answering FNOL calls in a quarter. It demos beautifully. It reads back a reference number, captures a few fields, and sounds impressively human. This is the visible 20 per cent, and it is genuinely the easy part.
The trouble begins the moment that conversation has to touch a real claim. 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 AI that talks now needs a workflow engine to route the case, an immutable audit trail to evidence every action, approval queues so nothing is auto-sent, authority limits so no one settles above their mandate, escalation rules for the conversations a machine should not finish, identity verification before any case detail is shared, channel parity so voice and email and WhatsApp behave identically, provider failover so a model outage does not drop a customer at 2am, and per-tenant isolation so data never crosses a boundary. None of that demos. All of it is the project.
That hidden 80 per cent is not a feature backlog. It is a multi-year build and a permanent team to keep it alive, on a roadmap that has nothing to do with the insurance you actually sell. The build-versus-buy question is therefore not "can we build a voicebot?" You can. It is "do we want to become a claims-software company in order to deploy one claim assistant?"
The right way to make this decision is to stop evaluating the conversation and start evaluating the operation around it. A claims AI is only as deployable as the platform it acts inside. So the comparison is not "our voicebot versus their voicebot". It is "our voicebot plus the platform we would have to build versus a platform that has already carried production claims load for a decade".
A proven claims operating system collapses the 80 per cent into something you configure rather than construct. The workflow engine, the audit logger, the approval and authority framework, the escalation routing, the identity flow, the multi-channel layer and the model failover already exist, hardened across millions of cases and seven industries. Your team configures it to your claim types, your SLAs and your authority structure. The AI becomes a thin, replaceable layer on top of an asset that is already load-bearing.
Buying does not mean surrendering control. The platform should run on top of whatever core system you already have, configure without code so your operations team owns it after go-live, and prove itself on one workflow before it touches the rest. The test is simple: a bought platform should let you ship something safe in weeks and keep it reversible, where an in-house build asks you to commit budget and roadmap for quarters before the first claimant ever speaks to it.
Work through these steps before you commit a budget. The goal is an honest, line-by-line view of what an in-house build actually requires, measured against what a proven platform gives you on day one.
List every capability a claims AI needs beyond the conversation: workflow routing, immutable audit logging, approval queues, authority limits, escalation rules, identity verification, multi-channel parity, model failover, per-tenant data isolation, and integration with your core system. For each, write down whether you have it today, whether it is production-grade, and who would own it. Most teams discover the conversation is the only box they can tick.
A build is not a one-off project cost. Price the initial build of each capability in the inventory, then add the permanent engineering team required to maintain it: model updates, channel API changes, security patching, audit and compliance changes, and 24/7 reliability for conversations that happen at night and at weekends. Compare that ongoing run-cost to a platform subscription, not just the build to the licence.
Write the non-negotiables before you look at any vendor. Typical requirements: no value is ever generated or negotiated by AI, every action is attributed to a named human in the audit trail, every outbound communication is approved before it sends, evidence is disclosed symmetrically, and any frustrated or vulnerable customer is routed to a person. These requirements are easy to state and hard to build. They are the real specification.
Take your safety specification and your capability inventory and score both options against them on the same sheet. Be specific about time-to-live, regulatory defensibility, reversibility, and who carries the operational risk on a Saturday night. A bought platform should score highly on time-to-live and defensibility because the hard parts already exist; a build typically scores on bespoke fit at the cost of years and a standing team.
Rather than debating the decision in the abstract, prove it on one workflow. Choose the conversation that wakes your duty manager: overflow FNOL, out-of-hours intake, or the bodyshop chase queue. Deploy a configured platform on it for 30 days, on your data, measured against your existing SLA and cost-per-claim. A real readout beats a business case built on assumptions.
At the end of the pilot you have a real answer, not a demo memory. If the platform earned its place, widen it: more channels outward, deeper into the workflow inward. If it did not, you have spent a month and learned something concrete about your own operation. Either outcome is cheaper and faster than discovering the 80 per cent halfway through a multi-year build.
The language model is the cheap, swappable part, and it gets cheaper and better every few months. The durable asset is your configured operation: the workflows, the audit history, the authority structure, the integrations. Build-versus-buy is really a question about who builds and owns that moat. Buying the platform lets you own the moat without building the foundations.
In-house builds routinely leave audit, approval and escalation until after the conversation works, because those parts do not demo. In a regulated claim they are the point. Insist that any option, build or buy, treats the immutable audit trail and human-in-the-loop controls as core from day one, not as a compliance retrofit.
A build hard-wired to one model provider inherits that provider's outages and price changes. A mature platform is provider-agnostic and can fail over between providers mid-conversation. When you score options, treat resilience to a provider outage as a first-class requirement, not a nice-to-have.
Your core system vendor may be promising agentic AI. A roadmap built for the average of a thousand insurers, bolted to one core, claims-only and single-channel, is not the same as a platform you can pilot this quarter. Compare what you can deploy now against what you would be waiting for, and let a 30-day pilot settle the argument.
If extending a workflow requires an engineering ticket every time, you have bought a dependency, not a capability. Favour platforms where configuration is no-code, so your claims operations team can adapt workflows as the book changes without re-entering a build cycle.
The strongest argument for buying is optionality. A pilot that runs alongside your existing process, with no migration and no long lock-in, lets the board defend a quick, measured win. A multi-year build is hard to stop once it has consumed budget and reputation, which is exactly when sunk-cost thinking takes over.
Workflow, audit, approvals, authority limits, escalation, identity, channel parity, failover and isolation all assessed.
Claims leakage is the silent profit killer in insurance. Most insurers know it exists but lack the systematic processes to measure, identify, and eliminate it.
claims managementWhen a major weather event or catastrophe strikes, claims volumes can increase tenfold overnight. The difference between chaos and control comes down to preparation.
fca complianceBuild a robust, evidenced fair value assessment process that satisfies FCA expectations under PRIN 2A and demonstrates genuine customer-centric outcomes.
Stop debating the decision in the abstract. Pick the noisiest conversation in your claims operation and let SwiftCase prove itself on it, on your data, measured against your own SLA and cost-per-claim. No migration, no long lock-in.
