תעשיית הביטוח / מדריך טכני

אוטומציית קליטת FNOL וטריאז' תביעות עם n8n ו-Claude — מדריך שלב אחר שלב

מדריך מלא לבניית pipeline ב-n8n עם Claude שלוכד הודעת נזק ראשונה ממייל, פורטל וטלפון, מחלץ נתוני פוליסה, מסווג חומרה, מנקד סיגנלי הונאה, מנתב לחוקר התביעות הנכון וכותב יומן ביקורת בדרגת TPA — אישור ראשון יוצא לתובע תוך פחות מ-90 שניות.

קריאה של 15 דקות
בינוני – מתקדם
n8n + Claude API
עודכן: מאי 2026
מה תבנה

קליטת FNOL (מייל / פורטל / טלפון)

OCR + חילוץ פוליסה (Claude)

ציון חומרה והונאה (Claude)

ניתוב לחוקר תביעות (LOB + עומס)

פתיחת תיק ב-Guidewire

יומן ביקורת בלתי ניתן לשינוי

SMS ומייל אישור לתובע

1. הבעיה — למה ה-backlog של ה-FNOL עולה למבטחת יותר מהתביעות עצמן

כל מבטחת אלמנטרית או TPA נתקלים באותו קיר תפעולי: הודעת נזק ראשונה (FNOL) מגיעה משישה ערוצים שונים — מייל, פורטל אינטרנטי, טלפון דרך מוקד, פקס מסוכן, אפליקציה סלולרית, EDI משותף עסקי — ועדיין יושב פקיד שצריך לקרוא את זה, למצוא את הפוליסה, להחליט אם זו תאונה קלה או אובדן מוחלט, לבדוק כפילויות, לתת ציון סיכון להונאה ולהקצות את חוקר התביעות הנכון. כל זה מתחת לשעון רגולטורי. דרישת האישור של 24 שעות שמופיעה ברוב חוקי ה-Unfair Claims Practices Acts המדינתיים מכה לפני שהעבודה הזו בכלל התחילה, ו-FNOL שמפספסים הוא תלונת DOI שמחכה להגיע.

מספרים אמיתיים ממבטחת אזורית (רכב + רכוש, ~6,200 FNOL בחודש)

FNOL בחודש (רכב + רכוש + GL) ~6,200
זמן חציוני מ-FNOL לאישור ראשון 11 שעות 40 דק'
סיווג חומרה שגוי שנתפס בהקצאה מחדש 14%
תביעות כפולות שנפתחו על אותו אירוע 3.1%
חשד הונאה שזוהה בקליטה (לא ב-SIU מאוחר יותר) 0.4%
שעות פקיד קליטה בחודש על הזנת נתונים ~840

חוסר הסימטריה האכזרי: כ-6% מה-FNOL הופכים ל-60%+ מתשלומי הנזקים. המערכת חייבת לזהות את תביעת הפציעה הקטסטרופלית, את האובדן החשוד של רכב יחיד בלילה, ואת התביעה השלישית של אותו מבוטח ברבעון — תוך דקות, לא בבוקר אחרי כשפקיד הקליטה מגיע לתור.

מה זה "טריאז'" כאן

טריאז' אינו דגל "כן/לא" של הונאה שמודבק על טופס. זוהי החלטה בארבעה צירים שרצה על כל FNOL ברגע שהמידע נוחת:

  • דרגת חומרה: נזק רכוש קל, נזק רכוש בינוני, נזק גוף (BI), אובדן מוחלט, קטסטרופה / פטירה. מכתיב רזרבה, רמת חוקר, התראה למפקח.
  • תחולת כיסוי: איזה ענף עסקי (LOB), איזה כיסוי בפוליסה, השתתפות עצמית, גבולות משנה.
  • ציון סיגנלי הונאה: כללים + נימוק של Claude מעל נרטיב התביעה והיסטוריית המבוטח. דגלים בלבד — אף פעם לא דחייה אוטומטית.
  • ניתוב: חוקר פנימי מול IA חיצוני מול הפנייה ל-SIU, משוקלל לפי עומס נוכחי ורישוי המדינה.
תובנה
הניצחון הגדול הוא קיצור הזמן לאישור ראשון מ-11+ שעות לפחות מ-90 שניות, והעמדת חוקר תביעות בדרגת החומרה הנכונה על התיק לפני שהרזרבה מסומנת לא נכון. התאמת רזרבה ביום הראשון מכתיבה את כל מתמטיקת ה-loss development במורד הזרם. אנחנו פורסים את אותו דפוס קליטה בכל פרויקטי האוטומציה לביטוח שלנו.

2. ארכיטקטורת המערכת

שמונה רכיבים, כל אחד ניתן להחלפה. שכבת התזמור היא n8n self-hosted בתוך ה-VPC של המבטחת עצמה, כדי שצוות ה-InfoSec והרגולציה יוכלו לבדוק כל קריאת API חיצונית שנוגעת ב-PII או ב-PHI. שום דבר לא יוצא מהפרימטר חוץ מ-prompts מנוקים ל-Claude וקריאות חתומות לספקי נתוני ההונאה.

המחסנית

