הגשת תביעת ביטוח דיגיטלית

עובדה: היעד העסקי המרכזי - קיצור משך הזמן מרגע הגשת התביעה ועד החלטה או תשלום בתביעות דירה. עובדה: יעד משני - הפחתת העומס הידני על מיישבי תביעות על ידי יישוב אוטומטי של תביעות קטנות וברורות. עובדה: יעד שלישי - עמידה עקבית בלוחות הזמנים הרגולטוריים ליישוב תביעות והפחתת תלונות. עובדה: קהל היעד - מבוטחי ביטוח דירה שמגישים תביעה דרך האפליקציה והאתר. הנחה: יעד מדיד לגרסה ראשונה - קיצור של 30%-40% במשך הטיפול הממוצע בתביעות דירה שנכנסות דיגיטלית, תוך שני רבעונים. המספר טעון אימות מול baseline. הנחה: יעד ליישוב אוטומטי - 20%-30% מתביעות הדירה הקטנות ייושבו במסלול מהיר בלי מגע ידני. יעד שמרני בכוונה כי חלק מהתביעות תמיד ידרוש שמאי. עובדה: בהיקף הגרסה הראשונה - הגשת תביעת דירה דיגיטלית עם הנחיה מותאמת למסמכים, העלאת תמונות ומסמכים, טריאז' אוטומטי למסלול (מהיר / מיישב / שמאי), מעקב סטטוס, ותשלום מהיר בתביעות שאושרו במסלול המהיר. עובדה: מחוץ להיקף הגרסה הראשונה - תביעות רכב וצד ג', שיחת וידאו עם שמאי, וזיהוי הונאה מבוסס מודל מתקדם. אלה מועמדים לגרסאות הבאות. הנחה: הבידול שלנו הוא הטריאז' האוטומטי והתשלום המהיר, לא עוד טופס דיגיטלי. לכן הם נכנסים כבר לגרסה ראשונה ולא נדחים. הנחה: אילוץ רגולטורי - כל החלטה במסלול אוטומטי חייבת לשמור תיעוד ונימוק, ולאפשר ערעור ומעבר לטיפול אנושי. מובנה בדרישות ולא תוספת.

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

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

