FNOL Automation · Dutch Non-Life Insurance

It's Monday morning.
Your FNOL team just started their shift.

Your team is managing a busy claims queue. If people move between disconnected systems or re-enter details, investigate the impact on handling time, accuracy and customer experience.

This Atsky demonstration explores an FNOL workflow, from collecting fictional details to policy checks and example system actions.

Policy-controlled workflows Data-handling controls Execution records Real-Time Voice Multi-Tenant SaaS
What to measure in your FNOL workflow
VolumeCalls, peaks and reasons for contact
TimeHandling, waiting and follow-up
SystemsHandoffs and repeated data entry
ReworkErrors, callbacks and corrections
ExperienceCustomer feedback and escalation needs

Every current solution fails FNOL
for the same structural reason.

❌ Fails Here
IVR & Traditional Voicebots
Rigid scripts break the moment a caller deviates. Cannot maintain context across a multi-step, emotionally charged conversation. Falls over on interruptions, corrections, and non-linear disclosures.
❌ Fails Here
Generic LLM Assistants
Probabilistic by nature — they guess. FNOL requires deterministic compliance: fraud checks must run, required fields must be validated, the required step order must be established. LLMs cannot guarantee this without a constraint layer.
❌ Fails Here
CCaaS Platforms (e.g. Netcall)
Agent-assist tools that automate routing and summarisation. They still depend on a human agent to make judgement calls and execute across systems. The bottleneck is not routing — it's intake execution.
❌ Fails Here
RPA & Workflow Automation
Works for static, predictable flows. Breaks immediately when a caller interrupts, changes their account of events, or adds a third party mid-conversation. Live voice is fundamentally non-deterministic input.

LLMs propose.
Deterministic logic decides.

SKYLA's Agentic Runtime Fabric (ARF) wraps AI inside policy-governed, symbolic rule enforcement. The LLM handles natural, empathetic conversation. The ARF ensures every step — fraud check, field validation, system write — executes in the correct order, with the correct data, under regulatory constraint.

⚡
Instant System Actions
The design connects a confirmed intent to a backend action and execution record. Measure latency and verify the integration in the intended workflow.
🛡
Six-Layer Hallucination Control
Pre-LLM PII filtering · Schema validation · OPA policy gates · Confidence gating · Execution-time validation · GER audit records. Nothing reaches a system write unless all six layers clear.
🏗
Multi-Tenant Architecture
The design separates tenant credentials, policies and data. Test those boundaries against each deployment’s access model and integrations.
🇪🇺
Data controls and execution records
PII redaction and execution records are part of the design. Validate their coverage and retention against the intended deployment.
Agentic Runtime Fabric — Layer Stack
Layer 1
Voice Interface
Telnyx WebRTC STT / TTS Interruption Handling
↓
Layer 2
Agentic Reasoning
LLM Routing Intent Engine RAG Context Memory
↓
Layer 3 — ARF Core
Policy & Constraint Enforcement
OPA Rules Schema Validation Confidence Gates Step Order
↓
Layer 4
Action & Integration
Claims System Fraud Check Scheduling CRM Write
↓
Layer 5
Observability & Compliance
GER Audit Log EU Data Residency Datadog
The ARF principle: LLMs are creative engines within deterministic guardrails — not decision-makers. Every system write requires policy clearance.

Five steps. Every call. Autonomously.

Every Dutch non-life FNOL intake follows the same five steps — today executed manually across four systems. SKYLA executes all five in a single, uninterrupted agent session.

Today — Manual
SKYLA — Autonomous
1
Today
Identity & Policy Verification
Agent searches policy admin system manually. Caller waits on hold during lookup. Errors in policy number entry cause re-verification loops.
SKYLA
Instant Identity Confirmation
SKYLA verifies identity via voice + policy lookup in real time. Caller continues speaking — no hold required. ARF gates step 2 until verification clears.
2
Today
Accident Detail Collection
Agent types structured fields during live call — date, location, third parties, circumstances. Interruptions cause data loss. Non-linear disclosures break data entry flow.
SKYLA
Structured Extraction, Live
SKYLA extracts all required fields from natural conversation, handles interruptions, corrections, and re-sequenced disclosures. Schema validation rejects invalid data before write.
3
Today
Fraud Flag Check
Agent must tab to fraud/risk system, manually enter policy number, interpret flag results mid-conversation. Step is sometimes skipped under call volume pressure.
SKYLA
Mandatory Automated Check
ARF mandates fraud check execution — it cannot be skipped. Results inform SKYLA's conversation routing. Flagged cases escalate to human agent with full context pre-loaded.
4
Today
Claim File Creation
Agent opens claims management system, manually populates all required fields. Data from steps 1–3 must be re-entered or copy-pasted. Entry errors create downstream rework.
SKYLA
Validated Claim Write
SKYLA writes a complete, validated claim file atomically — all fields from steps 1–3 are carried forward. No re-entry. Schema-validated before write. Claim ID confirmed to caller live.
5
Today
Appointment Booking
Agent switches to scheduling system, checks assessor availability, proposes slots verbally, confirms with caller, then manually adds appointment. Step sometimes deferred to a callback.
SKYLA
Confirmed in the Same Call
SKYLA books assessor slot, confirms appointment to caller by voice and SMS — within the same call. No callback required. Intake is complete before the caller hangs up.