n8n (self-hosted, VPC)
תזמור. Docker על VM של 4 vCPU / 16GB עם queue mode ו-6 workers לטיפול בגלים.
Claude API
Sonnet לסיווג חומרה ולנימוק הונאה, Haiku לסיווג מסמכים זול.
Guidewire ClaimCenter
מקור האמת לתיק התביעה. Duck Creek Claims או Insurity ClaimsXPress כתחליפים.
PolicyCenter (חיתום)
שליפת כיסויים בתאריך הנזק. REST או SOAP — n8n מטפל בשניהם.
Textract / Document AI
OCR לדוחות משטרה, טפסי ACORD, תמונות זירת אירוע. פלט מנורמל ל-JSON עבור Claude.
LexisNexis / Verisk
סיגנלי הונאה, היסטוריית תביעות, התאמת ISO ClaimSearch. cache ל-24 שעות לבקרת עלות.
S3 (מוצפן KMS)
מסמכים, תמונות, הקלטות שיחה. מדיניות bucket חוסמת כל גישה מחוץ ל-IAM role של ה-workflow.
יומן ביקורת (QLDB / WORM)
ledger בלתי ניתן לשינוי של כל prompt, ציון, החלטת ניתוב ופעולת חוקר. מוכן ל-TPA / DOI.

הערכת עלות (6,200 FNOL בחודש)

Claude Sonnet (~6.2k קריאות חומרה + הונאה, ~3,200 tok in / 600 tok out) ~$280
Claude Haiku (סיווג מסמכים, ~12k קריאות) ~$45
Textract / Document AI (דוחות משטרה, ACORD, תמונות) ~$520
LexisNexis + ISO ClaimSearch ~$1,860
VM (n8n + Postgres + QLDB ב-AWS, בתוך VPC) ~$310
Twilio (תמלול שיחות, SMS לתובע) ~$140
סך הכל בחודש ~$3,155

בערך $0.51 ל-FNOL. עבודת פקיד הקליטה שזה מחליף עולה $4–$7 ל-FNOL במלואה; ה-LAE שנחסך מכך שהרזרבה נכונה מיום ראשון מגמד את שניהם. אותה שכבת תזמור משתלבת ב-שירותי האוטומציה ה-AI הרחבים שלנו.

1

קליטת FNOL מרובת ערוצים

FNOL מגיע בכל צורה שהתובע או הסוכן בחרו. ה-pipeline מנרמל שלושה ערוצים מרכזיים לאירוע פנימי אחד: תיבת המייל שמפקח עליה צוות התביעות, פורטל אינטרנטי שבו מבוטחים וסוכנים מגישים ישירות, ושיחות נכנסות שנתפסות דרך Twilio עם תמלול בזמן אמת.

ערוצים ושיטת לכידה

  • מייל ([email protected]): n8n IMAP node מסקרן כל 30 שניות. טפסי ACORD, דוחות משטרה, תמונות וטקסט גוף יוצאים כקבצים נפרדים. גוף המייל הופך להערה מובנית על התיק.
  • Webhook פורטל: פורטל המבוטח/סוכן עושה POST של JSON FNOL עם פרטי תובע, תיאור הנזק, תמונות אופציונליות. חתום HMAC.
  • טלפון (Twilio): DID ייעודי ל-FNOL מחוץ לשעות פעילות. התמלול של Twilio טוב מספיק כקלט גולמי — Claude מנקה אותו. ההקלטה נשארת ב-S3 להאזנה של החוקר.
  • EDI / feed שותף: לצי, רכב מסחרי, הודעות ממשכנתאי. איסוף יומי דרך SFTP ופירוק לאותה צורת אירוע פנימית.

אירוע קליטה מנורמל

כל ערוץ מומר לסכמה אחת לפני ש-node במורד הזרם רץ. זה הופך את לוגיקת החומרה, ההונאה והניתוב ללא תלויית-ערוץ.

n8n — normalized FNOL intake eventJSON
{
  "intake_id": "fnol_01HXYZ...",
  "channel": "email" | "portal" | "phone" | "edi",
  "received_at": "2026-05-03T14:22:09Z",
  "raw_source_id": "imap:msgid-...",
  "claimant": {
    "name_provided": "Maria Lopez",
    "phone": "+1-512-555-0188",
    "email": "[email protected]",
    "policy_number_provided": "AUT-3399201",
    "relationship": "insured" | "third_party" | "agent" | "attorney"
  },
  "loss": {
    "date_of_loss_provided": "2026-05-02",
    "type_provided": "auto_collision",
    "narrative": "rear-ended at stoplight on I-35...",
    "location_text": "I-35 N near exit 230, Austin TX"
  },
  "attachments": [
    { "kind": "police_report", "s3": "s3://...", "mime": "application/pdf" },
    { "kind": "photo",         "s3": "s3://...", "mime": "image/jpeg" }
  ],
  "language": "en",
  "signature": "sha256=..."
}
שים לב
אירוע אחד מגיע לעיתים קרובות פעמיים: פעם מהמבוטח למבטחת, פעם מהסוכן ש-of-record לאותה תיבה. הפעל חלון dedupe על (policy_number, date_of_loss, claimant_name) ל-72 שעות לפני פתיחת תיק חדש. הצג את ההגעה השנייה כהערה על התיק הקיים, לא ככפילות.
2

OCR וחילוץ ב-Claude

החומר הלא-מובנה הוא איפה שהעבודה האמיתית. PDF של דוח משטרה, תמונה של פגוש מקומט, מייל של ארבע פסקאות — שום דבר מזה לא ניתן לשאילתה עד שהוא הופך לשדות מובנים בתיק. ה-OCR מושך את שכבת הטקסט; Claude הופך אותה לאובייקט החילוץ הקנוני של ה-FNOL שכל שאר ה-pipeline קורא.

