Nguyen Manh Thang
Chief Executive Officer, AgileTech Vietnam
- Published
- Read time
- 11 min
In short
Claims software runs the process by which an insurer keeps its promise: intake at first notice of loss, triage that routes each claim by severity and complexity, investigation and coverage verification against the policy version in force on the loss date, reserving that estimates the ultimate cost for the balance sheet, and settlement that moves the money. Because claims consume 60 to 70 percent of premium, small improvements in handling quality, fraud detection and leakage control move more money than any other system at a carrier. The sensible sourcing split is to buy the workflow core, which encodes decades of claims practice, and build the customer-facing layer: intake apps, status tracking and communication, where claimant experience differentiates.
Insurance is a promise that is only tested when something goes wrong, and the claims system is where the test happens. Every other system at a carrier exists to sell and administer the promise; this one keeps it, at the rate of 60 to 70 cents of every premium dollar. It is also the system claimants actually experience: nobody remembers their policy issuance, and everybody remembers their claim.
This guide follows the machinery properly: what happens at first notice of loss, how triage routes claims, why coverage verification depends on the policy ledger, what reserving really is and why its accuracy moves the balance sheet, where fraud detection and leakage controls fit, and how settlement closes the loop. It ends with the sourcing question: which parts of the claims stack to buy, and which to build.
This page is one of three core-system deep dives in a cluster. The insurance software guide holds the full map if you want the wide view, and policy administration systems explained covers the contract ledger this system queries at every coverage decision.
Key takeaways
- Claims is where the premium dollar actually goes: 60 to 70 percent of it. Handling quality, fraud detection and leakage control in this one system move more money than optimization anywhere else.
- The lifecycle is stable across every line: first notice of loss, triage, coverage verification against the policy as of the loss date, investigation, reserving, settlement, with subrogation and litigation as branches.
- Triage is the quiet lever: routing simple claims to fast straight-through paths and complex ones to senior handlers early is worth more than any single automation, and it is where severity models genuinely earn their keep.
- Reserves are a balance-sheet estimate, not bookkeeping: each open claim carries an estimate of its ultimate cost, and systematic reserving error distorts pricing, reinsurance and reported results.
- Leakage, paying more than the policy obliges through process error, is the measurable quality metric of a claims operation, and the software's job is to make the correct decision the easy one.
- Buy the claims workflow core; build the claimant-facing experience. Intake, status and communication are where preference forms, and they run on the core's APIs.
Why the claims system moves more money than anything else
Start with the arithmetic that frames everything. A carrier collecting 100 million in premium typically pays 60 to 70 million in losses and loss-handling costs. Against that base, a one percent improvement in claims outcomes, slightly better fraud catch rates, slightly less overpayment, slightly faster handling of the simple cases, is worth 600,000 to 700,000 a year, every year. No portal redesign, no marketing optimization, no back-office efficiency program at the same carrier has a lever that long.
The lever has two ends, and honest claims strategy holds both. One end is cost control: detecting the fraudulent minority, avoiding leakage on the legitimate majority, and keeping handling expense proportionate to claim size. The other end is the promise itself: paying legitimate claims fully and fast, because claims experience is the single strongest driver of renewal behavior and reputation. Software that only serves the first end produces an insurer people leave; software that only serves the second produces one that bleeds. The design tension between the two runs through every section of this guide.
The claims system also carries a balance-sheet responsibility that surprises people from other industries. Every open claim carries a reserve, the carrier's estimate of what the claim will ultimately cost, and the sum of those reserves is one of the largest liabilities on an insurer's books. Reserving flows through the claims system's data and discipline, which means the system's quality is audited not just by operations but by actuaries, reinsurers and regulators reading its numbers.
Finally, claims is where the integration argument from the rest of this cluster lands hardest. A coverage decision is a question put to the policy ledger: what did this contract say on the loss date, which endorsements applied, what were the limits and deductibles then. A claims system integrated with a snapshot of current policy state, rather than the versioned ledger, makes coverage decisions on the wrong contract, and the resulting errors are the expensive kind: legal, regulatory and public.
The claims arithmetic
First notice of loss: the intake that sets everything after it
A claim begins when the carrier first learns of a loss, and the industry's term, first notice of loss or FNOL, names the moment precisely. Everything downstream inherits the quality of this intake: a complete FNOL with photos, a clear account, the loss date and location, and contact details lets triage route accurately and lets simple claims resolve in days; a thin one, a phone message saying the car is damaged, generates weeks of follow-up before handling can even begin.
Intake channel design is therefore product work, not form design. The modern pattern is a guided digital intake, in an app or on the web, that adapts its questions to the loss type, captures photos and documents at the scene, validates as it goes, and confirms coverage basics in real time by querying the policy as of the loss date. Behind the scenes it opens the claim in the workflow core, attaches everything, and returns the two things a claimant most wants at that moment: a claim number and an honest statement of what happens next.
The channels that remain human, phone for distressed claimants, brokers for commercial losses, feed the same structure. The intake application the call handler drives should be the same guided flow, so that a phoned claim and an app claim arrive downstream identically shaped. Carriers that let each channel invent its own intake format pay for it forever in triage quality and handler time, one malformed claim at a time.
FNOL is also the natural home of the first automation wins, because its decisions are shallow and its volume is high. Duplicate detection catches the same loss reported twice through different channels. Coverage pre-checks flag the policy that lapsed before the loss date. Severity signals, loss type, vehicle drivable or not, water still flowing or stopped, feed the triage that follows. None of this is exotic machine learning; most of it is well-placed rules, and it is worth more than exotic machine learning applied anywhere shallower.
What a good FNOL captures, first time
- The loss, specificallyType, date, location, and an account in the claimant's words. The loss date drives the coverage question everything depends on.
- Evidence at the scenePhotos, documents, witness details, captured while they exist. Evidence quality at intake is settlement speed later.
- Coverage basics, verified livePolicy in force on the loss date, relevant coverage present, deductible known. Bad news delivered honestly at intake costs less than at settlement.
- A claim number and the next stepThe claimant's anxiety is the product problem. A number, a named next step and a time expectation answer it.
Triage: the quiet lever that decides handling cost
Not all claims deserve the same process, and triage is the machinery that acts on that fact. A cracked windshield with photos and a known repair cost needs no investigator; it needs a fast approval and a payment. A commercial fire with injuries needs a senior adjuster, engineering reports and legal counsel from day one. Routing each claim to the right depth of process is worth more than any single automation in the stack, because both errors are expensive: heavy process on simple claims burns handling expense and claimant patience, and light process on complex claims leaks money and mishandles risk.
The straight-through path is where digital claims programs earn their headlines. For claim types that qualify, low value, clear coverage, complete evidence, consistent history, the system verifies coverage, applies the deductible, prices the loss from photos or invoices against known repair costs, and pays, with no human in the loop and a cycle time measured in hours. The honest boundaries matter: straight-through works for the high-volume simple tail, and each claim type's eligibility rules need explicit design, monitoring and fraud sampling, because an unwatched automatic payment path is an invitation.
The complex path inverts the goal: get the right human on the claim early. Severity models, and this is where machine learning genuinely earns a place in claims, predict from FNOL data which claims will develop into large or litigated losses, so they can be assigned to senior handlers while the facts are fresh, rather than escalated after a junior handler has spent three weeks and set the wrong expectations. Early right-handler assignment is one of the most consistently reported wins in claims analytics, precisely because the cost difference between a well-handled and mishandled complex claim is so large.
Between the extremes sits the managed middle: claims that need a human but not a specialist, where the system's job is workload orchestration, assignment by capacity and skill, task queues with deadlines, and escalation when development exceeds the initial severity estimate. This is unglamorous workflow software, and its quality shows up in the operational metrics that claims leaders actually manage: cycle time by claim type, touches per claim, and the aging report of claims that have stalled.
The three routes out of triage
-
Straight-throughThe simple tail
Low value, clear coverage, complete evidence. Verified, priced and paid without human touch, in hours.
-
Managed handlingThe middle
Assigned by skill and capacity, driven by task queues with deadlines and escalation on development.
-
Complex from day oneThe costly head
Severity signals route the claim to senior handling early, with investigation and counsel while facts are fresh.
Coverage verification and investigation
Every claim decision rests on one question answered correctly: what did the policy say on the loss date. The claims system asks the policy ledger for the contract as of that date, the version in force, with the endorsements that applied, the limits, deductibles and exclusions as they stood, and evaluates the reported loss against it. The dependence is absolute, which is why the integration semantics covered in the policy administration guide matter here more than anywhere: a claims system reading current policy state instead of as-of-date state will eventually deny a covered claim or pay an uncovered one, and both errors compound legally.
Coverage evaluation is rarely a single yes or no. Real policies have coverage sections, sub-limits, deductibles that vary by peril, and exclusions with exceptions, and a single event can implicate several: a storm claim may involve building coverage, contents coverage, business interruption and a flood exclusion simultaneously. The software's contribution is structure: representing the coverage decision per section rather than per claim, holding the reasoning, and generating reservation-of-rights and denial communications that reference the actual contract language, because unsupported coverage communication is a regulatory complaint generator.
Investigation scales with what triage decided. The simple tail needs verification: is the invoice real, do the photos match the account, has this vehicle claimed before. The complex head needs real investigation: adjusters on scene, engineering and medical experts, recorded statements, and for suspected fraud, special investigation unit referral. The system's job across the range is the case file: every document, statement, photo, expert report and decision, attached, ordered and auditable, because the claim file is what gets defended if the claim ends in court, and a scattered file loses cases that the facts would have won.
Subrogation and salvage are the recovery branches, chronically under-worked because they happen after the claimant is served. When a third party caused the loss, the carrier can recover its payment from them; when damaged goods retain value, salvage recovers part of the cost. Both are detection problems first, the system should flag recovery potential from the loss facts automatically, and workflow problems second, because recovery follows its own long timeline. Carriers that instrument recovery properly typically find money their process was leaving on the table, which makes it a favorite early win in claims system modernizations.
Reserving, leakage and the money controls
A reserve is the carrier's running estimate of what an open claim will ultimately cost, set at intake, adjusted as facts develop, and released or paid at closure. Summed across all open claims, reserves are among the largest liabilities on the balance sheet, and their accuracy propagates everywhere: under-reserving flatters this year's results and detonates later as adverse development; over-reserving ties up capital and misprices renewals. The claims system is where reserve discipline lives or dies, because reserves are set and moved by handlers inside its workflow.
Good systems make reserving structural rather than heroic. Initial reserves come from type-and-severity tables rather than each handler's intuition. Reserve changes above thresholds require review and a reason code, so the development history is analyzable. Stale reserves, open claims whose estimate has not moved despite activity, surface on aging reports. And the whole reserve history feeds the actuaries, whose triangles and development factors turn claim-level discipline into portfolio-level pricing and reinsurance decisions. A claims system that treats reserves as an editable number rather than a governed process is quietly corrupting every number downstream of it.
Leakage is the industry's word for paying more than the policy obliges through process failure: the deductible not applied, the depreciation miscalculated, the duplicate invoice paid, the sub-limit missed, the recovery never pursued. Studies of closed files routinely find leakage worth several percent of claims spend, which against the arithmetic of the opening section makes it one of the most valuable defects in the building. The software countermeasures are specific: computed rather than hand-entered financial fields, payment validation against coverage and reserve, duplicate detection across claims and payees, and closed-file sampling workflows that measure leakage instead of assuming it.
Fraud sits at the intersection of money control and investigation, and deserves precision rather than slogans. The large majority of claims are legitimate, and a fraud program that treats every claimant as a suspect poisons the experience that drives renewals. The working pattern is layered scoring: rules catch the known patterns, the staged-accident indicators, the provider billing anomalies; models score the subtler signals; network analysis finds the organized rings that no single claim reveals; and everything above threshold routes to human investigators, because the system's job is to aim scarce investigation, not to auto-deny. Precision matters more than recall economics here: false accusations cost customers and court judgments.
The money controls, and what each protects
| Control | What it is | When it is absent |
|---|---|---|
| Governed reserving | Table-driven initial reserves, reviewed changes, reason codes | Adverse development, mispriced renewals, actuarial distrust |
| Leakage prevention | Computed financials, payment validation, duplicate detection | Several percent of claims spend lost to process error |
| Layered fraud scoring | Rules, models and network analysis routing to investigators | Fraud paid quietly, or honest claimants treated as suspects |
| Recovery workflow | Automatic subrogation and salvage flagging with follow-through | Recoverable money left with third parties |
The financial disciplines a claims system must make structural, and the failure felt when each is absent.
Settlement, communication and the claimant experience
Settlement is where the promise is finally kept, and its mechanics deserve the same engineering attention as intake. Payment options matter: bank transfer to a verified account, payment to a repairer in a managed network, replacement in kind, or structured payments on long-tail injury claims. Speed matters most on the simple tail, where the difference between a two-hour and a two-week payment is the difference between a promoter and a detractor. And finality matters on the complex head, where settlements carry releases and the documentation must be airtight.
Communication through the claim is the experience layer that claimants actually judge, and it is chronically underbuilt because it sits between systems. The claimant wants three things continuously: where the claim is, what happens next, and when. A status model designed for claimant comprehension, notification on every state change, and honest expectation-setting when things slow down cost little against the machinery this guide has described, and move satisfaction more than anything except the settlement itself. This is the layer carriers should build even when they buy everything else, and the insurance app cost guide prices exactly this build.
The repairer and provider network is the operational extension of settlement. In motor and property, managed repair networks let the carrier control cost and quality directly: the system assigns the repairer, the estimate flows digitally, the invoice validates against the estimate, and the claimant never fronts money. In health and injury lines, provider billing runs through adjudication rules that catch the coding anomalies where provider fraud lives. Network integrations are unglamorous B2B plumbing and repay their build cost in both leakage control and claimant convenience.
Closure discipline completes the lifecycle. A claim closes when payments are done, recoveries are resolved or written off, and the file is complete; reopening rules govern what happens when the loss develops after closure. The closed file then becomes data: loss experience feeding pricing, development history feeding reserving tables, leakage sampling feeding process improvement, and fraud outcomes feeding the models. The carriers that treat closed claims as a data asset rather than an archive are the ones whose next year's claims operation is measurably better than this year's.
What to buy, what to build
The sourcing logic follows the same clock-speed reasoning as the rest of the insurance stack, applied to claims' specific anatomy. The workflow core, claim lifecycle states, task orchestration, financial controls, reserving governance, compliance reporting, encodes decades of claims practice and regulatory expectation, changes slowly, and differentiates no one. Buy it. The claims platforms on the market have absorbed thousands of carrier-years of edge cases, and rebuilding that in custom software is a decade-long way to rediscover them.
The claimant-facing layer inverts every property, exactly as the distribution layer did in the wider stack. Intake experiences, status tracking, communication, and the digital flows around repairers and documents change with consumer expectations, differ meaningfully between carriers, and are where claims experience becomes renewal behavior. Build these, on the bought core's APIs, with the product engineering discipline of consumer software. The same argument covers the special cases: an embedded insurer whose claims flow lives inside a partner's app, or a niche line whose intake needs bear no resemblance to the platform's templates.
Analytics splits down the middle, and honesty about the split saves money. Fraud scoring rules and standard severity models increasingly come with platforms and are worth taking. But models trained on the carrier's own book, its lines, its geography, its fraud patterns, outperform generic ones where the data is rich enough, and the carrier's data science investment belongs exactly there, plus in the unglamorous data engineering that makes closed claims analyzable at all. A model program without the data plumbing underneath is a demo, not a capability.
Sequencing advice mirrors the wider modernization pattern. If the workflow core is being replaced, stabilize it first, then build experience layers against its APIs; building experience against a core mid-replacement doubles the integration work. If the core is staying, wrap what it cannot expose and build the intake and status experience now, because that layer pays back fastest and teaches the organization what its claims data can do. Either way, the first build should be one claim type, end to end, in production, before the program widens, for all the reasons one-product-first won in the app cost guide.
Claims sourcing discipline
Do this
- Buy the workflow coreLifecycle, tasking, financial controls and compliance encode decades of practice no custom build should rediscover.
- Build the claimant experienceIntake, status and communication differentiate and change fast. They belong on the core's APIs, built like consumer product.
- Train models on your own bookWhere data is rich, own fraud and severity models beat generic ones. Fund the data plumbing first.
- Ship one claim type end to endProve intake to settlement on one line in production before widening. The seams are the risk.
Not this
- Customize the core into a forkHeavy core customization freezes upgrades, the same disease that created legacy claims systems.
- Accept the vendor claimant portal as-isThe shipped portal is every competitor's portal. The experience layer is where you differ.
- Buy fraud AI without data engineeringModels on unanalyzable claim files are demos. The plumbing is the capability.
- Build experience against a moving coreA core mid-replacement doubles every integration. Stabilize, then build.
Frequently asked questions
What does claims software actually do?
It runs the process by which an insurer keeps its promise: intake at first notice of loss, triage that routes each claim by severity, coverage verification against the policy version in force on the loss date, investigation and case file management, reserving that estimates ultimate cost for the balance sheet, and settlement that moves the money, with fraud detection, leakage controls and recovery workflows threaded through.
What is first notice of loss?
The moment the carrier first learns of a loss, and the intake that captures it. FNOL quality determines everything downstream: a complete intake with photos, the loss account, date, location and live coverage verification lets simple claims resolve in hours and complex ones route to the right handler immediately, while a thin intake generates weeks of follow-up before handling can begin.
What is claims leakage?
Paying more than the policy obliges through process error: deductibles not applied, depreciation miscalculated, duplicate invoices paid, sub-limits missed, recoveries never pursued. Closed-file studies routinely find leakage worth several percent of claims spend. The countermeasures are structural: computed financial fields, payment validation against coverage and reserve, duplicate detection, and closed-file sampling that measures leakage instead of assuming it away.
What are claims reserves and why do they matter?
A reserve is the carrier's running estimate of what an open claim will ultimately cost. Summed across open claims, reserves are among the largest liabilities on an insurer's balance sheet, and their accuracy propagates into pricing, reinsurance and reported results. Good systems make reserving structural: table-driven initial estimates, reviewed changes with reason codes, and stale-reserve reports, feeding the actuarial analysis downstream.
Where does AI actually work in claims?
Three places with real track records: severity prediction at triage, so complex claims reach senior handlers while facts are fresh; fraud scoring layered over rules and network analysis, aiming scarce investigators rather than auto-denying; and photo-based damage estimation on the high-volume simple tail. Each depends on data engineering that makes claim files analyzable, which is the unglamorous investment that decides whether the models are a capability or a demo.
Should an insurer build or buy its claims system?
Buy the workflow core, the lifecycle, tasking, financial controls and compliance machinery that encode decades of claims practice, and build the claimant-facing layer on its APIs: intake experiences, status tracking and communication, where claims experience becomes renewal behavior. Avoid customizing the bought core into an unupgradeable fork, and prove any build on one claim type end to end before widening.
Claims is where 60 to 70 percent of every premium dollar actually goes, and where the insurance promise is kept or broken. Before touching the claims stack, follow a claim through the machinery properly, from first notice of loss to settlement, with the money controls made visible.
