התשובה הקצרה

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

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

איפה זה נשבר בפועל

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

שלבי המכירה: קריטריון יציאה לכל שלב

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

שלבקריטריון יציאה מדידראיה במערכתProbability
Qualificationזוהה צורך, תקציב ובעל החלטהשדות Budget ו-Decision Maker מלאים10%
Discoveryהוצג מיפוי צורך מאושר על ידי הלקוחמסמך או Note מקושר25%
Proposalנשלחה הצעה עם תמחור וסקופQuote פעיל50%
Negotiationהלקוח החזיר הערות מסחריות או משפטיותActivity מתועד בשבועיים האחרונים75%
Closed Wonחתימה או POקובץ מצורף100%

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

Lead מול Opportunity: הגבול שקובע את איכות ה-Pipeline

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

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

מי שבונה את מודל הנתונים שמאחורי זה ימצא רקע בעיצוב מודל נתונים ב-Salesforce.

Activities: לחייב מעט, במקומות שקובעים

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

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

Forecast: מה צריך להיות במקום לפני שמפעילים

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

  1. היררכיית משתמשים תקינה - Forecast ב-Salesforce מתגלגל לפי Role Hierarchy, לא לפי מבנה ארגוני בגיליון.
  2. תאריכי סגירה נקיים - כלל תפעולי שלא מאפשר לעסקה להישאר עם תאריך שעבר יותר משבוע.
  3. קטגוריות Forecast מוגדרות - Pipeline, Best Case, Commit, Closed - עם הגדרה מוסכמת מי מזיז עסקה ל-Commit ומתי.
  4. מחזור סקירה קבוע - ישיבת Pipeline שבועית שמתנהלת מתוך המערכת ולא מגיליון מקביל.

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

מה למדוד אחרי העלייה לאוויר

מדדמה הוא מגלהסף בעייתי
Forecast accuracyפער בין תחזית Commit לתוצאהסטייה מעל 20% ברבעון
Stage agingעסקאות שתקועות בשלבמעל פי 2 מהחציון
עדכון תוך 7 ימיםהאם המערכת משקפת מציאותפחות מ-70% מהעסקאות הפעילות
Data completenessשדות חובה בשלבים מתקדמיםפחות מ-90%

מדדי אימוץ עמוקים יותר מפורטים במדדי אימוץ Salesforce.

מה לא לעשות בגל הראשון

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

סיכום

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