קסקדת OCR

  1. מסווג מסמכים (Claude Haiku): קורא רק את העמוד הראשון, מחזיר police_report, acord_2, repair_estimate, medical_bill, photo או unknown.
  2. בחירת מנוע OCR: Textract Forms+Tables ל-ACORD, Textract Queries לדוחות משטרה, Document AI לתוספות בכתב יד, Claude Vision לתמונות נזק.
  3. ניקוי PII: SSN, מספר רישיון נהיגה מלא, תאריך לידה מלא, מספרי חשבון מלאים — מוחלפים ב-tokens של 4 ספרות אחרונות לפני כל קריאת Claude חיצונית. רשימה לבנה של שדות שמותר להם לצאת מה-VPC.
  4. חילוץ של Claude: Sonnet קורא את טקסט ה-OCR + גוף המייל + התמלול ופולט את אובייקט החילוץ הקנוני.
  5. ציון ביטחון: כל שדה שביטחון בו < 0.85 מסומן לבדיקת חוקר ולעולם לא מאוכלס אוטומטית בהתאמת הפוליסה.

Prompt חילוץ של Claude

Claude system prompt — FNOL extractorTXT
You are a Property & Casualty FNOL extraction engine. You read the
OCR text of one or more documents plus a free-text claimant narrative
and emit a single JSON object describing the claim.

Rules:
- Never invent fields. If a value is not present in the source, return null.
- Quote the source span verbatim in `evidence` for every populated field.
- Confidence is your honest estimate, 0.0 to 1.0. Below 0.85 means a
  human adjuster MUST verify before the claim is opened.
- Dates as ISO-8601. Money as integer cents.
- Coverage type uses the carrier ontology in `<coverage_taxonomy>`.

Output schema (strict):
{
  "claimant_name": str|null,
  "policy_number": str|null,
  "date_of_loss": str|null,
  "time_of_loss": str|null,
  "loss_location": { "address": str|null, "lat": num|null, "lng": num|null },
  "loss_type": "auto_collision" | "auto_comprehensive" | "property_water" |
               "property_fire" | "property_theft" | "liability_bi" |
               "liability_pd" | "workers_comp" | "other",
  "vehicles": [...],
  "injuries_reported": bool,
  "injury_descriptions": [...],
  "third_parties": [...],
  "police_report_number": str|null,
  "estimated_damage_cents": int|null,
  "narrative_summary": str,    // 2-3 sentences, neutral, no speculation
  "fields": { "<name>": { "value": ..., "confidence": num,
                          "evidence": "verbatim quote" } }
}
אבטחה
הרץ חילוץ עם תוכנית ה-zero-data-retention של Anthropic ועם רשימה לבנה קשיחה של שדות שמותר לשלוח. SSN, רישיון נהיגה מלא, מספרי חשבון מלאים ומספרי תיק רפואי הופכים ל-tokens של 4 ספרות אחרונות בתוך n8n לפני שכל prompt נבנה. מפת ה-tokens חיה אך ורק בתוך ה-VPC.
3

שליפת פוליסה

ברגע שלתביעה יש מועמד למספר פוליסה (או שם תובע + תאריך לידה + מדינה להתאמה מטושטשת), ה-workflow פונה למערכת החיתום כדי לוודא שהפוליסה הייתה בתוקף בתאריך הנזק, להוציא את לוח הכיסויים ולהציף השתתפויות עצמיות וגבולות משנה. זה השלב הראשון שבו החלטת soft-fail חשובה: אם הפוליסה לא נמצאה, עדיין כותבים את ה-FNOL — פשוט מנתבים אותו לחוקר בכיר עם דגל "פוליסה לא מאומתת".

היררכיית שליפה

  1. מספר פוליסה מדויק — שליפה ישירה, ולידציה של סטטוס "in force" מול date_of_loss.
  2. סוכן + שם משפחה + מיקוד — fallback כשהתובע נתן את הפוליסה "של ההונדה סיוויק" במקום את המספר.
  3. התאמת VIN (רכב) — נשלף מ-OCR של תמונה או מדוח משטרה. הספציפיות הגבוהה ביותר לרכב.
  4. כתובת + ענף עסקי (רכוש) — התאמה מטושטשת על מיקום המבוטח, ואז סקירה אנושית של 3 המועמדים המובילים.

שליפת PolicyCenter (n8n HTTP Request)

PolicyCenter — coverage lookup at loss dateJSON
{
  "method": "POST",
  "url": "https://pc.internal.carrier.com/rest/policy/coverage-at-date",
  "headers": {
    "authorization": "Bearer {{ $credentials.policycenter.token }}",
    "x-correlation-id": "{{ $json.intake_id }}"
  },
  "body": {
    "policy_number": "{{ $json.extraction.policy_number }}",
    "as_of_date":    "{{ $json.extraction.date_of_loss }}",
    "include": ["coverages","deductibles","sublimits","named_insureds","drivers","vehicles"]
  }
}

