הגדרת עסקאות ב-Bitrix24: היכן נשברת משפך המכירות
בהתקנה הסטנדרטית של Bitrix24 משפך המכירות חוזר על שלבי הדגמה: „חדש“, „בטיפול“, „הושלם“. תרשים כזה אינו מתאר את מחזור העסקה בפועל — מנהלים מזיזים כרטיסים ידנית ובאופן שרירותי, ועסקאות נתקעות בשלב שבו לא הוגדר אחראי או לא הוגדרה הפעולה הבאה.
נקודת הכשל השנייה — מילוי ידני של כרטיסים. אם השדות אינם חובה במעבר, והסכום ונתוני הלקוח מועברים ידנית מהחשבונית או מהאיש קשר, ב-CRM מצטברים סכומים ריקים, כפילויות ואנשי קשר אבודים. המנהל רואה את הסכום הכולל של המשפך, אך אינו מבין אילו עסקאות חיות ואילו תלויות כמשקל מת.
השלישית — הרשאות גישה: כאשר גישה מלאה לעסקאות ניתנת לכל המחלקה, מנהלים עורכים כרטיסים של אחרים, והדוחות מפסיקים להסתדר. הגדרת עסקאות ב-Bitrix24 סוגרת זאת לא בשכנוע אלא במכניקה — שדות חובה במעבר, רובוטים וטריגרים לפי זמן תקיעה, והפרדת הרשאות לפי תפקידים.
בהמשך נפרק כיצד זה נסגר: מתרשים השלבים וכללי האוטומציה ועד דוחות שאפשר להאמין להם.
מה נותן סדר בעסקאות: אפקט מדיד
האפקט הראשון — מהירות מעבר העסקה. כאשר לכל שלב מוגדרים תנאי כניסה ויציאה, והמעבר מבוצע על ידי רובוט ב-Bitrix24 לפי אירוע, המנהל מפסיק להיות צוואר בקבוק: חשבונית, תזכורת, יצירת משימה יוצאים בלי מעורבותו. המחזור מהמגע הראשון ועד התשלום מתקצר פי אחד וחצי עד שניים — זה ניכר במשך העסקה הממוצע בדוחות.
השני — שקיפות משפך המכירות: שיעור העסקאות ללא תנועה. במשפך לא מסודר הוא מגיע עד לשליש, מפני שכרטיסים תלויים בשלב בלי פעולה הבאה מוגדרת.
הכלל „אין משימה — אין שלב“ ותזכורות אוטומטיות לפי מועד שומרים על המדד בטווח של כמה אחוזים, ועסקאות תקועות נראות בדוח המנהל באותו יום, ולא בסוף הרבעון.
השלישי — מספר הפעולות הידניות לכל עסקה. השלמת שדות מכרטיס החברה, מסמכים לפי תבנית, מגעים חוזרים לפי לוח זמנים מוסרים מהמנהל: במקום שבו נדרשו עשרה מעברים בין מדורים, נשאר אחד. הזמן שהתפנה עובר לשיחה עם הלקוח, ולא לתחזוקת המערכת.
הרביעי — סוג הנתונים האבודים. פניות ממייל וממסרים, סירובים עם סיבות, היסטוריית התכתבות נשמרים בעסקה, ולא בתיקיות אישיות. סיבות סירוב נספרות לפי המשפך, ולא נאספות בסקר, וכאשר עובד עוזב, העסקאות נשארות בעבודה יחד עם ההקשר.
שלבים ידניים, רובוטים או אוטומציה חיצונית: מה לבחור
שלבים ורובוטים מובנים מכסים תהליך טיפוסי בלי קוד: הרובוט מעביר את העסקה, יוצר משימה לאחראי, שולח חשבונית. כל עוד ההיגיון נכנס למבנה „אירוע → פעולה“, זה מספיק, ואת השינויים מבצע מנהל ה-CRM, ולא מפתח.
ברגע שמופיעה הסתעפות לפי סכום, סוג לקוח או מלאי במחסן, התנאים המובנים אינם מספיקים. אז או שמתאימים את הכרטיס, הרשאות הגישה והדוחות לתהליך הספציפי, או שמגדירים אינטגרציה חיצונית עם מערכת הנה"ח, ומשאירים ב-CRM סטטוס והיסטוריה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| שלבים ורובוטים מובנים | התהליך טיפוסי, יש מעט הסתעפויות, נדרש אתחול מהיר | אינו מכסה תנאים וחישובים מורכבים; עם צמיחת ההיגיון גדל מספר הרובוטים והקונפליקטים ביניהם |
| התאמה לתהליך | כללי אישור ייחודיים, שדות משלכם, תפקידים ודוחות | נדרשת תחזוקה בעת עדכונים; ככל שהשינויים עמוקים יותר, ההעברה יקרה יותר |
| חיבור למערכת הנה"ח | נתונים על מלאי, משלוחים ותשלומים נמצאים מחוץ ל-CRM | תלוי ביציבות הסנכרון: אי-התאמות, העברה כפולה, השהיית סטטוס |
היכן עובר הגבול
מגבלת האוטומציה אינה בכלי, אלא בנתונים. אם מנהלים עורכים שדות ידנית ומנהלים עסקאות תוך עקיפת השלבים, הרובוטים פועלים על מצב שגוי. לכן קודם מקבעים כללי מילוי והרשאות גישה, ורק אחר כך מבצעים אוטומציה.
סדר ההטמעה: מביקורת המשפך ועד מסירת הנהלים
ביקורת משפך המכירות מתחילה לא בראיונות, אלא בייצוא עסקאות לתקופה: בודקים באילו שלבים מצטבר עיקר המסה, כמה זמן עסקה שוהה בכל שלב, אילו שדות ממולאים לסירוגין. זה נותן תמונה אמיתית במקום תפיסת המנהל את התהליך — ולפיה מתכננים את התרשים. שלבי הטמעת ה-CRM פורשים ברצף, כדי שלא יהיה צורך להרכיב את הפורטל מחדש לאחר ההשקה.
- סקירה. ניתוח השלבים, השדות, הדוחות והתפקידים הנוכחיים; בנפרד מתעדים אילו עסקאות מנוהלות מחוץ למערכת ומדוע.
- תרשים שלבים. רשימת שלבים, עילות מעבר, שדות חובה בכל שלב; שלבים מיותרים מצמצמים, ושלבים מעורפלים מפצלים.
- הגדרת תהליכים עסקיים. רובוטים ואוטומציה: יצירת משימות, מכתבים, מעבר בין שלבים לפי אירוע, ולא לפי הזיכרון של המנהל.
- הרשאות גישה. מטריצת תפקידים לפי שלבים ושדות: מנהל, ראש מחלקה, כספים — כל אחד רואה רק את שלו, וייצוא מסד הנתונים מוגבל.
- בדיקה על עסקאות אמיתיות. הרצת תרחישים על עותק של הפורטל: עסקה נכנסת, חזרה משלב, סירוב, פנייה חוזרת. את התיקונים מבצעים לפני מסירה לעבודה.
- הדרכה ומסירת נהלים. הוראות לפי שלבים, מפת רובוטים, מטריצת הרשאות, סדר שינוי המשפך והאחראי לכך.
לאחר מסירת הנהלים הפורטל חי לפי מסמך, ולא לפי הזיכרון של המנהל: כל שלב או רובוט חדשים מתוארים דרך המשימה שהם פותרים.
מה נשאר אצלכם: מפות שלבים, הרשאות, נהלים
שלבים מוגדרים כשלעצמם לא עובדים: בלי תיאור כללים מתחילים לשנות אותם „לפי עצמם“ כבר אחרי חודש, וההיגיון מתפרק. לכן אנחנו מוסרים לא CRM מוכן, אלא ערכת ארטיפקטים שלפיה המחלקה מנהלת עסקאות בלי מעורבותנו, והשינויים מוכנסים לתרשים מובן, ולא לתהליך חי.
- מפת שלבים — תרשים המשפך עם סדר ושמות השלבים, תנאי מעבר ורשימת שדות חובה בכל צעד.
- מטריצת הרשאות גישה — מה כל תפקיד רואה, משנה ומייצא: בנפרד הרשאה לשינוי שלב, לעריכת סכום ולמחיקת עסקה.
- מערכת כללים ורובוטים — לכל אחד מצוין מה מפעיל אותו ומה קורה לאחר מכן: משימה, מכתב, תזכורת, הסלמה למנהל בזמן תקיעה.
- הוראות למנהלים — תזכירים בעמוד אחד לכל שלב: מה למלא, אילו קבצים לצרף, מתי להזיז את העסקה הלאה.
- נוהל עבודת מחלקת המכירות — מועדי טיפול בפנייה נכנסת, מה עושים עם עסקה תקועה, מתי לתעד סירוב וכיצד להחזיר אותה לעבודה.
- תיעוד ה-CRM — תיאור שדות, ספריות וקשרים של העסקה עם איש קשר וחברה, כדי ששדות חדשים לא ישכפלו שדות קיימים.
- יומן שינויים וגיבויים — מה ומתי השתנה בתצורה וכיצד להחזיר את תרשים השלבים וההרשאות הקודם.
את ההרכב מתאימים למספר המחלקות והתפקידים: עבור צוות קטן חלק מהבלוקים מצטמצם לעמוד אחד, אבל מפת השלבים, מטריצת ההרשאות והנוהל נשארים תמיד.
מקרה בוחן: איך צמצמנו פעולות ידניות במחלקת המכירות
לפני ואחרי ההטמעה: היכן העסקאות קפאו
הלקוח — ספק של ציוד תעשייתי, מחלקה של תשעה מנהלים. לפני תחילת העבודה ייצאנו את היסטוריית העסקאות מ-Bitrix24 וחישבנו את מדדי המשפך. מתוך 420 עסקאות בעבודה, 160 לא זזו יותר משבוע, ושני שלישים נתקעו באישור החשבונית.
על עסקה אחת היו 14 פעולות ידניות: להפיק חשבונית, להרכיב מכתב, ליצור לעצמך משימה, לגרור ידנית את הכרטיס לשלב הבא, להזכיר ללקוח על עצמך. חלק מהצעדים פשוט נשכח — הכרטיס נשאר בשלב הישן, והדוח של המנהל לא תאם את המציאות.
מה שינינו ומה זה נתן
את השלבים תיארנו עם שדות חובה ותנאי מעבר. על צעדים מרכזיים תלינו רובוטים: החשבונית יוצאת אחרי אישור הסכום, משימה עם מועד בקרה נוצרת מעצמה, עם קבלת התשלום הכרטיס מחליף שלב בלי מעורבות המנהל. הרשאות הגישה הופרדו לפי מחלקות, והחלפת אחראי נכתבת על ידי המערכת להיסטוריית הכרטיס.
חודשיים לאחר ההטמעה זמן מעבר העסקה הצטמצם מ-26 ל-14 ימים, שיעור הכרטיסים ללא תנועה ירד מ-38% ל-9%, והפעולות הידניות לכל עסקה הפכו ל-5 במקום 14. המנהל כעת רואה צווארי בקבוק לפי הדוח, ולא לפי שאלות בישיבת בוקר. הצמצום בפעולות ידניות כאן נשען לא על „כפתור קסם“, אלא על משמעת שלבים וכללי מעבר.
במה שונים שלבים, רובוטים ותהליכים עסקיים
שלב — מצב העסקה בתרשים המשפך: הוא עונה על „היכן אנחנו עכשיו“, ולא „מה לעשות הלאה“. היגיון המעברים נקבע לא על ידי השלב, אלא על ידי תנאי כניסה: מי מעביר את העסקה, האם השדה חייב להיות מלא, האם אפשר לדלג על שלב. ב-Bitrix24 זה מוגדר ברמת הכרטיס וההרשאות.
רובוט — כלל אוטומטי שמשויך לשלב או לאירוע של העסקה. הוא פועל בתרחיש שטוח: פעולה אחת — תוצאה אחת, בגבולות עסקה אחת ומשפך אחד. היומן מראה מדוע הכלל הופעל או הוחמץ, ועריכת רובוט אחד לא שוברת שלבים סמוכים.
תהליך עסקי — מסלול רוחבי עם הסתעפויות, צעדים מקבילים והשתתפות של מחלקות שונות. אישור הנחה, בקשה להרכבה לא סטנדרטית, בדיקת ספק: התהליך מופעל מעל העסקה, חי על כמה שלבים ושורד החלפת אחראי.
מה לבחור: תקשורת לינארית ותזכורות — רובוטים, הם צפויים וזולים יותר לתחזוקה. אישורים עם חזרה לתיקון ומספר משתתפים — תהליכים עסקיים. לרוב התרשים משולב: שלבים מחזיקים את הדיווח, רובוטים מזיזים את העסקה, ותהליכים סוגרים חריגים.
הרשאות גישה — שכבה נפרדת. רובוט ותהליך מבוצעים בשם משתמש או חשבון שירות: בלי הרשאה לשדה או לשלב הכלל יעבוד חלקית או יתבטל. לכן מטריצת התפקידים מתוארת לפני האוטומציה, אחרת המשפך עובד בבדיקה ונשבר על עסקאות אמיתיות.
התלבטויות לגבי הרשאות, אינטגרציות והעברת נתונים
התלבטויות בדרך כלל צפות בשלב שבו ההיגיון של השלבים עוד לא סוכם, אך יהיה צורך להעביר אותו לנתונים חיים. זה אות תקין: כלומר, גבולות האחריות ונקודות החיבור למערכת הנה"ח הובהרו לפני תחילת העבודה, ולא אחרי ההשקה. להלן מה שלרוב מעכב את ההחלטה.
כיצד להפריד גישה אם במחלקה אזורי האחריות חופפים?
הרשאות נאספות בשלוש רמות: תפקיד במערכת, הרשאות לשלב מסוים ונראות שדות. התפקיד קובע גישה למדור, רמת השלב — אילו עסקאות העובד רואה ויכול להזיז, ונראות השדות מחסימה סכומים וחוזים מצוותים סמוכים.
בנפרד מגדירים איסור על החלפת אחראי ועריכה של שלבים סגורים, אחרת היסטוריית העסקאות מתאפסת בדיעבד. כל שינויי ההרשאות נכנסים ליומן הפעולות — רואים מי ומתי קיבל גישה מורחבת.
מה יקרה להיסטוריית העסקאות בעת העברת נתונים ל-CRM?
מעבירים לא רק עסקאות פעילות, אלא גם סגורות: תאריכי יצירה, אחראים, התכתבות, קבצים, הערות והשלב הנוכחי. נקודת המפתח — ספריות: ספקים ופריטים מאחדים פעם אחת, ומכאן והלאה עסקאות מפנות אליהם, ולא יוצרות כפילויות.
לפני הייצוא מריצים העברה מלאה במתאר בדיקה ומשווים מספר עסקאות, סכומים והתפלגות לפי שלבים — פערים מטופלים לפני ההשקה.
כיצד לקשר עסקאות למערכת הנה"ח כדי שהנתונים לא יתפצלו?
מערכת אחת נשארת מקור האמת למסמכים ראשוניים, השנייה — לתהליך המכירה, והקשר נשען על מזהה חיצוני של הספק או ההזמנה. כך הכפילויות נמנעות: ייצוא חוזר מעדכן רשומה קיימת, ולא יוצר חדשה. סטטוסי תשלום ומשלוח נמשכים חזרה לכרטיס העסקה, ולכן המנהל לא צריך להצליב עם מערכת הנה"ח ידנית.
האם יהיה צורך לעצור את המחלקה בזמן ההגדרה?
לא. שלבים ורובוטים מפרסמים בחלקים, קודם בקבוצת פיילוט, והשאר ממשיכים לעבוד במצב הנוכחי. את המעבר מבצעים בשעת פעילות נמוכה, ואת השינויים בהרשאות, באוטומציה ובשדות ניתן להחזיר בפעולה אחת, אם ההתנהגות התגלתה כשונה מהצפוי.
מי יוכל לשנות הגדרות לאחר המסירה?
מעבירים למנהלים תרשים שלבים, מטריצת הרשאות, רשימת אוטומציות עם תנאי הפעלה והוראות לתיקונים טיפוסיים. המומחים שלכם מכאן והלאה מוסיפים שדות ומתקנים טקסטים של התראות בעצמם — בלי לפנות אלינו על כל פרט קטן.
נדון במשפך שלכם ונחזור עם תוכנית
כדי שהערכת היקף העבודה תהיה מדויקת, ותוכנית ההטמעה — ברת ביצוע, מספיק לתאר את מבנה המשפך הנוכחי ואת האופן שבו הוא אמור לעבוד לאחר השיפורים. חלק מהסעיפים אפשר לדייק בשיחה — אבל ככל שנתוני המוצא קונקרטיים יותר, כך יהיו פחות סבבי הבהרה לפני תחילת העבודה.
- רשימת שלבי העסקה בסדר הנוכחי ומה משמעות כל אחד: היכן המנהל מסנן, היכן ממתין לתשובת הלקוח, היכן מעביר לעסקה עם תשלום.
- שדות חובה בכל שלב: אילו נתונים אסור לעסקה להמשיך בלעדיהם ומי ממלא אותם.
- רובוטים וטריגרים: מה צריך לקרות אוטומטית בעת החלפת שלב — יצירת משימה, מכתב ללקוח, חשבונית, תזכורת על עסקה תקועה.
- הרשאות גישה: מי רואה ומזיז עסקאות, מי משנה סכומים ואחראי, היכן נדרשות הגבלות לפי מחלקות ומדוע.
- חיבורים למערכת הנה"ח 1C, טלפוניה, מייל וטפסי אתר: אילו נתונים ובאיזה כיוון צריכים לעבור.
- היקפים: כמה עסקאות עוברות בחודש, כמה מנהלים ומשפכים בפעולה, האם נדרשת העברה של היסטוריה מצטברת.
- חריגים ונוהל: עסקאות לא סטנדרטיות, אישור הנחות, פניות חוזרות, דרישות לשמירת נתונים.
- מה כבר הוגדר ומה מפריע כעת: היכן עסקאות הולכות לאיבוד, אילו שלבים משוכפלים, על מה מתלוננים המנהלים.
תארו את המשימה במכתב, בטבלה או בשיחה קצרה — נחזור עם הערכת היקף העבודה, תרשים שלבים ותוכנית עבודה. לאחר סיכום נתחיל מיד: הגדרת עסקאות ב-Bitrix24 מתבצעת בשלבים, ולכן את השינויים הראשונים תראו לפני השלמת כל ההיקף.