משפך מכירות Bitrix24: היכן אובדות עסקאות
עסקאות ב-Bitrix24 כמעט לעולם לא אובדות במקום אחד — הן נתקעות בגבולות השלבים ומשוכפלות בפניות חוזרות. משפך מכירות Bitrix24, שנבנה "לפי ההיגיון של המחלקה", בדרך כלל משחזר שלבים מוכרים, אך אינו מתאר במה בדיוק שלב אחד שונה מאחר.
בסופו של דבר עסקאות תקועות נראות כפעילות, ואובדן עסקאות מתגלה בהתאמה מול תשלומים, כשכבר קשה להחזיר את הלקוח.
הסיבה הטיפוסית הראשונה — גבולות מטושטשים בין שלבי העסקה. אם המעבר אינו מקושר לאירוע בר-בדיקה (הצעה נשלחה, התקבל קשר של מאשר, מסמך נחתם), המנהל מזיז את הכרטיס לפי תחושה. דוח לפי שלבים מפסיק לשקף את המציאות: התחזית מנופחת, ובעסקאות תקועות מצטברות אלו שלא זזות חודשים.
השנייה — שדות חובה בשלב הלא נכון. הדרישה למלא הכול ביצירת הכרטיס מכריחה או לפתוח עסקה מאוחר יותר, או לשים מצייני מקום שאיש אינו מנקה אחר כך. התאמת משפך מכירות עובדת כאשר הנתונים נדרשים במקום שבו הם מופיעים: מקור וקשר — במגע הראשון, תנאים ומועדים — בשלב ההסכמה.
השלישית — היעדר כללי החזרה. בלעדיהם עסקה לאחר סירוב לקוח נשארת בשלב מתקדם, ופנייה חוזרת נפתחת ככרטיס שני, וחלק מהמשימות הולך לאיבוד בין הכפולים. נבחן כיצד זה נסגר באמצעות התאמת המשפך: קריטריוני מעבר ברי-בדיקה, שדות בשלבים המתאימים ותרחישי החזרת העסקה אחורה.
מה נותנת הרכבה מחדש: אפקט במדדים מדידים
הרכבה מחדש של המשפך ב-Bitrix24 משנה לא את "נוחות הממשק", אלא את הזמן שלוקח לעסקה לעבור מהפנייה הראשונה עד החשבונית. קודם המנהל העביר את הכרטיס ידנית, שכפל נתונים לטבלאות ותיאם הנחה בהתכתבות — בכל שלב אבדו שעות. לאחר שהמעברים בין השלבים, שדות החובה והאחראים חוברו לכללים, הכרטיס זז מעצמו, והמנהל מתעסק עם הלקוח.
מה נותנת אוטומציה של מכירות במונחים מדידים:
- מהירות עיבוד פנייה — פנייה מהאתר, מהדואר ומהטלפון נכנסת לכרטיס אחד ללא הזנה ידנית, והתשובה הראשונה מפסיקה להיות תלויה במי שנמצא בתורנות.
- המרה לפי שלבים — רואים באיזה שלב נושרות הכי הרבה עסקאות; לרוב צוואר הבקבוק הוא אישור או הוצאת חשבונית, ולא המשא ומתן.
- שיעור עסקאות תקועות — הכלל "אין פעילות מעבר לתקופה מוגדרת → משימה ותזכורת" מחזיר לעבודה את מה שקודם שכב בשקט במאגר.
- זמן התאוששות לאחר תקלת תהליך — אם החיבור למערכת חיצונית נפל, פניות אינן הולכות לאיבוד: התור ממשיך להיעבד, והאחראי מקבל התראה.
שקיפות מחלקת המכירות — תוצאה של אותו דבר: המנהל רואה את המשפך בזמן אמת, ולא מרכיב דוח בסוף החודש מטבלה של מישהו אחר. נעלם סוג שלם של כשלים — עסקאות נשכחות, פניות בלי אחראי, שלבים שאיש אינו שולט בהם.
תרשימי משפך: אפשרות, מגבלות, מתי מתאים
תרשים המשפך קובע לא רק את מראה כרטיס העסקה, אלא גם את כללי המעברים, שדות החובה בשלב, הרשאות התפקידים והרובוטים שמזיזים את העסקה בלי השתתפות המנהל. לכן בוחרים את התרשים לפני מילוי המאגר: החלפת אפשרות על נתונים חיים מאפסת את השוואתיות השלבים ושוברת את הדיווח לתקופות קודמות.
שונות העסקאות — הקריטריון העיקרי לבחירה. אם המוצר אחד ומחזור העסקה זהה אצל כל הלקוחות, משפכים מיותרים רק מפצלים את האנליטיקה; אם יש כמה כיוונים, משפך משותף ממצע את המועדים ואת ההמרה עד לערכים חסרי משמעות.
| תרשים משפך | מתי מתאים | מגבלות |
|---|---|---|
| משפך כללי אחד | מוצר אחד, מחזור עסקה זהה, מחלקת מכירות אחת | סגמנטים שונים מתערבבים: מועד ממוצע והמרה מחושבים "בממוצע", כללי המעברים נאלצים להיות רכים |
| משפכים לפי כיוונים, כולל לכמה מוצרים | מוצרים שונים, מחזורים ותרחישי סינון | נדרשת סנכרון של ספרי עזר ושדות; השוואה בין כיוונים — רק בדוחות מסוכמים, ולא בתרשים אחד |
| משפך עם שלבי סינון והחזרה | מחזור ארוך, עסקאות נתקעות, חלק מהלקוחות חוזרים לאחר סירוב | יותר שלבים — מחיר הטעות גבוה יותר: בלי משמעת מילוי והגדרות רובוטים המשפך מתמלא בעסקאות "מתות" |
כללי המעברים מקובעים במפורש: אילו שדות חובה בשלב, היכן אסור לדלג על שלבים, איזו משימה מגדיר הרובוט וכעבור כמה ימים העסקה עוברת להחזרה או לסירוב. שלד כזה הופך את המשפך גם לכלי עבודה של המנהל וגם למקור נתונים מהימן לתחזית.
שלבי הטמעה: מביקורת ועד מסירה לעבודה
סדר השלבים כאן אינו פורמליות: כל צעד עוקב נשען על תוצאת הקודם, וחוליה שהוחמצה מחזירה את הפרויקט לתיקון ידני בדיעבד. להלן הרצף שלפיו אנו מובילים הטמעת משפך מכירות ב-Bitrix24.
- ביקורת משפך מכירות. מייצאים שלבים, שדות והיסטוריית עסקאות, סופרים כמה עסקאות נתקעות בכל שלב ומי אחרון שינה את הכרטיס. בפלט — מפת בעיות: כפילויות שדות, שלבים בלי כללי מעבר, דוחות שאיש אינו קורא.
- תכנון שלבים. בונים תרשים למחזור העסקה האמיתי: כמה שלבים נדרשים, אילו שדות חובה בכל אחד, היכן הפעולה מתבצעת אוטומטית והיכן ההחלטה נשארת לאדם.
- הגדרת הרשאות גישה. תפקידים לפי משימות: מנהל מנהל את העסקאות שלו, ראש המחלקה רואה את המחלקה, שדות שירות סגורים לעריכה. מחיקת כרטיסים והחלפת שלב בדיעבד מוגבלות בנפרד.
- הרכבת אוטומציה. רובוטים, טריגרים ומשימות בתוך שלבים: תזכורת בזמן חוסר פעילות, משימה לאחר אישור, התראה לאחראי בעת החלפת שלב.
- בדיקה בסביבת בדיקות. מריצים תרחישים על עותק של הפורטל: העסקה עוברת את כל השלבים, הדוחות מתכנסים, ההרשאות אינן מפריעות לעבודה. את התרשים מתקנים לפני ההעברה, ולא אחריה.
- הדרכה ותקנון. מציגים לצוות את ההיגיון החדש על העסקאות שלהם עצמם ומוסרים הוראות קצרות: איזה שדה מתי ממלאים ומה עושים עם עסקה לא סטנדרטית.
- מסירה לתפעול. מעבירים את ההגדרות לפורטל העבודה, בשבועות הראשונים מתאימים דוחות ומסירים מקומות שנויים במחלוקת לפי עסקאות בפועל.
כל שלב נסגר בארטיפקט — תרשים, מטריצת הרשאות או תקנון, ולכן אפשר לקבל את התוצאה בחלקים.
מה הלקוח מקבל לידיו לאחר ההטמעה
לאחר ההטמעה ההיגיון של המשפך מפסיק להישען על הזיכרון של האינטגרטור — הוא מקובע במסמכים שלפיהם מחלקת המכירות עובדת באופן עצמאי. להלן רשימת מה שמועבר ללקוח בסיום הפרויקט.
- תרשים משפך מכירות — שלבים ותנאי מעבר ביניהם, שדות חובה בכל צעד, חיבור האוטומציה: משימות אוטומטיות, התראות, החלפת אחראי בזמן חוסר פעילות בעסקה.
- מטריצת הרשאות גישה — אילו תפקידים רואים, משנים ומוחקים עסקאות, מי מייצא את המאגר ומתקן הגדרות; ההפרדה נעשית לפי מחלקות, ולא "לכולם בבת אחת".
- תקנון עבודה עם עסקאות — מה המנהל עושה בכל שלב, באיזה מועד, אילו נתונים חייב למלא לפני מעבר לשלב הבא.
- הוראות למנהלים — תרחישים שלב-אחר-שלב לפי תפקידים: לפתוח עסקה, להעביר בין שלבים, להחזיר מסירוב, לצרף מסמך, להעביר עסקה לעמית.
- מדיניות גישה ויומן בדיקות — מי ומתי שינה הגדרות משפך, היסטוריית עריכות של שדות וסטטוסים, סדר התאמות מתוכננות.
- תיעוד המערכת — מפת קשרים עם 1C, טלפוניה ודואר, תיאור הרובוטים, כללי טיפול בשגיאות בזמן החלפת נתונים.
המסמכים נכתבים עבור התהליך שלכם, ולא לפי תבנית, ונבדקים על עסקאות אמיתיות לפני המסירה. כאשר שלבים או אחראים משתנים, אנו מעדכנים את התרשים והתקנון — העובדים נשארים בגרסה עדכנית, ולא בהסכמות בעל פה.
מקרה בוחן: הרכבנו מחדש את השלבים והסרנו עסקאות תקועות
מחלקת מכירות עם צוות מפוזר: שישה מנהלים בשלוש ערים, זרם פניות משותף מהאתר, מהדואר ומהמסנג'רים. ב-Bitrix24 משפך המכירות עד לשלב הניתוח כלל 12 שלבים — על שלושה מהם המנהלים דילגו, וחמישה לא הכילו שדות חובה.
העסקה עברה ל"הצלחה" בלי תאריך תשלום והחלטה על משלוח, ובדוח של המנהל מכירות כאלה נספרו כפעילות במשך חודשים.
מה שינינו בשלבים ובהרשאות
השלבים צומצמו לשבעה, לכל אחד נוסף סימן מעבר ושדות חובה: תאריך המגע הבא, אחראי, מקור, סכום. ההרשאות נבנו מחדש כך שמעבר לשלב הבא בלי מילוי שדות בלתי אפשרי, והחזרה לשלב קודם נעשית רק בידי ראש המחלקה ועם הערה.
הוספנו שלב אישור חוזה עם צ'ק-ליסט ורובוט: חמישה ימים בלי פעילות — משימה למנהל, עשרה — הסלמה לראש המחלקה.
מדדים לפני ואחרי
שיעור העסקאות ללא תנועה ירד מ-34% ל-11% — כעת אצל כל אחת רואים את נקודת העצירה ואת האחראי לצעד הבא. מועד העסקה הממוצע התקצר מ-47 ל-29 ימים, וההמרה מפנייה לחשבונית עלתה בכמעט חמישית.
מספר העסקאות שבדוח אין עליהן נתונים צומצם לאפס. השלב הפסיק להיות תווית והפך לנקודת בקרה: עסקאות תקועות רואים ביום השני, ולא בסוף החודש, כשהמנהל כבר אינו זוכר את הקשר של השיחה.
מה לעשות אם העסקאות כבר מתנהלות לפי כללים משלהן
כן, את המעבר עושים על מערכת פעילה, בלי לעצור את המחלקה. הסדר הוא כזה: תחילה ב-Bitrix24 בונים משפכים נוספים לצד המשפך הקיים — מגדירים שלבים, הרשאות, שדות חובה — ורק לאחר הרצה בסביבת בדיקות מעבירים את העסקאות. עד יום המעבר המנהלים עובדים במתכונת הקודמת.
התאמת מערכת קיימת מתחילה בספירת מלאי, ולא בניקוי: אילו שלבים באמת בשימוש, היכן עסקאות נתקעות, אילו שדות ממולאים ואילו כבר איש אינו מתחזק. סטטוסים ישנים איננו מוחקים — סוגרים אותם לבחירה ידנית, אך משאירים זמינים, כדי שכרטיסים לא יאבדו את הקשר להיסטוריה.
העברת העסקאות נעשית במנות לפי אחראי או לפי תאריכים, עם התאמת סטטוסים ושמירה של תאריך היצירה, הסכום, הקישור לאיש הקשר ולחברה. כל כרטיס מקבל מזהה חיצוני: הרצה חוזרת של הייצוא אינה יוצרת כפילויות, ורשומות שנויות במחלוקת נכנסות לדוח ומטופלות בנפרד — בלי ניתוח ידני של כל המערך.
הדיווח נשבר לא מההעברה, אלא משלבי ביניים לא מלאים. לכן בתקופת המעבר אנו מחזיקים ספרי עזר וסיבות סירוב מתואמים בשתי התרשימים: רואים היכן העסקה הייתה קודם והיכן היא כעת, ומשפך המכירות נשאר תפור, ולא מתפרק לשני מערכי נתונים לא קשורים.
כשההתאמה מתכנסת, המחלקה עוברת למתארים החדשים, והקודמים נשארים כארכיון לביקורת.
שאלות טכניות בנושא שלבים, הרשאות ודוחות
שלבים, הרשאות ודוחות במערכת קשורים זה לזה: עריכת ישות אחת משנה את ההתנהגות של האחרות. ריכזנו חמש התלבטויות שעולות לרוב בשלב התכנון, עם תשובות קצרות לעניין.
האם אפשר להציג לעובד רק חלק מהשלבים?
כן. הגישה מוגדרת באמצעות תפקידים ופרופילים: המחלקה שלו רואה את המשפך כולו, מחלקות סמוכות — רק מקטעים ושדות נדרשים של הכרטיס. המגבלות מוגדרות ברמת ההרשאות, ולא בסינון ידני בדוחות, ולכן אי אפשר לעקוף אותן מהממשק.
מה ישתנה בדוחות אם נשנה שם שלבים או נסדר אותם מחדש?
היסטוריית העסקאות נשמרת, אך דוחות עם סינון לפי שלב מסוים יהיה צורך להרכיב מחדש: חלק מהמדדים קשורים למזהה השלב, ולא לשמו בממשק. לכן אנו מבצעים שינויים לפי תקנון ומיד בודקים את הדיווח שנמסר.
איך פנייה מהאתר מגיעה מיד לשלב הנכון?
הטופס מעביר מערכת שדות שלפיהם פועל תנאי ההפצה: מקור, כיוון, סוג בקשה. הפנייה נוצרת בשלב ההתחלתי, לאחר מכן עוברת אוטומטית, והאחראי ממונה לפי כלל. אם יש כמה טפסים, כל אחד מקושר לתרחיש משלו, כדי שהזרמים לא יתערבבו.
האם צריך לעשות משפך נפרד לכל כיוון?
הדבר תלוי בשאלה אם השלבים והאחראים שונים. אם כן, משפך נפרד נותן המרה נקייה לפי כיוון. אם התהליכים זהים, עדיף משפך אחד עם הפרדה לפי שדות — אחרת יהיה צורך לאחד דוחות ידנית.
החזרת עסקה לשלב קודם שוברת את הסטטיסטיקה?
לא, זהו תרחיש שגרתי: העסקה חוזרת אחורה, בכרטיס נשמרת הסיבה, וההמרה סופרת מעברים חוזרים בנפרד מהראשוניים. בלי סיבת חובה להחזרה, עסקאות כאלה מטשטשות את התמונה, ולכן כדאי לקבוע את השדה בטופס.
נדון במשימה: היקף העבודה וסדר ההתחלה
הניתוח מתחיל בשיחה עניינית, ולא במצגת סקירה: כדי לחזור עם הערכה ותוכנית עבודה, אנו צריכים לראות את משפך המכירות הנוכחי שלכם ב-Bitrix24 — שלבים, רובוטים, הרשאות, אינטגרציות. ככל שיהיה יותר הקשר בהתחלה, כך ההערכה תהיה מדויקת יותר ופחות הבהרות יהיו בשלב ההטמעה.
- גישה לפורטל בקריאה בלבד או לסביבת בדיקות שבה אפשר לשחזר את הגדרות המשפך הנוכחיות.
- רשימת משפכים וכיוונים עם ציון אילו מהם פעילים ואילו נותרו מתרשימים קודמים.
- תיאור תהליך המכירה מהליד ועד העסקה: מי ובאיזה שלב משנה את הסטטוס, מה נחשב לתוצאת השלב.
- רשימת האוטומציה: רובוטים, טריגרים, תהליכים עסקיים, תבניות מכתבים ומשימות שכבר פועלים.
- אינטגרציות שמשפיעות על השלבים: טלפוניה, דואר, טפסים באתר, החלפת נתונים עם 1C ושירותים חיצוניים.
- תפקידים והרשאות לפי מחלקות — מהם תלוי אילו מעברים בין שלבים זמינים לאיזו קבוצה.
אנו מנתחים את היסטוריית העסקאות, בודקים היכן הן נתקעות ובאיזה מעבר אובד הכי הרבה, ומשווים זאת להיגיון השלבים. בפלט תקבלו תרשים משפך, מפת אוטומציה ותוכנית עבודה לפי שלבים עם סדר התחלה ברור: תחילה תכנון השלבים בסביבת בדיקות, לאחר מכן העברה לפורטל העבודה בלי לעצור את המכירות. תארו את המשימה — נחזור עם הערכה ותוכנית עבודה.