// Response shape (truncated)
{
  "policy_number": "AUT-3399201",
  "in_force": true,
  "effective": "2025-09-12",
  "expires":   "2026-09-12",
  "named_insureds": [{ "name": "Maria Lopez", "dob_last4": "1988" }],
  "coverages": [
    { "code": "BI",  "limit_each_person_cents": 10000000, "limit_occurrence_cents": 30000000 },
    { "code": "PD",  "limit_cents": 5000000 },
    { "code": "COLL","deductible_cents": 50000 },
    { "code": "COMP","deductible_cents": 25000 },
    { "code": "UM",  "limit_each_person_cents": 5000000 }
  ],
  "vehicles": [{ "vin": "1HGCM82633A...", "year": 2019, "make": "Honda", "model": "Civic" }]
}
תובנה
תמיד שלוף כיסוי בתאריך הנזק, לא "היום". פוליסה יכולה להתבטל או להיכנס ל-non-renewal בין הנזק ובין שה-FNOL הגיע — והמבטחת עדיין חבה ניתוח כיסוי לפי מצב in-force ב-date_of_loss. קידוד קשיח של "as_of = now()" הוא הטעות הנפוצה היחידה והגדולה ביותר שאנחנו מתקנים בביקורות.
4

מסווג חומרה

דרגת החומרה מכתיבה רזרבה, רמת חוקר תביעות, התראת מפקח — תוך דקות מ-FNOL. סיווג שגוי בכל כיוון יקר: רישום שריטה כ-BI נועל רזרבת הפסדים שהמבטחת לא יכולה להפנות לשימוש אחר; רישום פציעה קטסטרופלית כ-PD בינוני מפוצץ את כל עקומת ה-loss development ומפעיל שאלות רגולטוריות מאוחר יותר. Claude קורא את אובייקט החילוץ + הפוליסה ופולט אובייקט חומרה מובנה.

חמש דרגות החומרה

tier_1_minor_pd
רק נזק רכוש, ללא פציעות, אומדן < $5k.
tier_2_moderate_pd
PD בין $5k–$25k, אפשרי PD לצד ג', ללא פציעות.
tier_3_bi_low
פציעה דווחה, ביקור מיון בלבד, ללא אשפוז.
tier_4_bi_high_or_total
אשפוז, ניתוח, או רכב באובדן מוחלט. חוקר בכיר.
tier_5_catastrophic
פטירה, פגיעת ראש, שיתוק, התנגשות רב-רכבית. הזעקת מפקח כונן.

System prompt למסווג חומרה

Claude system prompt — severity classifierTXT
You are a P&C claims severity classifier. You read a structured FNOL
extraction and the in-force policy schedule, and you assign a severity
tier and a recommended initial reserve range.

You DO NOT make coverage decisions. You DO NOT make payment decisions.
You DO NOT deny anything. A licensed adjuster owns those decisions.

Severity tiers (carrier-tuned):
- tier_1_minor_pd:        PD-only, est < $5k, no injuries
- tier_2_moderate_pd:     PD $5k-$25k, multi-party PD allowed, no injuries
- tier_3_bi_low:          BI reported, ER-only, no hospitalization
- tier_4_bi_high_or_total: hospitalization, surgery, total-loss vehicle
- tier_5_catastrophic:    fatality, brain/spinal injury, mass casualty

Output (strict JSON):
{
  "tier": "tier_1_minor_pd" | ... | "tier_5_catastrophic",
  "tier_confidence": 0.0-1.0,
  "reserve_recommendation": {
    "currency": "USD",
    "low_cents": int, "high_cents": int
  },
  "supervisor_alert_required": bool,
  "reasoning": "2-4 sentences citing the specific FNOL evidence",
  "evidence_spans": ["verbatim quote 1", "verbatim quote 2"]
}

Rules:
- If injuries_reported is true and you cannot verify ER-only, default UP
  one tier (precautionary).
- If a fatality is mentioned anywhere in the source, tier=5, confidence
  may be lower but supervisor_alert_required = true regardless.
- tier_confidence below 0.7 forces human review before reserve is set.

פלט לדוגמה

Claude — severity output for a real FNOLJSON
{
  "tier": "tier_4_bi_high_or_total",
  "tier_confidence": 0.91,
  "reserve_recommendation": {
    "currency": "USD",
    "low_cents":  1500000,
    "high_cents": 4500000
  },
  "supervisor_alert_required": true,
  "reasoning": "Claimant reports two-vehicle collision with airbag deployment and transport by ambulance to St. David's. Police report cites suspected fracture. Vehicle photos show A-pillar deformation consistent with possible total-loss assessment.",
  "evidence_spans": [
    "transported by ambulance to St. David's",
    "vehicle towed from scene, frame appears bent",
    "officer notes possible left tibia fracture"
  ]
}
תובנה
שמור את כל מחרוזת הנימוק וה-evidence spans בתיק. כשחוקר עוקף את המודל, ההחלטה והסיבה שלו הופכות לדוגמה מתויגת לכיוון ה-prompt של הרבעון הבא. אחרי שני רבעונים של override, למבטחת יש סט קליברציה ששווה יותר מכל מודל חומרה מאומן מראש של ספק.
5

ציון סיגנלי הונאה

ציון הונאה ב-FNOL הוא סיגנל הפנייה, לא החלטת דחייה. המערכת מציפה דפוסים — מצביעי תאונה מבוימת, חריגות בתדירות תביעות, ניסוח חשוד בנרטיב — ומפעילה אחת משתי פעולות: (א) כותבת הערה מסומנת לחוקר, או (ב) מייצרת הפניה רכה ל-SIU. שום דבר לא נדחה אוטומטית. אף פעם. פלט המודל לעולם לא מגיע לתובע; רק החלטת החוקר הסופית מגיעה.

