הגדרת לידים ב-Bitrix24: אוטומציה של משפך, שלבים ורובוטים

הגדרת לידים ב-Bitrix24: היכן נשבר המשפך

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

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

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

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

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

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

מה נותנת אוטומציה של טיפול בפניות ובשלבים

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

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

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

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

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

אפשרויות הפצת לידים: השוואת גישות

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

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

שלבי הטמעה: מביקורת המשפך ועד מסירה

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

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

1. ביקורת המשפך. מתעדים את המסלול בפועל של הפנייה לפי מקורות ונקודות כניסה, ומשווים לנהלים. התוצאה — מפה עם מספרים: שיעור הפניות בלי מגע ראשון, זמן עד תגובה, אובדנים בכל שלב.
2. סכמת שלבים. מתכננים סט של שלבים לפי מחזור העסקה בפועל, ולא לפי תבנית. לכל שלב — סימן מעבר אחד ברור, כדי שהמנהל לא יגרור כרטיסים ידנית ולא יבחר שלב באקראי.
3. שדות והפצה. שדות חובה בכרטיס, כללי מינוי אחראי, תור משותף והצבה אוטומטית של משימות.
4. הגדרת רובוטים. פעולות אוטומטיות נקשר לאירועים: תזכורת בזמן קיפאון, מכתב ללקוח אחרי החלפת שלב, מינוי מחדש כשהאחראי חסר, התראה למנהל על שלב מתמשך.
5. בדיקת תרחישים. מריצים כל מסלול עם פנייה לבדיקה, כולל לא שגרתיים: פנייה חוזרת, סירוב, החזרה מהארכיון, שינוי סכום.
6. מסירה והפעלה. מוסרים את סכמת השלבים, רשימת הרובוטים ונהלים קצרים למחלקה. בשבועות הראשונים בוחנים את המשפך על נתונים חיים ומתקנים כללים אם התרחיש מתנהג אחרת מאשר בפנייה לבדיקה.

סכמות תהליכים, הרשאות גישה ונהלי עבודה

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

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

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

מקרה בוחן: זמן התגובה לפנייה הצטמצם פי שלושה

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

היכן פניות הלכו לאיבוד

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

מה שינינו

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

כעבור חודשיים זמן התגובה הראשונה הממוצע הצטמצם מכמה שעות ל-12-15 דקות, שיעור הפניות האבודות — מ-18% ל-2-3%, ושיחות שלא נענו הופכות אוטומטית למשימות. דוחות לפי שלבים החליפו את הטבלה הידנית: צווארי הבקבוק של המשפך נראים בזמן אמת, ולא רק בסיכום החודש.

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

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

מצבי ביניים יש מעט, ולכל אחד יש סדר פעולות משלו.

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

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

ספקות טכניים ושאלות נפוצות על הטמעה

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

איך להגביל הרשאות גישה כך שמנהל לא יראה משפך של אחר?

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

איך לבדוק שרובוטים באמת פועלים?

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

האם היסטוריית העסקאות תישמר בעת שינוי המשפך?

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

נדבר על המשימה ונחזור עם הערכה ותוכנית

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

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

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