אוטומציה של הסדרת תביעות: צ'אטבוט בינה מלאכותית לדיווח ראשוני תוך 3 דקות

צ'אטבוט AI בביטוח: מדוע FNOL נתקע

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

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

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

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

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

מה משתנה לאחר הטמעת אוטומציה בטיפול בתביעות

איסוף נתונים בסשן אחד

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

העומס על הנציגים מתחלק מחדש

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

סוג שלם של שגיאות קלט נעלם

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

עלות הטיפול בתביעה אחת

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

זה נראה בשלושה מדדים: הזמן עד להגשת ההצהרה, שיעור ההצהרות ללא תיקונים, ומספר הנגיעות של נציג בתביעה.

מצבי פעולה: תרחישי, NLP והיברידי

מצב הפעולה קובע לא את ה״תחכום״ של הבוט, אלא את שיעור הפניות שמגיעות לנציג, ואת שלמות כרטיס התביעה. דיאלוג תרחישי מתנהל לפי עץ שאלות שנבנה מראש; מצב NLP מנתח טקסט חופשי ומחלץ ישויות — תאריך, נסיבות, משתתפים — ואילו המצב ההיברידי עובר בין הגישות תוך כדי השיחה עצמה.

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

השוואת המצבים

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

שלבי הטמעת האוטומציה בתהליך הטיפול

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

1. ביקורת תהליך הטיפול. אנחנו בוחנים את ערוצי קבלת הפניות, מי ובאיזה שלב מקבל החלטה, והיכן הפנייה ממתינה לתשובה ימים. התוצאה — מפת תהליך ורשימת חריגים, שאותם צ'אטבוט AI מעביר מיד לאדם.

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

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

4. בדיקות על פניות היסטוריות. בודקים ענפי כשל: פוליסה לא נמצאה, מקרה מחוץ לכיסוי, מערכת סמוכה אינה זמינה. מחשבים את שיעור השיחות שנסגרו ללא מומחה.

5. פיילוט על חלק מהזרם. משווים למודל הקודם לפי הזמן עד רישום ההצהרה ולפי שלמות הנתונים שנאספו.

6. מסירה. תיעוד, נוהל הסלמות, פאנל ניטור, הדרכת הצוות. בהמשך — עדכוני תרחישים למוצרים חדשים.

מה כלול באספקה: תוצרים ותיעוד

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

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

בנפרד נמסר יומן קבלה: אילו מסלולים נבדקו, על אילו נתונים ובאיזו תוצאה. זה מאפשר לאשר את העבודה לפי עובדות, ולא לפי הדגמה.

מקרה בוחן: קיצור זמן הטיפול מ-2 ימים ל-3 דקות

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

מה עשינו

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

צ'אטבוט AI מנהל את הדיאלוג באזור האישי באתר ובמסרים מיידיים: מזהה מסמכים ותצלומי נזקים, שולף את נתוני הפוליסה, בודק אותם לסתירות ומעביר הצהרה מוכנה לשמאי. אם המקרה אינו שגרתי, השיחה עוברת למומחה אנושי יחד עם היסטוריית ההתכתבות והנתונים שכבר נאספו.

התוצאה במספרים

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

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

כיצד לחדש אוטומציה קיימת של הטיפול בתביעות?

החלפה נדרשת לעתים רחוקות. בדרך כלל תרחיש-העץ הקיים נשאר כפי שהוא, ולצידו מתווספת תוספת AI: היא מנתחת את הטקסט החופשי של הלקוח — מהות האירוע, הנסיבות — ומעבירה לעץ שדות שכבר מולאו. הצ'אטבוט הקלאסי ממשיך להיות אחראי על הנהלים: סוג ההסכם, הסטטוס, וענפים עם ניסוחים בעלי תוקף משפטי.

השדרוג מתבצע בשלושה מקומות. בקלט, ה-AI מתרגם טקסט וקול לשדות ההצהרה ובודק את שלמותם. באמצע — האינטגרציה: התרחיש קורא למתודות של מערכת הרישום, שבה נמצאים ההסכמים והתביעות, ואינו משכפל דבר.

בפלט — היומן: החלטת המודל נשמרת יחד עם דבר הלקוח המקורי, כך שבמקרה של טיפול שנוי במחלוקת יהיה מה להציג.

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

את זה בודקים בבדיקה אחת: אם הצ'אטבוט הקלאסי בנוי, למשל, על Dialogflow CX, הרי שלפלטפורמה יש קריאות תכנות וגרסאות של תרחישים — והתוספת יושבת מעל.

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

ספקות טכניים: מה לבדוק לפני ההתחלה

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

באמצעות מה הבוט מתחבר למערכת הרישום?

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

באיזו מידה מזוהה הפנייה במדויק?

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

האם הפתרון יעמוד בשיא הפניות?

העיבוד מתרחב אופקית: עם גידול בזרם מתווספים צמתי עבודה, וזמן התגובה אינו גדל. אירועים המוניים — ברד, שיטפון — נבדקים בבדיקת עומס לפני ההשקה.

מה כלול בתמיכה לאחר ההשקה?

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

נדון במשימת האוטומציה של הטיפול בתביעות

צ'אטבוט AI לביטוח מתחיל לא בקוד, אלא בניתוח התהליך שלכם: כיצד מגיעה הפנייה, מי מתעד את התביעה, והיכן הולך לאיבוד הזמן. תארו את המשימה — נחזור עם הערכה ותוכנית: נפרק את השלבים, נראה אילו נתונים נדרשים וכיצד הפתרון ישתלב במתחם הטיפול הנוכחי.

כדי לחזור עם תוכנית ולא עם מילים כלליות, אנחנו מנתחים כבר בהתחלה:

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

השלב הבא — שיחה קצרה לעניין: אתם מתארים את התהליך, ואנחנו חוזרים עם הערכה, תוכנית עבודה וגבולות הגרסה הראשונה. מכאן נתאם את ההיקף ונתחיל בעבודה.