פיתוח מערכת AI להפעלה מחדש של לקוחות לא פעילים

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

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

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

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

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

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

מה נותנת הפעלה מחדש מנוהלת: אפקט במדדים מדידים

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

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

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

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

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

פורמטים לעבודה עם הבסיס: תרחישים, מגבלות ויישומיות

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

היכן האוטומציה נתקעת

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

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

שלבי הטמעה: מביקורת נתונים ועד מסירת נהלים

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

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

מה הלקוח מקבל לידיו: תצורות, סכמות, נהלים

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

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

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

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

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

מה שינינו

אספנו מאפייני שתיקה: ותק הביקור האחרון, תדירות הפניות הקודמת, הערוץ הרגיל (טלפון, אתר, מסנג'ר), תגובה להודעות בעבר.

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

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

מדידות לפני ואחרי

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

בקבוצת הביקורת באותה תקופה חזרו פחות מ-2% — כלומר, עיקר הגידול נבע מההתערבות, לא מעונתיות. בתוך הסגמנט הקבוצה שבלטה ביותר הייתה «קורס שהופסק»: החזרה של לקוח там הייתה גבוהה פי שלושה מזו של «אלה שעברו לאחר».

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

מה לעשות אם הבסיס כבר מחומם מקמפיינים קודמים?

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

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

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

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

תארו אילו מבצעים כבר עברו על הבסיס ומה ידוע על התגובה — נחזור עם הערכה ותוכנית.

ספקות טכניים: כיצד אנחנו פותרים סיכונים אופייניים בפרויקט

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

איך נלקחות בחשבון הסכמות לתקשורת

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

איך בודקים הטיה של המודל והתוצאה

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

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

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

נדבר על המשימה: מה דרוש מכם להתחלה

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

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

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