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