This is not a marketing overview. It is a stage-by-stage account of how the Insurteam pipeline handles a specific claim type, so that claims operations teams can understand exactly what happens and where. The numbers and timing are from our beta pipeline environment.
The scenario: a policyholder with a travel insurance policy that includes a flight-delay benefit is on LX 395, Zurich to London Heathrow, scheduled departure 07:40. The flight delays and eventually departs at 11:22. The actual delay is 3 hours 42 minutes. The policy's delay threshold is 3 hours. The benefit schedule provides CHF 150 for delays between 3 and 5 hours.
Stage 1: Event detection
The pipeline is subscribed to flight tracking feeds from multiple data providers. At approximately 20 minutes after scheduled departure, the flight status changes to "delayed" with an estimated new departure time. The pipeline logs the delay event against the monitored booking record. No action is taken at this point; the delay has not confirmed beyond the coverage threshold, and estimated departure times change frequently in the first hour of a delay.
The pipeline continues monitoring. This is important because a delay that initially looks like 45 minutes can extend to 4 hours, and a delay that looks like 3.5 hours can recover to 2.5 if the aircraft gets an earlier departure slot. Acting on estimated times would generate both false positives and missed claims. The pipeline waits for confirmed wheels-up data before initiating coverage evaluation.
Stage 2: Delay confirmation at wheels-up
At 11:17, the aircraft pushes back. At 11:22, the tracking feed registers confirmed wheels-up. The pipeline records the departure timestamp: 3 hours 42 minutes from the scheduled 07:40. This confirmed measurement exceeds the 3-hour threshold. The pipeline moves to coverage evaluation.
Note the distinction between gate departure and wheels-up. Some carriers show gate departure as the departure time in their feeds; others use pushback; others use wheels-up. The pipeline normalises to wheels-up across all providers, because that is the timestamp most consistently available and most clearly represents the start of flight from the policyholder's perspective. The policy document's delay clause references are also evaluated against wheels-up time in this pipeline configuration.
Stage 3: Coverage evaluation
The pipeline retrieves the policy record associated with this booking. It confirms the policy is active, the travel date falls within the coverage period, and flight delay is a listed benefit. It then runs the policy extraction layer against the full policy document.
Extracted elements for this claim: delay threshold confirmed at 3 hours; benefit schedule confirmed at CHF 150 for delays in the 3-to-5-hour tier; no weather exclusion present in this product variant; no general exclusion applicable to the cited cause of delay. Coverage confidence across all extracted elements: 0.97. The single element below 1.0 confidence is the cause-of-delay clause, which references a definition the extraction model scored at 0.92, still well above the routing threshold.
A structured coverage decision object is generated: eligible, benefit CHF 150, policy clause references, confidence score per element. Time elapsed from delay confirmation to coverage object: 2.8 seconds.
Stage 4: Claim creation and policyholder notification
A claim record is created in the insurer's core claims system via API. The claim record carries all structured data: policy number, insured name, booking reference, confirmed flight data with source, coverage decision with clause references, benefit amount, and a flag indicating straight-through processing eligibility.
The policyholder receives an SMS and email notification: their flight was delayed by 3 hours 42 minutes, which exceeds the covered threshold, and a settlement of CHF 150 is being processed to their registered payment method. A claim reference number is provided. The policyholder has not filed a claim, submitted any document, or called any number. The notification arrives while they are still at the airport.
Stage 5: Settlement
The settlement instruction is issued to the insurer's payment rail. For most payment configurations in our beta deployments, the settlement completes within 2 to 24 hours of the claim creation, depending on the insurer's payment processing cycle. The policyholder receives a settlement confirmation. The claim is closed.
Total elapsed time from wheels-up to settlement initiation: under 5 minutes for pipeline processing. Total adjuster involvement: none. The insurer's operations team can see the claim record, the coverage decision rationale, and all cited clause references at any point if they want to audit the decision.
What routes to human review instead
The claim above went straight through because all conditions were unambiguous: confirmed delay data from a consistent source, delay well above threshold, no exclusion ambiguity, high-confidence extraction across all elements. Two variants of the same scenario that would route to a handler queue:
Variant A: the delay calculation shows 2 hours 55 minutes against a 3-hour threshold. The 5-minute gap is within the pipeline's 15-minute proximity threshold. The case routes to a handler with the structured data pre-assembled. The handler confirms or disputes the delay measurement, makes a binary eligibility decision, and closes. Typical handling time for this variant in the beta environment: 4 to 7 minutes.
Variant B: two flight data providers report different wheels-up timestamps, 3 hours 10 minutes in one source and 2 hours 48 minutes in the other. The discrepancy exceeds the data confidence threshold. The case routes to a handler with both data sources displayed, the delta flagged, and a prompt to confirm which source is reliable for this carrier and route. The handler makes the data quality judgment, not a policy interpretation judgment. Typical handling time: 6 to 10 minutes.
The pipeline design is explicit about this division: machine-speed deterministic evaluation for clean cases; human judgment for genuinely ambiguous cases, with the analytical work already done before the handler opens the record. The adjuster is not doing data retrieval or policy reading. They are applying judgment to the specific point of ambiguity that the pipeline identified.
