לקוחות סיטונאיים שמצמצמים רכש בשקט

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

למה דוח המכירות מגלה את זה אחרון#

שלוש סיבות מבניות, ואף אחת מהן אינה תקלה בדיווח.

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

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

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

הסימנים שזזים לפני שהמכירות יורדות#

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

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

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

איך הופכים סימנים לרשימה שבועית#

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

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

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

שלחו את הראיות יחד עם ההתראה. ‘לקוח 4471 בסיכון’ הוא מסר חסר תועלת. ‘לקוח 4471 הזמין כל 19 ימים במשך שנתיים, לא הזמין 41 ימים, והפסיק לקנות את משפחת האביזרים במרץ’ נותן לאיש המכירות משפט לפתוח איתו את השיחה. ההתראה חייבת לשאת מה השתנה, ממתי, ומה הוא נהג לקנות.

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

אילו כלים קיימים לזה, ביושר#

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

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

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

מערכות גבייה וסיכון אשראי. קטגוריה בשלה בצד התשלומים. BlueLinx, מפיץ סיטונאי אמריקאי, צמצם חובות בפיגור ב-30% והגיע ל-91% שיוך תקבולים אוטומטי עם מערכת גבייה מבוססת AI, על פי מקרה לקוח של הספק HighRadius, ומחקר עצמאי של Nucleus Research מצא אצל חברה אחרת צמצום של כ-27% בימי הגבייה (DSO), מ-80 ל-58 ימים, על פי המחקר שפרסם. הכלים האלה מטפלים בסחף בתשלומים, לא בסחף ברכש, ולכן כדאי להתייחס אליהם כחצי מהתמונה.

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

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

מה כבר עשינו#

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

• ניתוח נטישת לקוחות כתוצר שסופק. בליווי של שלוש שנים ליצרן תעשייתי בשוק האמריקאי, נטישת לקוחות התגלתה קודם לכן רק בדיעבד. פיתחנו ניתוח נטישה שמזהה דפוסי התרחקות ומצליב אותם עם ידע מהשטח, לצד ניתוח התנהגות לקוחות בתקופות אי-ודאות בביקושים וניתוח אשכולות לקוחות, הכול כתוצרים בפועל שנבחנו מדי חודש מול תוצאות אמת.
• אותה גישה אצל יצרן שני. עבור יצרן גלובלי בתחום טכנולוגיות המים הוספנו ניתוח נטישת לקוחות וניתוח מכירות גיאוגרפי מעל תחזית ביקושים רב-אזורית, בפיתוח ותיקוף.
• ניטור חריגות בהזמנות ובתשלומים, באפיון ותכנון לסיטונאי. עבור סיטונאי תוצרת חקלאית המשרת מעל 1,000 לקוחות אפיינו ותכננו זיהוי אוטומטי של חריגות תשלומים עם התראות שבועיות, לצד ניטור יומי של ‘מי לא הזמין היום’, בשילוב עם ה-ERP ומערכות ההזמנות הקיימות. העבודה הזו היא בדרגת אפיון ותכנון, במסגרת מסמך התקשרות חתום.
• קפדנות ההערכה שמאחורי ההתראות. מסווגי משתמשים מעורבים ולקוחות בעלי ערך גבוה על מאות אלפי אירועים, עם בקרת דליפות בחלוקת הנתונים ודיווח מלא של precision/recall. זו משמעת ההערכה שכל מודל התראות זקוק לה לפני שמישהו סומך על הרשימה השבועית שלו.

הדפוס הרחב כבר נושא שם אצל הספקים הגדולים בשוק: SAP משווקת יכולת AI שמציפה מתי ‘הרכש של הלקוח ירד בחודשים האחרונים’, על פי Forbes. אנחנו בונים את אותו אות עבור תפעול עם אלף לקוחות, לא עבור מערך ERP של חברת ענק. אם אתם רוצים לדעת אם היסטוריית ההזמנות שלכם נושאת את זה, בדיקת מוכנות הנתונים היא המקום להתחיל בו, ואפשר להריץ אותה לבד.