What changes when SKYLA runs your FNOL intake

Human agent navigates 4 systems manually during a live call, re-entering data at each step while keeping the caller engaged.

→

SKYLA executes all system actions autonomously, in the configured order, in real time — while maintaining natural, empathetic conversation with the caller.

Data entry errors during FNOL create rework downstream — incorrect claim files delay assessment, trigger compliance reviews, and require costly callbacks.

→

Schema validation can detect missing or invalid fields before a write. Error rates and recovery behaviour need to be measured during testing.

Measure handling time, repeat contacts and escalation demand in the current workflow before assessing automation.

→

Intake handled end-to-end by SKYLA. Human agents handle edge cases and complex escalations only — the work that actually requires human judgement.

Plan the connections
to your existing insurer systems.

Example systems to assess for integration
  • Guidewire ClaimCenter & PolicyCenter
  • Duck Creek Claims
  • Salesforce CRM
  • SAP Insurance
  • OpenText / Hyland OnBase
  • Telnyx & Twilio (voice carrier)
How connections work — AIS Registry
  • REST / OAuth2 via ARF generic executor
  • OpenAPI spec import → AIS auto-generated
  • JSONata field mapping — no code required
  • Per-tenant credential isolation
  • Sandbox regression tests before go-live
  • Configuration and integration work scoped per insurer
Scope
Integration and test requirements agreed for the selected environment
Scope
Configuration and engineering work assessed for each insurer
Policy
Tenant isolation — credentials, data and policy boundaries to verify
The architecture includes PII redaction, policy checks for field-level access and execution records. These are technical controls; their coverage and operation need to be reviewed for each deployment.

An example route
from assessment to rollout.

FNOL workflows share common steps, but insurers differ in policy rules, systems and operating procedures. Configuration and integration needs must be assessed for each proposed deployment.

Pilot
Example insurer
Full configuration · validation sandbox
→
Deployment
Insurer 2
Configuration and integration scope assessed per deployment
→
Scale
Insurer 3–N
Reuse and cost assumptions tested before expansion
→
Expansion
Adjacent Workflows
GGZ wachtlijst · Claims status · Renewals

Hear SKYLA handle
an example FNOL intake.

Speak with SKYLA in your browser using a fictional motor-claim scenario. Explore the questions, checks and handover steps in a live demonstration. Do not use real claim information.

1
Fill in your details — we capture this for follow-up and to personalise the demo call.
2
Click Start Demo Call — SKYLA connects via your browser (WebRTC, no app needed).
3
Speak naturally. Interrupt. Correct yourself. SKYLA adapts — and completes the full FNOL intake.

This is Atsky’s own FNOL demonstration. Use fictional claim details to explore the voice workflow; it does not submit a claim to your insurer.

Pick a demo scenario
POL-VALID-FB39002XP
Full intake, no complications. Say this policy number when SKYLA asks. Describe a rear-end collision on 1 May. Third party involved, vehicle driveable at home. SKYLA will complete claim creation, adjuster assignment, and inspection booking.
POL-LAPSED-001
Lapsed policy. Use this policy number. SKYLA verifies it, detects the coverage has expired, and closes the intake professionally — no claim is created.
POL-FRAUD-002
Fraud escalation. Policy is valid, but a fraud signal triggers mid-intake. SKYLA routes the call to a senior adjuster team gracefully, without alarming the caller.
Start FNOL Demo Call
Your browser will connect directly — no downloads required
Loading…
Starting a voice demo sends your audio and name, email, company and phone details through Telnyx. We also send your contact details to our enquiry service for follow-up. Text chat sends your messages to the Skyla demo service. Use fictional claim details; do not share real claims or sensitive personal data. Privacy policy →
Demo ends in 5:00
Noisy environment? Switch to text chat instead →
Hi! I'm SKYLA. When you're ready, tell me your policy number and I'll start the FNOL intake.
✓
Demo Complete

Thank you for experiencing SKYLA FNOL.
Your 5-minute demo has ended.

Our team will be in touch shortly to discuss how SKYLA can work for your organisation.