ניקוד דו-שלבי

  1. שכבת כללים דטרמיניסטית — רצה ראשונה, ב-n8n. התאמת ISO ClaimSearch על אותו VIN ב-24 חודשים אחורה, מבוטח עם >3 תביעות קודמות ב-36 חודשים, נזק שדווח באיחור >14 ימים, נזק במיקוד הבית של המבוטח ללא דוח משטרה. כל כלל הוא סיגנל מתויג, לא פסק דין.
  2. שכבת נימוק של Claude — קוראת את הנרטיב + העשרת LexisNexis + סיגנלי שכבת הכללים, מפיקה ציון סיגנלי הונאה מובנה עם נימוק מפורש על הטקסט הספציפי.

סכמת פלט סיגנלי הונאה

Claude — fraud signal scoring outputJSON
{
  "fraud_signal_score": 0-100,
  "band": "low" | "elevated" | "high",
  "siu_referral_recommended": bool,
  "rules_hits": [
    { "rule_id": "ISO_HIT_24M", "weight": 0.25,
      "evidence": "matching VIN in ISO ClaimSearch, prior claim 2024-11" },
    { "rule_id": "LATE_REPORT_GT_14D", "weight": 0.10,
      "evidence": "date_of_loss 2026-04-15, FNOL received 2026-05-02" }
  ],
  "narrative_signals": [
    {
      "signal": "passive voice on key facts",
      "evidence": ""the vehicle was caused to leave the roadway""
    }
  ],
  "reasoning": "Late-report combined with prior ISO hit on same VIN and a single-vehicle nighttime loss in claimant's home zip. Recommend SIU referral; do not delay adjuster assignment.",
  "do_not_communicate_to_claimant": true,
  "model_version": "fnol-fraud-v3.2"
}

ספי ניתוב

רמה ציון פעולה
low 0–34 הערה מצורפת. הקצאת חוקר רגילה.
elevated 35–64 החוקר סוקר את הדגל בפנייה הראשונה. ייעוץ SIU אופציונלי.
high 65–100 הפניה ל-SIU חובה. החוקר ממשיך כרגיל — ללא עיכוב, ללא הבדל גלוי לתובע.
ציות
ה-Unfair Claims Practices Act בכל מדינה אוסר על שימוש בסינון הונאה כטקטיקת השהיה. שעון האישור של ה-FNOL ושעון הקצאת החוקר חייבים לא להיעצר בזמן שהפניית SIU מטופלת. בנה את ה-workflow כך שמסלול ה-band הגבוה רץ במקביל להקצאה הרגילה, אף פעם לא כשער.
6

ניתוב לחוקר תביעות

החוקר הנכון על התיק בשעה הראשונה משנה כמעט יותר מכל שלב אחר במורד הזרם. הניתוב הוא החלטה משוקללת של ענף עסקי, דרגת חומרה, מדינת התובע (חוקרים מורשים לפי מדינה), מספר תיקים פתוחים נוכחי, והעדפת שפה. הפלט הוא adjuster_id יחיד ורשימת fallback למקרה שהראשי לא במשרד.

מטריצת ניתוב (מבטחת רכב + רכוש)

חומרה רמת חוקר סמכות רזרבה SLA לפנייה ראשונה
tier_1 מסלול מהיר רכב פנימי עד $7,500 4 שעות
tier_2 רכב פנימי, סטנדרטי עד $25k 4 שעות
tier_3 מומחה BI עד $100k שעתיים
tier_4 BI בכיר / אובדן מוחלט עד $500k שעה + מפקח מקבל ping
tier_5 צוות קטסטרופה + מפקח כונן מפקח בלבד 15 דקות, page מחוץ לשעות

שאילתת ניתוב

Postgres — adjuster routing querySQL
-- Pick the lowest-loaded eligible adjuster for this LOB + severity + state.
-- Open-file count is refreshed every 5 minutes from ClaimCenter.

SELECT a.adjuster_id,
       a.full_name,
       a.open_files,
       a.languages
FROM   adjusters a
JOIN   adjuster_licenses al  ON al.adjuster_id = a.adjuster_id
WHERE  a.line_of_business = $1     -- 'auto' | 'property' | 'gl'
  AND  a.tier_max         >= $2   -- numeric tier value 1-5
  AND  a.status           = 'active'
  AND  al.state_code      = $3     -- claimant state, e.g. 'TX'
  AND  al.expires_on      > now()
  AND  ($4 = ANY(a.languages))     -- claimant preferred language
ORDER  BY a.open_files ASC,
          a.last_assigned_at ASC
LIMIT  3;

אם הראשון ברשימה לא במשרד (אינטגרציית יומן), ה-workflow עובר על LIMIT 3. אם כל השלושה לא זמינים, התיק מנותב לתור המפקח עם דגל. המפקח אף פעם לא רואה tier_1 של מסלול מהיר אלא אם כל חוקרי המסלול המהיר במדינה לא זמינים — וזו הסלמה נכונה, לא נפילה לתור איטי יותר.

7

פתיחת תיק תביעה ואישור

ברגע שהחומרה, ההונאה והניתוב הוכרעו, ה-workflow פותח את תיק התביעה ב-Guidewire ClaimCenter, מצרף כל מסמך ותמונה, מקבע את טווח הרזרבה המומלץ, מפרסם את הערות ה-AI (מסומנות בבירור כפלט מודל) ומקצה לחוקר שנבחר. התובע מקבל SMS ומייל אישור עם מספר התביעה, שם החוקר שהוקצה ו-SLA לפנייה הראשונה אליו.

