Insurance Claims Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the domain model collapse into a ticket system so often?

Because a claim looks like a ticket from a distance. It arrives, gets assigned, has a status, closes. Any generic development team can build that in three weeks and it demonstrates beautifully with a dozen sample files.

Then the real shape appears. One loss can span multiple coverages. An estimate has versions. A supplement arrives six weeks after closure and reopens the money without reopening the claim. A reinspection produces a second opinion that has to sit alongside the first rather than replacing it. An assignment can be reassigned twice, and each of those states has fee consequences. A ticket has one status field and none of that fits inside it.

The fix is a scoping rule you can enforce before you sign: make the developer whiteboard claim, assignment, inspection, estimate version, supplement and reinspection as distinct records, and show you one loss spanning two coverages. Watch specifically for whether the estimate is a versioned object with structured data behind it or an attachment. That single distinction decides whether your invoicing is automatic or re-typed, because if the replacement cost value never enters your database, the fee schedule is applied by a person from a PDF and it gets misapplied silently.

What goes wrong when you migrate thousands of open claims with live deadlines?

The mistake is treating it as a data problem. It is an operations problem with a data component, because every open file has a carrier clock running on it, and a clock that stops being monitored during a cutover is a breach nobody can explain afterwards.

The data itself is messier than the export suggests. Historic files carry policy numbers typed from PDFs, so the same policy appears three ways. Adjuster names exist as free text with the same person entered four different ways across two years. Photos and documents live across the incumbent system, a shared drive and adjusters' phones. Fee history often cannot be reconstructed at all, because the fee actually paid was calculated in a spreadsheet that no longer exists.

The approach that works is a parallel run rather than a cutover. Import open files with full history and documents, run the new system read-only alongside the old one for two to four weeks, then move carriers one at a time so no deadline clock is ever unmonitored. Closed claims migrate as archived records so a carrier audit or a Department of Insurance market conduct exam can still be answered. Reconcile open file counts and next-deadline dates per carrier before each carrier cuts over. Anyone proposing a single weekend cutover has never done this with live carrier deadlines running.

Why do the XactAnalysis and carrier channel integrations break after launch?

Because there is no single channel and there never will be. A regional firm working eight carriers receives first notice of loss assignments through XactAnalysis, proprietary carrier portals, and plain email. Each has its own format and each changes without telling you.

The three failure patterns are consistent. The email parser is the first: it is trained on the formats each carrier used at go-live, the carrier changes a template, and files stop being extracted correctly, or worse, get extracted incorrectly, which is how a wrong policy number reaches an insured. The portal scrape is the second and it breaks whenever the portal is redesigned. The third is the Verisk side, where the connection keeps working but the structured estimate data changes shape, so replacement cost value stops being parsed and invoices go out at the wrong tier.

The fixes are specific. Never let parsed data enter the system unverified: a human review queue for anything the parser was not confident about is the correct architecture, not a fallback. Alert on absence, meaning a carrier whose overnight assignment volume drops to zero should page someone, because silence is the normal symptom of a broken channel. Version the estimate parser and keep the source file attached to the estimate record so a fee dispute can be traced to the actual export. And when a developer says every integration is straightforward, ask what broke on the last one, because anyone who has shipped against a carrier portal has a story.

What happens when compliance clocks and licensing are not covered?

You find out during an audit or during a catastrophe deployment, and both are the worst moment. Every carrier hands you a guideline document: contact within 24 hours, inspect within 72, first report in 7 days, status updates every 14. States layer their own claim handling deadlines on top through unfair claims settlement practices rules. In most firms those clocks live in a PDF binder and in adjusters' heads, and a file becomes visible only once it is already late.

Licensing is the parallel gap. During a surge your roster can go from 45 adjusters to 320 in ten days, and every deployed adjuster needs a licence valid in the deployment state, a W-9, a fee split agreement and a check against the carrier's approved list. If licensing is a spreadsheet, someone gets assigned a file in a state where they are not licensed, which is a regulatory error rather than a process one.

