הגדרת סגמנטים של קהל בשיווק CRM ב-Bitrix24

מדוע סגמנטים של קהל Bitrix24 נכשלים בדיוור

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

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

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

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

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

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

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

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

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

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

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

סגמנטים סטטיים ודינמיים: השוואת גישות

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

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

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

שלבי הגדרה: מביקורת המסד ועד בדיקת תרחישים

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

1. ביקורת מסד הלקוחות — מייצאים חתך של אנשי קשר, חברות ועסקאות, מחשבים שיעור שדות מלאים, מחפשים כפילויות לפי טלפון ודוא"ל, בודקים אם המקורות מסומנים. בפלט — מפה: אילו מאפיינים חסרים ואיפה הנתונים סותרים זה את זה.
2. סכימת שדות ומאפיינים — מחליטים היכן חי כל מאפיין: שדה סטנדרטי, מותאם אישית או ערך מחושב מתוך ישות מקושרת. מיד קובעים כללי מילוי, אחרת הסגמנט «יזלוג» בעוד חודש.
3. מילוי אוטומטי של מאפיינים — חלק מהנתונים מגיע מטפסים, חלק מסומן על ידי רובוטים וכללים בעת שינוי שלב. בלי זה אצל לידים חדשים השדות נשארים ריקים, והסגמנט לא רואה אותם.
4. בניית תנאי בחירה — בונה כללים: סט שדות, אופרטורים, קבוצות מקוננות «ו/או», החרגות חובה לפי הסרות מדיוור, כפילויות וחברות לא פעילות.
5. מדגם בדיקה של אנשי קשר — כל סגמנט בודקים על 20–50 רשומות: משווים ידנית מי נכנס ומי לא, ומשיגים שהמונה יתאים לציפייה.
6. בדיקת תרחישי דיוור — הרצה על כתובות בדיקה: תנאי הפעלה, תדירות פניות, שרשרת הודעות, תקינות קישור הסרה והפעלות חוזרות.
7. מסירה והדרכה — מוסרים מפת סגמנטים, תקנון עדכון מאפיינים ותזכיר לעריכות; עוברים עם המשווק על איך להקים סגמנט חדש בלי מפתח.

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

כללי הפעלה, מסננים ותקנונים לעבודה עם המסד

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

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

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

ניתוח מקרה יישום: פחות הודעות לא רלוונטיות וחסימות

לפני: דיוור לכל המסד

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

שיעור הנמענים השגויים הגיע ל-27%, מדי חודש הגיעו 30-40 תלונות על דיוור, ושירותי דואר סיווגו את ההודעות לעתים קרובות יותר כספאם המוני.

אחרי: סגמנטים שנבנים מחדש בעצמם

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

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

במה שונים קבוצות אנשי קשר מרשימות דיוור

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

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

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

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

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

ספקות טכניים לפני תחילת ההגדרה

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

איש קשר בלי עסקה משתתף במדגם?

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

מה לעשות עם מסד אנשי קשר מפוזר?

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

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

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

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

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

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