payload פתיחת תיק ב-ClaimCenter

Guidewire ClaimCenter — POST /rest/claim/v1/claimsJSON
{
  "policy_number":   "AUT-3399201",
  "loss_date":       "2026-05-02",
  "reported_date":   "2026-05-03T14:22:09Z",
  "loss_type":       "auto_collision",
  "loss_location":   { "address": "I-35 N exit 230, Austin TX" },
  "claimant": {
    "name":  "Maria Lopez",
    "phone": "+1-512-555-0188",
    "email": "[email protected]",
    "preferred_language": "en"
  },
  "ai_metadata": {
    "intake_id":          "fnol_01HXYZ...",
    "severity_tier":      "tier_4_bi_high_or_total",
    "severity_confidence":0.91,
    "reserve_low_cents":  1500000,
    "reserve_high_cents": 4500000,
    "fraud_band":         "elevated",
    "siu_referral":       false,
    "human_review_required": false,
    "model_versions": {
      "extractor":  "fnol-extract-v4.1",
      "severity":   "fnol-severity-v3.0",
      "fraud":      "fnol-fraud-v3.2"
    }
  },
  "assigned_adjuster_id": "ADJ-1188",
  "documents":  [...],
  "ai_notes":   "Auto-generated by intake workflow — see ai_metadata. Adjuster review required before any coverage decision or payment."
}

אישור לתובע (SMS + מייל)

האישור נכתב על ידי Claude עם תבנית מוגבלת בהדוקות. הוא לעולם לא מצטט לתובע את פלט החומרה או ההונאה של המודל. הוא מציין את מספר התביעה, שם החוקר, ה-SLA לפנייה ומה לשלוח בהמשך.

Twilio SMS payload — claimant ackJSON
{
  "to":   "+15125550188",
  "from": "+18335550100",
  "body": "Hi Maria — your claim CLM-2026-118334 has been opened. Sara Patel ([email protected]) is your adjuster and will call you within 1 hour. Reply STOP to opt out of claim updates."
}
תובנה
ציון שם החוקר במסר הראשון מוריד את שיחות "מי מטפל בתביעה שלי?" הנכנסות ב-60–70% במשך 48 השעות הראשונות. החיסכון במוקד לבדו לרוב מכסה את כל ה-pipeline בקנה מידה של מבטחת.

ציות: ביקורת TPA, רגולטור מדינתי (DOI), בולטין NAIC

ענף הביטוח מפוקח ברמת המדינה על ידי ה-Department of Insurance של כל מדינה, עם חוקי מודל מתואמים דרך ה-NAIC. AI בתביעות מטופל מפורשות ב-NAIC Model Bulletin on the Use of AI Systems by Insurers (2024) ואומץ באיזושהי צורה ברוב המדינות. התייחס לציות כעמוד שדרה של העיצוב, לא כתוספת בסוף.

כללים נוקשים שמכתיבים את הארכיטקטורה

  • ללא דחייה אוטומטית. פלט המודל לעולם לא מייצר החלטת כיסוי, מכתב דחייה או תשלום. חוקר תביעות מורשה חותם על כל פעולה שלילית.
  • ללא האשמת הונאה אוטומטית. הפניית SIU היא פנימית. התובע לעולם לא רואה הודעת "אנו חושדים בהונאה" שנוצרה על ידי המודל.
  • שעון האישור. רוב חוקי ה-UCPA המדינתיים דורשים אישור בכתב תוך 10–15 ימים; האישור של ה-workflow תחת 90 שניות עוקף את הסטנדרט בריווח גדול. תעד את ה-timestamp ב-ledger הביקורת.
  • חוקר אחראי. כל מדינה דורשת חוקר תביעות מורשה על כל תביעה. ה-assigned_adjuster_id הוא האדם האחראי מבחינת הרגולטור, ללא קשר לאופן שבו הניתוב הוכרע.
  • Model card. בולטין ה-NAIC מצפה למסמך ממשל מודל פנימי שמכסה את נתוני האימון, השימוש המיועד, מגבלות ידועות ונקודות פיקוח אנושיות. מסווג החומרה משוגר עם אחד; עדכונים דורשים העלאת גרסה רשמית.

יומן ביקורת בדרגת TPA

יומן הביקורת הוא המסמך שהמבטחת מוסרת ל-TPA, למבקר חיצוני או לחוקר DOI מדינתי. הוא חייב להיות בלתי ניתן לשינוי, מלא וניתן לשאילתה לפי תיק ולפי חוקר. AWS QLDB או כל אחסון WORM שווה ערך עובדים; הסכמה למטה היא מה שאנחנו משגרים.

Audit log entry — one record per workflow stepJSON
{
  "audit_id":      "aud_01HXYZ...",
  "claim_number":  "CLM-2026-118334",
  "intake_id":     "fnol_01HXYZ...",
  "step":          "severity_classification",
  "actor":         "system:claude-sonnet-4-5",
  "actor_version": "fnol-severity-v3.0",
  "input_hash":    "sha256:b41d...",
  "output_hash":   "sha256:c0a9...",
  "input_summary": "extraction object + policy schedule (PII redacted)",
  "output":        "tier_4_bi_high_or_total, conf 0.91",
  "human_override": null,
  "occurred_at":   "2026-05-03T14:22:31Z",
  "correlation_id":"req_01HXYZ...",
  "prev_audit_id": "aud_01HXYW...",
  "ledger_hash":   "sha256:..."
}

