ניתוח סדרות זמן בביטוח: מה מוכר, מתי ולמה זה חשוב

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

הדרך היעילה ביותר לצמצם את הפער הזה היא EDA (Exploratory Data Analysis) ממושמע: להבין מה עובד (מוצרים/כיסויים/סוגי פוליסות), ומתי זה קורה (עונתיות, ימים ושעות). המאמר שעליו נשענים כאן עשה את זה לעולם הקמעונאות באמצעות Pandas; אני לוקח את אותה מתודולוגיה ומתרגם אותה לשפת הביטוח וניהול הסיכונים—בדיוק בקו של סדרת התוכן שלנו, “בינה מלאכותית במוסדות פיננסיים ו‑FinTech”.

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

EDA בביטוח: לא “נחמד שיש”, אלא בסיס לתמחור וחיתום

הצעד הראשון הוא להפסיק להתייחס ל‑EDA כשלב טכני. בביטוח, EDA הוא שלב עסקי לכל דבר:

• בחיתום: להבין אילו כיסויים/ענפים מייצרים פרמיה איכותית מול הפסד צפוי.
• בתמחור: לזהות עונתיות בתביעות ולהתאים תעריפים/השתתפויות עצמיות/סייגים.
• בתביעות: לתכנן כוח אדם לפי שעות שיא וימים “כבדים”.
• בהונאות: לזהות התנהגויות חריגות שחוזרות בזמן (למשל גל תביעות בסופי חודש).

במאמר המקורי, יצרו עמודת Revenue והשתמשו ב‑groupby() כדי להבין מה נמכר ובאיזה תזמון. בביטוח, המקבילה הכי שימושית היא ליצור עמודות כמו:

• EarnedPremium / WrittenPremium (פרמיה נרשמת/מורווחת)
• IncurredLoss (הפסד מצטבר: תשלום + עתודות)
• LossRatio (יחס הפסד)
• ClaimCount, AvgSeverity (תדירות וחומרה)

המסר: לפני AI, חייבים מדדים נקיים.

“מוצר מוביל” בביטוח: לא לפי כמות פוליסות—לפי ערך ורווחיות

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

כמות לא שווה רווח

אפשר למכור המון פוליסות פשוטות (למשל נסיעות קצרות או הרחבות קטנות), ועדיין:

• ההכנסה פר פוליסה נמוכה
• יחס ההפסד גבוה
• עלויות שירות (מוקד/סוכנים/תביעות קטנות) “אוכלות” את המרווח

לכן אני ממליץ לבנות שני דירוגים מקבילים:

1. Top 10 לפי נפח: מספר פוליסות/כיסויים שנמכרו או מספר תביעות (תלוי בשאלה)
2. Top 10 לפי ערך: פרמיה מורווחת, או רווח חיתומי משוער (פרמיה פחות הפסד צפוי ועלויות)

ב‑Pandas זה נראה כמו אותו רעיון:

• df.groupby('ProductLine')['PolicyId'].nunique() לנפח
• df.groupby('ProductLine')['EarnedPremium'].sum() לערך
• ואם אתם בשלים יותר: df.groupby('ProductLine')['LossRatio'].mean() כדי לראות איכות

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

במאמר הופיעו שורות כמו “POSTAGE”, “AMAZON FEE”, “Manual”—לא מוצרים אמיתיים, אבל תורמים הכנסה. בביטוח זה קורה כל הזמן:

• דמי הפקה/עמלות טיפול
• הצמדה/ריבית/החזרים
• גבייה רטרואקטיבית
• “קנסות” או התאמות ידניות

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

• להפריד בין פרמיה ביטוחית לבין הכנסות נלוות
• למדוד רווחיות חיתומית בלי הכנסות נלוות, ואז לראות את השפעתן בנפרד

זה ניתוח קטן שמונע החלטות תמחור שגויות.

הנדסת מאפייני זמן (datetime): הדרך המהירה לראות עונתיות בתביעות

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

• AccidentDate מול ReportDate (מתי קרה מול מתי דווח)
• DevelopmentLagDays (פער דיווח) — מדד חזק גם להונאות וגם לעתודות
• PolicyStartMonth (חודש תחילת פוליסה) — שימושי לקמפיינים וסוכנים

דוגמה קלאסית:

• תביעות רכב יכולות לעלות בחורף (גשם, ראות)
• תביעות דירה יכולות לקפוץ בסערות/הצפות
• תביעות נסיעות כמעט נעלמות בתקופות מתוחות ביטחונית, ואז חוזרות בבת אחת

תאריך היום הוא 21/12/2025—עיתוי מושלם לבדוק את סוף השנה: לא רק מכירות פוליסות, אלא גם גלי תביעות אחרי חגים/חופשות, ועומסים במוקדים.

