מערכת בינה מלאכותית לחיזוי התרחבות חשבון

למה Expansion Prediction לא עובד בחשבונות אמיתיים

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

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

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

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

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

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

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

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

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

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

איך מודל Expansion Prediction משנה את העבודה עם בסיס הלקוחות

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

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

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

את הסף אנו בוחרים כך שחלקו העליון של הרשימה יכלול את רוב החשבונות שאכן התרחבו — התראות שווא נחתכות בתנאים נוספים, למשל נוכחות מנהל פעיל ובקשות פתוחות לרישיונות נוספים.

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

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

השוואת גישות: כללים, סטטיסטיקה, למידת מכונה

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

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

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

שלבי הטמעת חיזוי הרחבת חשבונות

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

1. סקירת מקורות. מפרקים היכן נשמרת היסטוריית החשבונות: תשלומים, פעילות מוצר, פניות לתמיכה. מתעדים עומק היסטוריה, כפילויות, חסרים ודרך לקשר רשומות של אותו לקוח בין מערכות.
2. הכנת נתונים. אוספים חלון נתונים ברמת החשבון בצעד חודשי ומפרידים בין חלון תצפית לחלון תחזית: מאפיינים מחשבים רק על העבר, והיעד — על העתיד.
3. תיוג עסקאות היסטוריות. מאפיין היעד — עובדת הרחבה בטווח של כמה חודשים; נטישה והקפאות מסמנים בנפרד, כדי שהמודל לא יבלבל בינן לבין סירוב להארכה.
4. סכמת מאפיינים. צריכה והדינמיקה שלה, מספר מקומות פעילים, הרכב משתמשים, פניות לתמיכה, זמן מאז ההתחלה, התנהגות חשבונות דומים.
5. אימות וכיול. בודקים על תקופה מושהית בזמן, ולא על מדגם אקראי, ומשווים לקו בסיס פשוט. לאחר מכן בוחרים סף שבו העומס על המנהלים נשאר סביר.
6. הטמעה בתהליכי הצוות. האות מגיע לכלי העבודה הרגיל עם הסבר של הגורמים, ואליו מצורפים נוהל אימון מחדש ובקרת הטיית נתונים.

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

תיעוד, סכמות נתונים ונוהלי עבודה של המודל

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

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

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

מקרה בוחן: לפני ואחרי הטמעת חיזוי ההרחבה

לפני: האותות נאספו ידנית

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

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

אחרי: הרצת פיילוט ומדדים

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

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

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

מדדים לפני ואחרי:

• דיוק התחזיות — מ-46% ל-78%;
• שלמות בחשבונות באזור צמיחה — מ-31% ל-64%;
• שיעור התראות שווא — קטן פי שלושה;
• זמן משינוי במוצר עד אות למנהל — משבועיים-שלושה ליום אחד.

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

במה חיזוי הרחבה שונה מתחזית נטישה

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

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

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

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

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

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

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

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

איך מתבצעת האינטגרציה עם מערכות הרישום?

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

מה עושים עם התראות שווא?

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

מי מלווה את המודל לאחר ההפעלה?

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

נדון במשימה ונחזור עם תוכנית עבודה

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

מכם בשלב ההתחלה:

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

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