Model card (תקציר ממסווג החומרה)

  • שימוש מיועד: סיגנל טריאז' לדירוג וניתוב ב-FNOL. המלצת רזרבה בלבד.
  • מחוץ לתחום: הכרעות כיסוי, מכתבי דחייה, סכומי פשרה, אסטרטגיית שיבוב.
  • סט קליברציה: 24 חודשי תביעות סגורות פנימיות של המבטחת, מרובדות לפי tier.
  • מגבלות ידועות: נוטה לתת-סיווג כשנרטיב הפציעה דליל בהגשות פורטל; מטופל על ידי כלל השדרוג הזהיר כש-injuries_reported הוא true.
  • סקירת הטיה: ביקורת התפלגות tier רבעונית לפי מיקוד התובע ושפה. כל drift >5% מפעיל סקירת prompt.
  • פיקוח אנושי: tier_5 מפעיל page למפקח; tier_confidence < 0.7 כופה סקירה אנושית לפני קביעת רזרבה; כל החלטה שלילית מוכרעת על ידי אדם.
ציות
הרץ עם תוכנית ה-zero-data-retention של Anthropic. המבטחת בעלת ה-prompt, המבטחת בעלת יומן הביקורת, ושום נתון תביעה לא משמש לאימון מודלים חיצוניים. זו הקונפיגורציה שרוב ה-DOIs המדינתיים והמבקרים החיצוניים מצפים לראות כשהם שואלים "לאן הולכים נתוני בעל הפוליסה?"

תוצאות נמדדות — אחרי 90 יום

מספרים מפריסה אצל מבטחת אזורית (~6,200 FNOL בחודש, 38 חוקרים פנימיים, צוות SIU של 3 ומפקח כונן יחיד) אחרי הרבעון המלא הראשון. נפח התביעות נשאר זהה — כל הרווח מגיע ממהירות, מדיוק חומרה ומהקצאה מחדש של עבודה.

זמן טיפול ב-FNOL
11ש' ← 84ש'
חציון, מקליטה לאישור
דיוק סיווג חומרה
93%
מול tier סופי של החוקר
תפיסת הונאה (מול שנה קודמת)
x3.4
הפניות SIU בקליטה
פרודוקטיביות חוקר
+38%
תביעות סגורות / חוקר / חודש
תלונות DOI
−54%
קשורות ל-FNOL, מול 90 ימים קודמים
התאמת רזרבה ביום 1
+22pp
בטווח 25% מהתשלום הסופי

המדד שעניין את ה-Chief Claims Officer הכי הרבה: סיווגי חומרה שגויים שנתפסו בהקצאה מחדש ירדו מ-14% ל-4%. זה המספר שמאפשר לצוות האקטוארי לבטוח ברזרבה של יום 1 מספיק כדי לשחרר IBNR משנים קודמות בביטחון — המנוף הפיננסי במורד הזרם של התאמת ה-tier כבר ב-FNOL גדול בהרבה מהחיסכון התפעולי המובן מאליו.

לוח זמנים ועלות יישום

מסלול DIY
280 – 420 שעות
  • n8n self-host + VPC + סקירת InfoSec: 30–50 שעות
  • קליטה מרובת ערוצים (מייל + פורטל + Twilio): 24–36 שעות
  • קסקדת OCR + טוקניזציית PII: 30–46 שעות
  • Prompt חילוץ של Claude + backtest מול golden-set: 28–40 שעות
  • אינטגרציית PolicyCenter + לוגיקת as-of-date: 24–36 שעות
  • מסווג חומרה + קליברציית רזרבה: 30–44 שעות
  • שכבת כללי הונאה + LexisNexis + ISO ClaimSearch: 32–48 שעות
  • אינטגרציית ClaimCenter + audit ledger: 40–60 שעות
  • ניתוב חוקרים + מטריצת רישוי/מדינה: 18–28 שעות
  • Model card, מסמכי ממשל, תיק ל-DOI: 16–24 שעות
  • הדרכת חוקרים + מפקחים: 10–14 שעות
עם SEOKRU
פריסה ב-10 שבועות
  • שבוע 1–2: Discovery, golden-set FNOLs, kickoff InfoSec / Compliance
  • שבוע 3–4: קליטה (מייל + פורטל + Twilio) + קסקדת OCR
  • שבוע 5–6: חילוץ Claude + מסווג חומרה + קליברציה
  • שבוע 7: כללי הונאה + LexisNexis + ISO ClaimSearch
  • שבוע 8: אינטגרציית ClaimCenter + audit ledger
  • שבוע 9: shadow-run לצד קליטה חיה (ללא יצירה אוטומטית)
  • שבוע 10: Cutover לפי ענף עסקי, מסירה למפקחים
  • כולל: model card, חבילת ממשל מוכנה ל-DOI, דוח drift חודשי
קבל יישום מותאם ←

שאלות נפוצות

