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

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

הכישורים שלנו:

שאלות נפוצות

למה פלחי קהל ב-Bitrix24 מתיישנים תוך חודש

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

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

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

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

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

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

מה נותן פילוח מנוהל: 4 אפקטים מדידים

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

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

דיוק ההגעה לקבוצה

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

שיעור הסרות מהתפוצה

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

זמן הכנת קמפיין

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

רכישות חוזרות

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

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

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

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

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

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

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

סדר העבודות: ממלאי נתונים ועד תקנון

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

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

מפות שדות, כללי הפעלה ותקנון תמיכה

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

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

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

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

מקרה בוחן: שיעור הפתיחה עלה, ההסרות ירדו בחצי

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

מה שינו בכללים

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

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

מדדים לפני ואחרי

מדד לפני אחרי
שיעור פתיחות 11–12% 29–31%
הסרות לשליחה 0.9% 0.4%
הרכבה ידנית של פלחים כשש שעות בשבוע כשעה

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

במה שונה קבוצה דינמית מקבוצה סטטית?

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

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

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

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

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

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

ספקות טכניים: כפילויות, עומס, מגבלות

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

מה עם כפילויות אנשי קשר מערוצים שונים?

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

החישוב מחדש של פלח מעמיס על המערכת?

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

האם יש גבול למורכבות התנאים?

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

האם היסטוריית השינויים נשמרת?

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

אפשר לייצא נתונים של פלח?

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

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

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

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

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

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

תארו את המשימה — נחזור עם הערכה ותוכנית עבודה.