הגדרת משפך מכירות ב-Bitrix24: היכן הולך לאיבוד הרישום
משפך מכירות ב-Bitrix24 יכול להיות מוגדר באופן פורמלי — השלבים הוגדרו, ההרשאות חולקו, הדוח נבנה. אבל די להשוות אותו לחוזים ולמסמכי סגירה, ומתברר שחלק מהעסקאות כלל לא נכנסו לרישום.
בדרך כלל הסיבה אינה בדוח עצמו, אלא בשלושה מקומות: שלבים מטושטשים, כפילויות כרטיסים ועסקאות שחיות מחוץ למערכת.
שלבים מטושטשים של עסקה שוברים את כל החשבון. אם «הוציאו חשבונית» ו«הלקוח חושב» הם אותו שלב, כל איש מכירות סוגר אותו בדרכו, וההמרה בין השלבים מפסיקה לומר משהו. הפתרון העובד — שלב כפעולה ניתנת לבדיקה עם שדה חובה: כל עוד השדה לא מלא, העסקה לא מתקדמת הלאה.
כפילויות יוצרות גל שני של אי-התאמות. פנייה מגיעה מטופס, משיחה ומהתכתבות — ונוצרת כשלושה כרטיסים. חלק מהם נסגרים כדחייה, חלק פשוט נזנחים, ורישום העסקאות מציג משפך רחב מכפי שהוא. בלי כלל התאמה לפי איש קשר בחברה ומספר טלפון, המספרים נשארים דקורטיביים.
השלישי — עסקאות מחוץ למערכת. סיכמו בהתכתבות, סיפקו סחורה, ואת הכרטיס פתחו בדיעבד או לא פתחו בכלל. מקורות הלידים במקרה כזה לא מסומנים, ולכן דוח המכירות לא עונה על השאלה העיקרית: איזה ערוץ מביא הכנסות ואיזה — רק פניות. נסביר איך זה נסגר באמצעות הגדרה, ולא באמצעות שכנוע אנשי מכירות.
מה משתנה בעבודת מחלקת המכירות לאחר ההגדרה
אנליטיקת מכירות מפסיקה להיות תלויה באיסוף ידני. כל עוד מקור העסקה ממולא מהזיכרון והשלבים מקודמים ידנית, הדוח נבנה על מדגם שבו חלק מהכרטיסים בלי ערוץ ותאריך סגירה.
שדות חובה בכרטיס ומילוי אוטומטי של המקור מהמגע הראשון מסירים את סוג השגיאות הזה: שיעור העסקאות בלי מקור יורד לאחוזים בודדים, וההתאמה מול מערכת החשבונאות נעשית לפי מפתח, ולא לפי שם חברה דומה.
ההמרה לפי שלבים הופכת לניתנת לניהול, ולא לתוצאה שנצפית בדיעבד. רובוטים במעברים מתעדים תאריך כניסה ויציאה, ולכן צוואר הבקבוק נראה במספרים: באיזה שלב הולכות לאיבוד הכי הרבה עסקאות ואיפה הן נשארות זמן רב מהאחרות. תקן זמן בשלב לא נותן לכרטיס להיתקע — עסקה באיחור חוזרת לעבודה של האחראי בלי תזכורות מהמנהל.
מחזור העסקה מתקצר בזכות שקיפות, ולא בזכות לחץ. כשכל שלב כולל קריטריון מעבר, ה«לקוח חושב» השנוי במחלוקת מפסיק להיות סיבת תקלות: העסקה או מתקדמת לפי הכלל, או נסגרת עם סיבת דחייה מתועדת.
דיוק הדוחות נשען על כללי חישוב מחדש, ולא על המשמעת של המבצע. ב-Bitrix24 מגדירים לוגיקה אחידה: מה נחשב לתחילת המחזור, איך נלקחות בחשבון פניות חוזרות, ואילו שלבים נכנסים לסיכום. דוח המשפך נוצר לפי לוח זמנים, והזמן להכנתו יוצא מהשגרה של המנהל.
דרכים לאיסוף אנליטיקה: השוואה בין גישות ומגבלות
נתוני מכירות מגיעים לאנליטיקה בדרכים שונות, וכל דרך מטילה מגבלות משלה על אילו שאלות אפשר בכלל לשאול את המשפך.
סיכומים ידניים בטבלאות מחזיקים מעמד עד החלפת איש המכירות הראשונה, דוחות מובנים של Bitrix24 רואים רק את מה שמוזן לכרטיסים, והחלפת נתונים עם מערכת החשבונאות מוסיפה לעסקאות את עובדת התשלום והמשלוח. להלן השוואה בין הגישות לפי מה שכל אחת נותנת ומה שאינה נותנת.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| דוחות ידניים בטבלאות | חיתוך חד-פעמי, זרימת עסקאות קטנה | מתיישנים ביום המסירה, אין היסטוריית מעברים בין שלבים, שגיאות לא מתועדות |
| אנליטיקת משפך מובנית | כל השלבים מנוהלים בכרטיסים, השדות ממולאים באופן ממושמע | רואה רק את המערכת: תשלומים והחזרים מחוצה לה, לא תציג אי-התאמות מול מעגל החשבונאות |
| החלפת נתונים עם מערכת חשבונאית | יש צורך בהכנסות, תשלומים ועלות לפי עסקה | דורש התאמת ספרי עזר ומזהים יציבים, החלפה מתבצעת בהשהיה |
| אנליטיקה מרוכזת במאגר חיצוני | כמה ערוצים ומערכות, היסטוריה ארוכה | נדרש נוהל עדכון ואחראי על איכות הנתונים |
ההבדל מתגלה למרחק ארוך. דוח ידני לא ניתן לחשב מחדש בדיעבד בלי לאבד פירוט, ואנליטיקה מובנית מציגה שלבים אך לא מתיישבת עם הכספים. אנליטיקה מרוכזת מעל מעגל החשבונאות נותנת גם את זה וגם את זה — בתמורה להגדרת התאמה של ספרי עזר ונוהל החלפה שיהיה צריך לתחזק.
שלבי העבודה: מביקורת נתונים ועד מסירת נהלים
העבודה מתנהלת בסדר אחד: קודם מסדרים את הנתונים, אחר כך בונים דוחות, ואז בודקים אותם על עסקאות אמיתיות. סדר הפוך נותן גרפים יפים מעל שדות לא מלאים ושלבים כפולים — לפי מספרים כאלה לא מקבלים החלטות. להלן שלבי הטמעת אנליטיקת משפך מכירות ב-Bitrix24.
- ביקורת נתונים. מייצאים חיתוך של עסקאות מכמה חודשים, משווים מעברים בפועל לשלבים שהוגדרו, מחפשים שדות שאנשי מכירות ממלאים ידנית ולכן מפספסים, ועסקאות שתקועות בשלבי ביניים.
- סכימת המשפך. מקבעים סט שלבים והמשמעות שלהם, שדות חובה בכל שלב, כללי מעבר ופעולות אוטומטיות. את הסכימה מתאמים איתכם לפני ההגדרה — שינויים בדיעבד יקרים יותר.
- הגדרת כללים ודוחות. בונים דוחות לפי המרה בין שלבים, זמן שהיית עסקה בשלב, סיבות דחייה ועומס על עובדים. מפרידים הרשאות לפי תפקידים: מנהל רואה את כל המשפך, איש מכירות — רק את העסקאות שלו.
- בדיקה על עסקאות בקרה. מריצים עסקאות בדיקה בכל ענפי התהליך ומשווים את המספרים בדוחות לחישוב ידני. אי-התאמה בשלב הזה מעידה על שגיאה בכללים, לא בנתונים.
- נוהל עבודה עם נתונים. מתארים מי ומתי מעביר עסקה, איך נרשמת דחייה, מה עושים כששדות לא מלאים ומי אחראי על האיכות.
- מסירה. מוסרים הוראות, סכימות ותיעודי ניתוחים, מציגים נקודות בקרה שלפיהן אתם עצמכם מזהים ירידה במשפך.
סכימות רישום, הרשאות גישה, נהלים והוראות
אחרי הפעלת המשפך ב-Bitrix24 הצוות נשאר עם המערכת לבד: אנשי מכירות משנים סטטוסים, השיווק מוסיף מקורות, המנהל מבקש חיתוך חדש. אם סכימת המשפך, כללי מילוי השדות ומטריצת ההרשאות חיים רק בהתכתבות, העובד החדש הראשון כבר שובר את לוגיקת הדוחות.
לכן מוסרים ערכה שלפיה התהליכים משוחזרים בלעדינו:
- סכימת המשפך — סטטוסים, הסדר שלהם, תנאי מעבר, סימן הצלחה וכישלון. לפיה משחזרים את לוגיקת ההמרה אחרי כל עריכה.
- כללי מילוי שדות — שדות חובה ומחושבים, ספרי עזר של מקורות וסיבות דחייה, איסור על קלט חופשי. עסקאות עם אנליטיקה ריקה הופכות לפחותות באופן ניכר.
- מטריצת הרשאות — תפקידים, שיוך לתחומים ומחלקות, הרשאות צפייה, שינוי וייצוא. המנהל רואה את העסקאות שלו, ומידע מיותר לא יוצא החוצה.
- הוראה למחלקת המכירות — תרחיש עבודה מדורג עם עסקה: מתי לשים איזה סטטוס, מה לצרף, איך לתעד דחייה.
- תיעוד דוחות — דוחות ייחוס, שדות ומסננים שמהם הם נבנים, סדר פעולות במקרה של אי-התאמה במספרים.
- נוהל שינויים והתאמה — מי רשאי לערוך את הסכימה והשדות, איך מתאמים סטטוסים חדשים כדי לא לאפס את ההיסטוריה; תדירות בדיקת ההתאמה עם מערכת החשבונאות, חיפוש כפילויות ועסקאות תקועות.
הערכה נשארת אצלכם: עובדים חדשים נכנסים לתהליך לפי הוראות, ולא לפי סיפורים, ושינויים באנליטיקה לא מחייבים לקרוא לנו.
מקרה בוחן: אי-ההתאמות בדוחות הצטמצמו פי שלושה
ספק סיטונאי עם כמה תחומי מוצרים ניהל עסקאות ב-Bitrix24, אבל כל מחלקה שינתה את שמות השלבים לפי עצמה: אצל אחדים «חוזה» סימן תיאום תנאים, אצל אחרים — כבר חתימה. אנשי מכירות מילאו את מקור הפנייה מהזיכרון, וחלק מהעסקאות נפתחו ידנית אחרי המשלוח. דוח המשפך לא התיישב עם הייצוא ממערכת החשבונאות, ועל ההתאמה הלך כמעט יום עבודה של אנליסט.
צמצמנו את השלבים לסכימה אחידה עם סדר קבוע ואיסור לדלג על שלבים. המקור התחיל להירשם אוטומטית מערוץ הפנייה ברגע יצירת העסקה, והעסקה עצמה קושרה למסמך במערכת החשבונאות לפי מזהה — דוח המשפך ונתוני המכירות הפסיקו לחיות בנפרד.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| אי-התאמות של דוח המשפך עם הרישום | 12–15% מהעסקאות מדי חודש | 3–4% |
| עסקאות בלי מקור פנייה | יותר ממחצית | בודדות, נסגרות במשימה |
| זמן להתאמת הדוח | כעין יום | 1–2 שעות |
| עסקאות מחוץ לשלבים עדכניים | אחרי החלפת המשפך — עשרות | מזוהות באותו יום |
אי-ההתאמות הצטמצמו פי שלושה, והעיקר — הפסיקו להצטבר: כל עסקה חדשה מקבלת מיד שלב ומקור נכונים. ההמרה בין השלבים נקראת כעת לפי ערוצים, והתחזית לעסקאות שלא נסגרו נשענת על נתונים, ולא על הזיכרון של אנשי המכירות.
מה לעשות אם המשפך מוגדר אבל המספרים לא מתיישבים?
אי-ההתאמה כמעט אף פעם לא במשפך עצמו. הדוח מחשב לפי המשפך הנבחר, התקופה והשלבים הנוכחיים, והייצוא של העסקאות — לפי כל התחומים בבת אחת, יחד עם הסל והארכיון.
לכן הצעד הראשון הוא להוציא נתונים גולמיים לאותה תקופה עם תאריכי יצירה וסגירה ולהשוות שורה מול שורה: האם הפער הוא בכמות העסקאות או בסכום שלהן.
מקורות אבודים צפים ראשונים. שדה המקור מסומן במגע הראשון, אבל בביקור חוזר התגיות נדרסות, והעסקה עוברת ל«כניסה ישירה». בודקים בכמה עסקאות המקור ריק או עומד על ברירת מחדל, והאם יש לידים שלא הומרו ואחריהם נגררים שיחות והתכתבות.
כפילויות — סיבה נפוצה שנייה. הן מופיעות בייבוא מטבלאות, כשפנייה מגיעה מטופס וממסנג'ר בו-זמנית, או כשהמנהל יוצר עסקה בלי למצוא את הלקוח לפי טלפון.
בודקים את כלל הסרת הכפילויות, מפתח הייבוא, והאם כל תשובה בדיאלוג יוצרת עסקה חדשה: כפילות מעוותת גם את מספר העסקאות בשלב וגם את שווי העסקה הממוצע.
בהמשך — אי-התאמות תפעוליות: הרשאות גישה, גבולות תקופה ואזור זמן, סכום עם הנחה מול סכום בלעדיה, עסקאות בסל ובשלבי ארכיון. אותו דוח תחת המנהל ותחת איש המכירות ייתן מספרים שונים על אותם נתונים.
סדר הניתוח נוקשה: התאמה של ייצוא גולמי והתקופה, אחר כך מקורות, אחר כך כפילויות, ורק לאחר מכן הגדרות שלבים ורובוטים. תיקונים במשפך לפני השלב הזה פשוט מוחקים את עקבות הבעיה.
שאלות נפוצות על איסוף והתאמת נתונים
להלן שאלות שעולות לרוב לפני ההתחלה: הן נוגעות להחלפת נתונים בין CRM, מעגל החשבונאות והאנליטיקה, ולא לממשקים. התשובות קצרות, אבל מראות איך כל ספק נסגר ברמת ההגדרה.
למה המספרים בדוח ובכרטיסי העסקאות לא מתיישבים?
אי-ההתאמה מוסברת כמעט תמיד ברגע תיעוד שונה: העסקה מחליפה שלב במקום אחד, והייצוא לוקח את מצבה לפי לוח זמנים. אנחנו מנהלים החלפה לפי יומן שינויים, לא בכתיבה מחדש מלאה, ושומרים מזהים של עסקאות ושלבים — בזכות זה כל מספר ניתן לפרוס עד לרשומה מסוימת ולהבין מאין הוא בא.
אפשר להגדיר הכול בלי לעצור את מחלקת המכירות?
כן. העבודה מתבצעת במעגל בדיקות שבו היסטוריית העסקאות מועתקת בלי להשפיע על בסיס העבודה. את המעבר עושים בחלון של פעילות נמוכה, ואת ההחלפה הראשונה מפעילים במצב קריאה בלבד — אנשי המכירות ממשיכים לעבוד בממשק הרגיל, והחלפת הנתונים פועלת ברקע.
האם יהיה צורך לנהל טבלאות ידניות במקביל?
המשמעות של ההגדרה היא להסיר קלט כפול. ספרי עזר, אחראים ושלבים נמשכים מהמערכת, ואי-התאמות שחיפשו קודם ידנית מוצגות בדוח בקרה נפרד. קבצים ידניים נשארים רק כמקור לתיקונים חד-פעמיים, והכניסה שלהם לנתונים הכלליים נראית לעין.
איך מועברת היסטוריית העסקאות והאם השלבים לא הולכים לאיבוד?
ההיסטוריה מועברת במעבר נפרד: קודם מבנה המשפכים והשלבים, אחר כך עסקאות עם שיוך לאנשי קשר ולחברות. רשומות מותאמות לפי מפתחות, כפילויות נחתכות, ועסקאות סגורות מסומנות בתאריכים נכונים. אחרי ההעברה משווים כמויות וסכומים לפי שלבים — אי-התאמה מותרת רק במקום שבו היא מאושרת בנתוני המקור.
מי יראה את כל הנתונים ואיך מוגבלות ההרשאות?
ההרשאות מחולקות לפי תפקידים: מנהל תחום רואה אנליטיקה מרוכזת, איש מכירות — רק את העסקאות שלו, והחלפה אינטגרטיבית פועלת תחת חשבון נפרד עם הרשאות מינימליות נדרשות. זה מונע מצבים שבהם הדוחות חיים מחוץ לנוהל ההרשאות.
נדון במשימה: מה צריך כדי להעריך את היקף העבודות
כדי לחזור עם הערכה ותוכנית, ולא עם ניסוחים כלליים, אנחנו צריכים מינימום של נתוני קלט על הפורטל שלכם. להלן רשימה קצרה של מה שמזרז משמעותית את הניתוח: עם הסט הזה אנחנו רואים מיד את היקף העבודות במשפך ומבינים היכן יידרש ארגון מחדש של ישויות והיכן מספיקות הגדרות אנליטיקה.
- הרשאות ונתונים. פורטל עם הרשאות צפייה ב-CRM, במדורי המשפכים ובדוחות; משתמש בדיקה נפרד כדי לא להפריע לעבודת המחלקה. אם הפרדת ההרשאות נוקשה — תארו אילו חיתוכים מותר לנו לראות.
- סכימת תהליך המכירות. איך העסקה עוברת מהפנייה הראשונה ועד התשלום: כמה שלבים, מי ולפי איזה סימן מעביר אותה הלאה, ואילו שלבים כיום מכפילים זה את זה.
- דוגמאות לדוחות. שניים-שלושה ייצואים שאתם עובדים איתם עכשיו: מה אתם מסתכלים בהם, אילו מספרים חסרים ואילו מדדים מעוררים ספק באמינות.
- מקורות לידים ואינטגרציות. טלפוניה, טפסים באתר, מסנג'רים, 1C — מאין מגיעה הפנייה ואיך מועברים סטטוסים חזרה לפורטל.
- ספרי עזר ושדות. שדות חובה בכרטיס, אחראים, סיבות דחייה. כך נראה היכן האנליטיקה מתפרקת בגלל נתונים לא מלאים, ולא בגלל הלוגיקה.
- מגבלות של תחילת הפרויקט. נהלים, תפקידים, מועדי סגירת תקופה — כל מה שאין לשנות בתהליך ההגדרה.
תארו את המשימה בצורה חופשית: מצב המשפך הנוכחי, מה בדיוק צריך להיחשב ואילו החלטות אתם רוצים לקבל לפיו. נחזור עם הערכת היקף העבודות, תוכנית שלבים ורשימת סיכונים בלוחות זמנים.