לא. כל הכרעת כיסוי, דחייה, תשלום ופשרה נעשות על ידי חוקר תביעות מורשה אנושי — זו דרישה רגולטורית וגם בחירה מודעת בעיצוב. מה שמשתנה זה מה החוקר עושה ב-30 הדקות הראשונות של התיק. במקום להקליד נתוני FNOL ל-ClaimCenter מתוך PDF, הוא סוקר תיק שכבר מאוכלס מראש עם דרגת חומרה, טווח רזרבה, פוליסה מצורפת ודגלי הונאה שהוצפו. חוקרים אצל מבטחות שעבדנו איתן מתארים את זה כמעבר מהזנת נתונים לטיפול תביעות אמיתי.
לא, וזה לא נתון למשא ומתן. למערכת אין שום סמכות דחייה. המסווג פולט דרגת חומרה והמלצת רזרבה; מודול ההונאה פולט סיגנל הפניה; אף אחד מהם לא מייצר פעולה שלילית כלפי התובע. ה-Unfair Claims Practices Act של כל מדינה ובולטין ה-NAIC על AI מניחים שחוקר אנושי הוא הבעלים של החלטות שליליות, וה-workflow אוכף את זה עם guardrails מפורשים ב-prompt, בלוגיקת התזמור וביומן הביקורת.
שלוש שכבות. ראשית, ה-prompt מגדיר את ה-tiers במונחי פציעה ונזק, אף פעם לא במאפייני התובע. שנית, אנחנו מתחזקים ביקורת הטיה רבעונית שמשווה התפלגות tier לפי מיקוד התובע, שפה ודמוגרפיה מדווחת היכן שנאספת — drift >5% בכל ציר מפעיל סקירת prompt וסט נתונים. שלישית, כלל השדרוג הזהיר (כשפציעה דווחה אך לא אומתה, ברירת מחדל היא העלאת tier) מגן מפני שגיאות תת-סיווג שיפגעו באופן לא פרופורציונלי בתובעים עם נרטיבים דלילים. ה-model card מתעד את שלוש השכבות, וגם את הרכב סט הקליברציה.
לפחות שלושה ארטיפקטים: (1) יומן הביקורת של התביעה הספציפית, שמראה כל פלט מודל, כל override אנושי וכל שלב workflow עם timestamps; (2) ה-model card ומסמכי הממשל שהיו בתוקף בתאריך הנזק, נעולים לגרסה; (3) הערת החוקר המורשה על כל החלטה שלילית. ה-ledger הבלתי ניתן לשינוי בסגנון QLDB אומר שהרגולטור יכול לוודא ששום דבר לא נכתב מחדש בדיעבד. עברנו ביקורות מבטחת שבהן סט הארטיפקטים הזה הפך מה שהיה אמור להיות שישה שבועות של חיפוש מסמכים לתגובה של יומיים.
אותה ארכיטקטורה, node סנכרון אחר. ל-Duck Creek Claims יש REST ומשטח SOAP חזק; ClaimsXPress של Insurity הוא REST-first. בלוק ה-ai_metadata, שדות יומן הביקורת ו-model card לא משתנים — רק מיפוי payload יצירת תביעה משתנה. שיגרנו את זה על שלושתם; האינטגרציות של ClaimCenter, DCT ו-ClaimsXPress דומות במאמץ.
Claude רב-לשוני מקצה לקצה, אז ה-prompts לחילוץ ולחומרה רצים על טקסט בשפת המקור ללא תרגום. תבנית האישור נרנדרת בשפה המועדפת של התובע מהפוליסה או מאירוע הקליטה. שאילתת הניתוב מסננת חוקרים לפי שפה, כך שתובע דובר ספרדית מותאם לחוקר מורשה ספרדית במדינה הנכונה. יומן הביקורת שומר את השפה שבה רץ כל שלב, מה שה-DOI לעתים מבקש בבדיקות market conduct.
כל אחד מאלה הוא ספק חזק בפלח ספציפי — Tractable להערכת תמונות נזק, Snapsheet לחוויית תביעות דיגיטלית, Shift לאנליטיקת הונאה. הם לא תחליף ל-workflow קליטה-וטריאז' מקצה לקצה; הם שירותים שאפשר לחבר לאחד. גישת n8n + Claude נותנת את עמוד השדרה של התזמור, את יומן הביקורת ואת ממשל המודל, עם מודולים של ספקים משובצים היכן שהם מנצחים. המבטחת בעלים של ה-prompts, של לוגיקת הניתוב ושל זרימת הנתונים — לא של roadmap מוצר של ספק.
שלוש קצב חודשי. (1) דוח drift — התפלגות דרגות חומרה, התפלגות bands של הונאה, שיעור override לפי חוקר. (2) כיוון prompt — בדרך כלל סבב אחד לרבעון, מונע מדפוסי override. (3) רענון model card — נעול לגרסה, עם חתימה פנימית של ה-Chief Claims Officer. עומס ההנדסה השוטף עומד על 8–14 שעות בחודש למבטחת של 6,000 FNOL, פלוס זמן הסקירה של הנהלת התביעות. אנחנו עוטפים את זה ב-retainer של אוטומציות לשירותים פיננסיים הרחב יותר ללקוחות שרוצים שזה ינוהל.

רוצה שזה ייבנה לתפעול התביעות שלך?

SEOKRU פורסת את המערכת הזו בדיוק ב-10 שבועות, מקצה לקצה. אנחנו עושים backtest למסווג החומרה מול 24 חודשי תביעות סגורות שלך, מחווטים את קסקדת ה-OCR ושליפת הפוליסה, משלבים ClaimCenter (או DCT / ClaimsXPress) ומשגרים את ה-model card, מסמכי הממשל ויומן הביקורת המוכן ל-DOI. המבטחת שומרת על בעלות מלאה על כל רכיב — workflows, prompts, audit ledger, הכל.

דבר עם מהנדס אוטומציה לביטוח