עובדה: Epic 1 - טופס הגשת תביעה דיגיטלי מותאם לסוג הנזק, כולל העלאת תמונות ומסמכים והנחיה דינמית. זו נקודת הכניסה של המבוטח. הנחה: הערכה גסה 12-18 ימי פיתוח כולל צד קליינט ושרת. טעון חידוד מול הצוות. עובדה: Epic 2 - מנוע הטריאז' וסיווג המסלול. הלוגיקה שמסווגת תביעה למסלול מהיר / מיישב / שמאי לפי סוג נזק, סכום, כיסוי ואיתותי סיכון. הנחה: זה ה-Epic הכבד והקריטי ביותר. הערכה גסה 20-30 ימי פיתוח כולל אינטגרציה למערכת הפוליסות. תלוי בזמינות נתוני כיסוי. עובדה: Epic 3 - בדיקת כיסוי והשתתפות עצמית מול הפוליסה הספציפית. אינטגרציה למערכת הליבה של הפוליסות. הנחה: תלוי בממשק ממערכת הליבה, סיכון תלות חיצונית. הערכה גסה 10-15 ימי פיתוח. עובדה: Epic 4 - מעקב סטטוס ותקשורת למבוטח, כולל מה חסר, צפי זמן, והתראות עדכון. הנחה: יחסית עצמאי, יכול לרוץ במקביל ל-Epic 2. הערכה גסה 8-12 ימי פיתוח. עובדה: Epic 5 - תשלום מהיר במסלול המהיר, כולל אישור הסכום על ידי המבוטח והוצאת תשלום התגמול. הנחה: תלוי ב-Epic 2 ובאינטגרציה למערכת התשלומים. מועמד לדחייה אם התשלום המהיר מסתבך. הערכה גסה 8-12 ימי פיתוח. עובדה: Epic 6 - מדידה ואנליטיקה. הטמעת אירועים, שיוך מסלול לתוצאה, ותשתית ל-KPI. הנחה: חייב להיכנס כבר לגרסה ראשונה, אחרת לא נדע אם הפיצ'ר עובד. הערכה גסה 5-8 ימי פיתוח. הנחה: תיעדוף מוצע - Epic 3 ו-2 קודם (כיסוי וטריאז' הם הבסיס), אחריהם 1 ו-4 שנותנים את החוויה, ו-5 ו-6 להשלמת הערך והמדידה. Epic 5 יכול להידחות בלי לחסום את הגרסה.

עובדה: Story A - הגשה מודרכת. כמבוטח, אני רוצה שיגידו לי בדיוק מה לצרף לפי סוג הנזק, כדי לא לשלוח מסמכים חסרים ולא לחזור על התהליך. עובדה: Acceptance - בהינתן שהמבוטח בחר סוג נזק, כשהוא ממשיך, אז מוצגת רשימת פרטים ותמונות מותאמת לאותו סוג נזק, ולא ניתן להגיש בלי הפריטים המסומנים כחובה. עובדה: Story B - סיווג מסלול. כמבוטח, אני רוצה שהתביעה תנותב מיד לטיפול הנכון, כדי לא לחכות סתם. עובדה: Acceptance - בהינתן תביעה מתחת לתקרה עם סוג נזק מוכר, תיעוד תקין וללא איתות סיכון, כשהיא מוגשת, אז היא מסווגת למסלול מהיר ומוצג למבוטח סכום תגמול צפוי לאישור. עובדה: Acceptance - בהינתן חוסר מסמך, סכום לא ודאי, או איתות סיכון, כשהתביעה מוגשת, אז היא מנותבת למיישב אנושי עם סימון הסיבה, בלי אישור או דחייה אוטומטיים. עובדה: Story C - שקיפות סטטוס. כמבוטח, אני רוצה לראות בכל רגע מה מצב התביעה ומה חסר, כדי לא להתקשר למוקד. עובדה: Acceptance - בהינתן תביעה פתוחה, כשהמבוטח נכנס אליה, אז מוצג הסטטוס הנוכחי, פריטים חסרים אם יש, וצפי זמן לטיפול לפי לוחות הזמנים. עובדה: Story D - מעבר לאדם וערעור. כמבוטח, אני רוצה לבקש טיפול אנושי או לערער על החלטה, כדי שלא אישאר תקוע מול מערכת. עובדה: Acceptance - בהינתן החלטה אוטומטית כלשהי, כשהמבוטח מבקש בדיקה אנושית, אז התביעה עוברת למיישב עם כל התיעוד, וההחלטה האוטומטית מסומנת כממתינה לבדיקה. הנחה: Story E - תשלום מהיר. כמבוטח, אני רוצה לקבל את הכסף מהר בתביעה ברורה, כדי לטפל בנזק בלי להמתין. הנחה: Acceptance מוצע - בהינתן תביעה במסלול מהיר שהמבוטח אישר את סכומה, כשהאישור ניתן, אז התשלום יוצא לפי ה-SLA שנקבע. תלוי בכניסת Epic 5 לגרסה ראשונה.

עובדה: תרחיש קריטי - אישור אוטומטי שגוי. המערכת מאשרת תשלום על נזק לא מכוסה או על סכום שגוי במסלול המהיר. זה התרחיש המסוכן ביותר - כסף שיוצא בטעות וקשה להשיב. עובדה: בדיקה - לוודא שהמסלול המהיר חל רק מתחת לתקרה, עם כיסוי מאומת ובלי איתות סיכון, ולבדוק ידנית מדגם של יישובים אוטומטיים מול הפוליסה. עובדה: תרחיש קריטי שני - דחייה אוטומטית שגויה. אסור שהמערכת תדחה תביעה לבד. הבדיקה - לוודא שבמצב לא ודאי התביעה עוברת לאדם ולא נדחית אוטומטית. עובדה: מצב קצה - פוליסה שאינה בתוקף במועד האירוע, או אירוע שקדם לתחילת הכיסוי. הבדיקה - זיהוי נכון ומעבר לטיפול מתאים בלי אישור אוטומטי. עובדה: מצב קצה - נזק שחלקו מכוסה וחלקו לא. הבדיקה - לא לאשר את כל הסכום אוטומטית; להפנות לאדם או לפצל רק לפי מדיניות מאושרת. עובדה: מצב קצה - תביעה כפולה על אותו אירוע, או הגשה חוזרת אחרי דחייה. הבדיקה - זיהוי כפילות ומניעת תשלום כפול. עובדה: תיעוד - תמונות באיכות נמוכה, פורמט לא נתמך, קבצים כבדים מדי, או קובץ פגום. הבדיקה - הודעה ברורה למבוטח בלי לקרוס ובלי לאבד את מה שכבר הועלה. הנחה: צריך בדיקת פרטיות ואבטחה על מסמכים רגישים שמועלים (תעודות, חשבוניות), כולל הרשאות גישה ומדיניות שמירה. טעון אישור מדיניות. עובדה: רגרסיה - וידוא שתהליך התביעה הקיים (טלפוני וידני) ממשיך לעבוד במקביל, ושתביעה שנכנסה דיגיטלית לא נופלת בין הכיסאות אם המבוטח עובר לערוץ אחר. הנחה: כדאי הרצת shadow mode - להריץ את הטריאז' ברקע בלי לפעול לפיו, ולהשוות את החלטותיו מול החלטות מיישב אנושי לפני הפעלה מלאה.

עובדה: KPI ראשי - משך הזמן מהגשת התביעה ועד החלטה או תשלום בתביעות דירה, לפני ואחרי החשיפה לפיצ'ר. עובדה: KPI ראשי שני - שיעור התביעות שיושבו במסלול המהיר בלי מגע ידני, מתוך כלל התביעות הדיגיטליות. הנחה: היעד - קיצור של 30%-40% במשך הטיפול ו-20%-30% יישוב אוטומטי תוך שני רבעונים. יעדים לאימות מול baseline. עובדה: KPI רגולטורי - שיעור העמידה בלוחות הזמנים ליישוב תביעות ומספר החריגות, כמדד סיכון. עובדה: KPI מוצרי - שיעור השלמת ההגשה (מבוטחים שהתחילו והגישו), שיעור המסמכים החוזרים, ושיעור המעבר לטיפול אנושי מתוך המסלול המהיר. עובדה: KPI חוויה - שביעות רצון אחרי סגירת תביעה ושיעור פניות למוקד סביב סטטוס. עובדה: אירועים לתיעוד - claim_started (עם סוג נזק), claim_submitted (עם מספר מסמכים וסכום משוער), triage_decided (עם המסלול והסיבה), document_rejected, status_viewed, human_review_requested, payout_issued (עם הסכום והזמן עד תשלום). עובדה: כדי לקשור החלטה לתוצאה, כל אירוע triage_decided יישא את המסלול שנבחר, כדי להשוות משך טיפול ושביעות רצון בין המסלולים. הנחה: השוואה הוגנת דורשת rollout מדורג עם קבוצת ביקורת, ולא רק לפני-אחרי, כי נפח וסוגי התביעות משתנים לפי עונה (למשל נזקי מים בחורף). הנחה: תביעה יכולה להיסגר שבועות אחרי ההגשה, ולכן צריך חלון שיוך שמלווה את התביעה עד סגירתה. הנחה: אירועי התביעה נוגעים בנתונים אישיים ורגישים ולכן דורשים מדיניות שמירה ואנונימיזציה לפני ניתוח.

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

עובדה: המצב - הושלמו ה-Business Brief, ה-BRD, ה-PRD, פירוק ל-Epics וסיפורי משתמש. תוכנית מדידה ובריף דשבורד מוכנים. אנחנו לפני תחילת פיתוח. עובדה: הבעיה שאנחנו פותרים - הגשת תביעת דירה היום ידנית ומפוצלת, איטית, ומטופלת אדם-אדם גם בתביעות קטנות וברורות. זה מאריך זמנים, מעמיס על מיישבים, ומסכן עמידה בלוחות הזמנים הרגולטוריים. עובדה: הפתרון בגרסה ראשונה - הגשה דיגיטלית מודרכת, טריאז' אוטומטי למסלול הנכון, מעקב סטטוס שקוף, ותשלום מהיר בתביעות ברורות. עובדה: היעד - קיצור של 30%-40% במשך הטיפול ו-20%-30% יישוב אוטומטי בתביעות דירה תוך שני רבעונים מהעלייה לאוויר. הנחה: היעדים ניתנים לאימות רק אחרי שנקבע baseline מדויק מנתוני יישוב התביעות. עובדה: מצב תחרותי - מבטחים דיגיטליים כבר מציעים הגשה דיגיטלית ומעקב. הבידול שלנו הוא הטריאז' האוטומטי והתשלום המהיר, לא עוד טופס. לא מתחרים על אותו פיצ'ר בודד. עובדה: הסיכון המרכזי - החלטה אוטומטית שגויה, גם אישור וגם דחייה. אישור שגוי מוציא כסף בטעות; דחייה שגויה פוגעת במבוטח וחושפת לתלונה. המענה - תקרת סכום נמוכה, כיסוי מאומת, מעבר לאדם בכל אי-ודאות, ו-shadow mode לפני הפעלה. הנחה: הסיכון השני - התלות במערכת הפוליסות לבדיקת כיסוי. אם הממשק לא יהיה מוכן בזמן, הטריאז' ייחסם. נדע רק אחרי בירור מול צוות הליבה. עובדה: החלטות נדרשות מההנהלה - אישור היעדים מול baseline, החלטה האם התשלום המהיר (Epic 5) נכנס לגרסה ראשונה, ואישור הרצת rollout מדורג עם קבוצת ביקורת למדידה נקייה.