תובנות תזמון שמייצרות כסף: חודש, יום ושעה (ומה עושים עם זה בביטוח)

במאמר המקורי התקבלה תמונה חדה:

• שיא הכנסות בנובמבר
• קפיצה מפתיעה בינואר
• יום חזק במיוחד (שלישי)
• שעת שיא סביב 10:00 עם פעילות גבוהה עד 15:00

בביטוח, אותה מתודולוגיה מייצרת שלושה סוגי החלטות מעשיות.

1) עונתיות חודשית: תחזית תביעות ותכנון עתודות

הדפוס “Q4 חזק + ינואר חזק” מוכר גם בביטוח, אבל מתבטא אחרת:

• סוף שנה: חידושים, סגירות תקציב, ומבצעים שמייצרים נפח
• ינואר: “סידור עניינים” אחרי החגים, שינויי כתובת/רכב, וחזרה לשגרה

מה עושים עם זה?

• מעדכנים Forecast של תביעות לפי חודש (Claim Frequency) ולא רק לפי שנה
• מכוונים מסרים שיווקיים/ערוצי מכירה בחודשים שמייצרים פוליסות איכותיות
• מתכננים עומסים בתביעות סביב תקופות שבהן הדיווח עולה

2) יום בשבוע: תכנון מוקדים, סוכנים ומניעת נטישה

אם אתם רואים שיום מסוים “שולט” בהכנסות/פניות—זו מתנה תפעולית.

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

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

• תזמון מכירות/חידושים
• תזמון דיווח תביעות וטיפול

3) שעה ביום: תזמון דיגיטל, מניעת הונאות, ו‑Straight Through Processing

השיא ב‑10:00 במאמר לא מפתיע: לקוחות רבים פועלים בשעות עבודה. בביטוח זה משפיע ישירות על:

• מתי לשלוח SMS/מייל חידוש (כשפותחים)
• מתי להפעיל צ’אט/בוט שירות (כשיש נפח)
• מתי לתגבר בקרות הונאה (כשנפח התביעות “דוחף” את המערכת)

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

איך מחברים את זה ל‑AI בביטוח (באמת, לא כסיסמה)

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

1) פיצ’רים של זמן כקלט לתמחור ולחיתום

במקום להכניס רק גיל/סוג רכב/אזור, מוסיפים:

• חודש תחילת פוליסה
• עונתיות תביעות באזור גיאוגרפי
• פער דיווח ממוצע ללקוח/סוכן

התוצאה: מודל תמחור שמבין “מתי” ולא רק “מי”.

2) ניהול סיכונים תפעולי: תחזית עומסים במוקדי תביעות

אם יודעים שבין 10:00–15:00 יש שיא פניות, אפשר:

• לחזות SLA יומי/שעתי
• להקצות בודקים לפי עומס צפוי
• למדוד אם אוטומציה (OCR, סיווג מסמכים) באמת הורידה צוואר בקבוק

3) זיהוי הונאות: חריגות בזמן במקום “חריגות כלליות”

הונאות רבות הן תלויות זמן:

• קפיצה בסוף חודש
• ריכוז תביעות אחרי אירוע מסוים
• דפוסי דיווח בשעות חריגות

ברגע שיש בסיס time-series נקי, אפשר לבנות כללי חריגה חכמים יותר, או מודלים שמודעים לעונתיות ולא “נבהלים” ממנה.

שאלות נפוצות שמנהלים שואלים (והתשובות שעובדות בשטח)

“מה המדד הנכון ל’מוצר מוביל’ בביטוח?”

מוצר מוביל הוא שילוב של נפח + ערך + איכות. בפועל: נפח פוליסות, פרמיה מורווחת, ויחס הפסד (או רווחיות חיתומית).

“איך מתחילים בלי פרויקט דאטה ענק?”

בוחרים תחום אחד (למשל רכב חובה), חודשיים‑שלושה נתונים, ומייצרים 4 עמודות זמן (שנה/חודש/יום/שעה) + מדד ערך אחד (פרמיה או הפסד). זה מספיק כדי לראות תבניות.

“מה הטעות הכי יקרה בניתוח כזה?”

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

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

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

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

1. להגדיר מדד “ערך” אחד מוסכם (פרמיה מורווחת, או רווח חיתומי משוער).
2. להוציא דוח עונתיות חודשי להכנסות ולתביעות באותו גרף.
3. לזהות יום ושעת שיא ולהשוות מול עומסים במוקד ותהליכי אישור תביעה.
4. להכין רשימת “מוצרים מובילים לפי ערך” מול “מובילים לפי נפח” ולהציג פערים.

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