The fix is to make both into data rather than knowledge. Encode each carrier's guideline set and the relevant state timelines as rules, so every file displays its next deadline and an escalation ladder fires to the adjuster and then the manager before a breach rather than after. Store adjuster licences with states and expiry dates, block assignment where the licence does not cover the loss state, and expire access automatically at demobilisation so you are not securing 300 dormant accounts in November. Every action lands in an audit trail you can export when a carrier audits your firm. That export is what protects the roster spot.

Should you build custom or configure what you already own?

Stay on what you have if you run fewer than about 20 adjusters, work daily claims rather than catastrophe surges, and hold one or two carrier relationships. FileTrac Evolve and ClickClaims are real products, the subscription is cheaper than any build, and at that scale your problems are process problems that software will not solve. We tell firms this on calls and it is usually the right answer.

The signals that configuration has run out are concrete rather than aesthetic. Dispatcher headcount grows every time volume grows. Assignments arrive through five or more channels. Invoice reconciliation lives in Excel because the tool cannot express your carrier fee schedules. Per-seat bills spike every storm season, which is the surge that makes your year also inflating your software cost. Or a carrier has already warned you about reporting discipline. Above roughly 50 adjusters or 10,000 files a year across multiple carriers, a build typically repays itself within 18 to 24 months in our delivery experience, through recovered fee leakage and eliminated dispatch labour.

Do not build because you dislike the interface. Build because your assignment logic, your fee schedules and your deadline sets cannot be expressed in the tool, so the labour piles up around it.

How do hidden costs get into the quote?

Five places, and each is worth naming in the estimate rather than folding into a line called integrations. The number of carrier channels you need automated is the first, and it scales per channel, not per carrier. Depth of integration with the Verisk ecosystem is the second, and receiving assignments is a different piece of work from parsing structured estimate data.

A per-state compliance rules engine is the third. Firms working three states and firms working eighteen are not in the same project. Offline capability for field adjusters is the fourth, and it is not a checkbox: storm zones rarely have signal, photo capture has to queue locally, and sync conflict rules have to be decided rather than assumed. Storage volume is the fifth, because photo and document volumes reach terabytes after one storm season and that changes the hosting shape.

Migration of open claims with intact history belongs on the same list, and it is routinely underestimated because the export looks clean until someone tries to reconcile fee history that was never stored anywhere.

Then ask about the year after launch. In our engagements ongoing support runs roughly 15 to 20 percent of the initial build cost per year, covering hosting, monitoring, security updates and the adjustments needed when carriers change portal or reporting requirements. That last item is the cost of staying on rosters rather than optional maintenance.

What separates a build that works from one that fails here?

The builds that work start at intake and assignment, because that is where the largest block of manual labour sits. Unified intake across XactAnalysis, portals and email with a review queue, an assignment engine that ranks adjusters by licence state, distance, current workload and carrier approval, and a contact clock that starts the moment the file arrives rather than when a dispatcher notices. A dispatcher spending five hours a day re-keying assignments is $18,000 to $25,000 a year of pure data entry, and that is the least of it, because assignment latency is what quietly eats the contact service level agreement.

The builds that fail try to replace everything at once, including Xactimate. Nobody should be rebuilding estimating. The value is in the connective tissue between your carrier mix, your fee schedules and your roster, and a project that respects that boundary ships in 12 to 16 weeks rather than disappearing for a year.

Three questions before you sign. Ask them to model one loss spanning multiple coverages with two estimate versions and a supplement, on a whiteboard. Ask what their fallback is when a carrier offers only a portal and email: structured parsing with a human review queue is a real answer, a shrug is not. Ask them to describe the migration for open claims with live deadlines. Then settle ownership in writing: full intellectual property assigned to your firm, the repository in your own organisation account from day one, hosting credentials yours. Walk away from license-back terms or per-claim fees on software you paid to build.