pipeline של deals נראה כמו מסך הגדרות. הוא בעצם הצורה של איך החברה שלכם מוכרת. המטרה היא לא להעתיק רשימת stages גנרית - אלא לבנות pipelines ו-stages שמשקפים את תהליך המכירה האמיתי שלכם, כך שהמיקום של כל deal אומר לכולם את אותו הדבר ואפשר לסמוך על התחזית. רוב התחזיות המבולגנות ב-HubSpot מגיעות מ-stages שמתארים פעולות שהנציגים עושים במקום מחויבויות של הקונה, או מדחיסה של שני תהליכי מכירה שונים ל-pipeline אחד. ריכזנו לכם כאן את נקודת המבט המעשית על תכנון pipelines ו-stages שמחזיקים מים.
pipeline הוא מסלול אחד ש-deal עובר בו מפתוח לסגור, בנוי מ-stages מסודרים - ואתם צריכים pipeline נפרד בכל פעם שלתהליך מכירה יש שלבים שונים באמת. מכירה חדשה, חידוש, ו-deal שהגיע משותף עסקי לרוב עוברים דרך stages, בעלים ולוחות זמנים שונים. כפייה שלהם ל-pipeline אחד אומרת שחצי מה-stages לא רלוונטיים לחצי מה-deals, והדוחות שלכם מיטשטשים. דוגמה מהשטח: צוות הריץ מכירות חדשות וחידושים ב-pipeline אחד. החידושים דילגו על "Discovery" ו-"Demo", אז ה-deals האלה ישבו ב-stages מוקדמים ונראו תקועים וגררו את התחזית למטה. אחרי הפיצול לשני pipelines, כל stage סוף סוף תיאר שלב אמיתי - והתחזית לכל תהליך הפכה לקריאה. השתמשו ב-pipeline אחד לכל תהליך נבדל; אל תכפילו אותם מעבר למה שתנהלו בפועל.
מספיק כדי לסמן שינויים אמיתיים וניתנים לצפייה במחויבות של הקונה - בדרך כלל חמישה עד שבעה - ולא יותר. כל stage צריך לענות על "מה השתנה בצד של הקונה כדי להעביר אותו לכאן?". מעט מדי stages ולא תוכלו לראות איפה deals נתקעים. יותר מדי, והנציגים מנחשים, deals מוחנים במקום הלא נכון, והדאטה שלכם הופכת לרעש. שדרה נקייה ל-pipeline של מכירות חדשות היא לרוב: Qualified, Discovery, Proposal, Negotiation, Closed Won, Closed Lost. השמות המדויקים פחות חשובים מהעיקרון: כל stage הוא אבן דרך שמנהל יכול לאמת, ולא רק task שנציג ביצע.
ה-stages צריכים לתאר מחויבות של הקונה, ולא פעילות של הנציג - כי stages שמבוססים על פעילות מנפחים את ה-pipeline ומסתירים את האמת. "Demo scheduled" אומר לכם שנציג קבע פגישה; הוא לא אומר כלום על האם הקונה אמיתי. "Proposal sent" נשמע כמו התקדמות, אבל הצעה שאף אחד לא ביקש היא לא deal שמתקדם. תעגנו כל stage לאות מהקונה במקום: הוא אישר בעיה ותקציב, הוא הסכים להעריך, הוא מנהל משא ומתן על תנאים. דוגמה מהשטח: ה-stages של צוות היו כולם פעולות של נציג - "Call made", "Email sent", "Demo done". כל deal נראה עסוק ושום דבר לא הצליח להיכנס לתחזית. אחרי שכתבו אותם מחדש סביב מחויבות הקונה, אותו pipeline הראה פתאום אילו deals אמיתיים ואילו רק פעילות. כשה-stages משקפים את הקונה, התחזית משקפת את המציאות.
תגדירו את ה-deal stage probabilities במחשבה, תדרשו את הפרופרטיז הנכונים בכל stage, ותגדירו מה זה "תקוע" - ואז תאכפו את זה. תנו לכל stage הסתברות זכייה שתואמת למציאות, כך שהתחזית המשוקללת שלכם לא תהיה בדיה. השתמשו בפרופרטיז נדרשים מבוססי-stage (close date עד Proposal, amount עד Negotiation) כך ש-deals לא יוכלו להתקדם חצי-ריקים. תחליטו כמה ימים של שקט הופכים deal ל"מיושן", ותסקרו את ה-deals האלה לפי לוח זמנים, במקום לתת להם להירקב ב-Negotiation לנצח. זה הסדר שאנחנו עוקבים אחריו עם לקוחות: לתכנן את ה-stages סביב הקונה, לחווט את הכללים ששומרים אותם כנים, ואז לבנות את הרגל הסקירה שתופס סטיות. pipeline אמין בדיוק כמו המשמעת שסביבו.
ה-pipelines הם המקום שבו תהליך המכירה והדוחות נפגשים, ורוב הצוותים טועים בהם באותה צורה: הם בונים stages סביב מה שהנציגים עושים במקום מה שהקונים מתחייבים אליו. הבחירה האחת הזו היא הסיבה שאי אפשר לסמוך על כל כך הרבה תחזיות. תקבעו את ה-stages נכון - אבני דרך נצפות של הקונה, pipeline אחד לכל תהליך אמיתי, חמישה עד שבעה stages עם הסתברויות כנות - וכמעט כל דוח בהמשך הדרך משתפר בבת אחת. תקבעו אותם לא נכון, ושום דשבורד, אינטגרציה או אייג'נט AI לא יציל אתכם, כי כולם יקראו ממפה שלא תואמת לשטח. תכננו את ה-pipeline בקפידה כמו שהייתם מתכננים את תהליך המכירה עצמו, כי הוא תהליך המכירה.
תחזית pipeline שאתם לא לגמרי סומכים עליה? תקבעו אודיט פורטל של 30 דקות - נראה לכם איפה ה-stages מנפחים את ה-pipeline ומה לתקן קודם. לתמונה הרחבה יותר, ראו איך אנחנו ניגשים להטמעה ואופטימיזציה של HubSpot.
אפשר ליצור כמה deal pipelines ב-HubSpot?
כן, ברמות בתשלום של Sales Hub, עם מגבלות שמשתנות לפי התוכנית. תיצרו pipeline נפרד בכל פעם שלתהליך מכירה יש stages, בעלים או לוחות זמנים שונים באמת - כמו מכירה חדשה מול חידושים - כך שכל stage מתאר שלב אמיתי עבור ה-deals שבו.
כמה deal stages כדאי שיהיו לי?
בדרך כלל חמישה עד שבעה. אתם רוצים מספיק stages כדי לסמן שינויים אמיתיים במחויבות של הקונה ולזהות איפה deals נתקעים, אבל מעט מספיק כדי שהנציגים תמיד יידעו לאן deal שייך. יותר stages מזה נוטה ליצור ניחושים ודאטה רועשת.
אילו deal stage probabilities כדאי שאגדיר?
כאלה שתואמות לשיעורי הזכייה האמיתיים שלכם בכל stage, ולא מספרים עגולים שנבחרו מתוך נוחות. HubSpot משתמשת בהסתברויות האלה לתחזיות משוקללות, אז נתונים כנים נותנים לכם תחזית כנה. תסקרו אותן מדי פעם מול תוצאות אמיתיות ותתאימו.
איך מונעים מ-deals להיתקע ב-stage אחד?
תגדירו כמה ימים של חוסר פעילות נחשבים "מיושן", תבנו תצוגה שמורה או דוח שמציף את ה-deals האלה, ותסקרו אותם בקצב קבוע. תשלבו את זה עם פרופרטיז נדרשים מבוססי-stage כך ש-deals לא יוכלו להתקדם בלי הדאטה שמנהל צריך.