מדוע משפכי אימייל של Bitrix24 לא מגיעים לכדי עסקאות
המייל יוצא מ-Bitrix24, וחלק מהכתובות אינן מקבלות אותו. המיילים לא מגיעים מסיבות שונות: דומיין ללא רשומות אימות, מוניטין שולח שלא חומם, בסיס נתונים שנאסף ללא הסכמה מאושרת. יכולת המסירה של המיילים לא נמדדת כלל — התפוצה נחשבת רשמית להצלחה, אף שמחצית מהשרשרת כבר קרועה.
מכאן הפער עוד יותר מורגש. הלקוח משיב למייל, אך התשובה אינה הופכת לפנייה: לתיבת הדואר אין קישור לאיש קשר, הנושא אינו מזוהה כתשובה לתפוצה מסוימת, והמקור אינו נמשך לכרטיס. זהו בדיוק הפער בין המייל לעסקה — העניין של הלקוח מתועד במייל, אך לא במערכת.
בגלל זה הלידים הולכים לאיבוד: חלקם שוקעים בתיבה של המנהל, חלקם נסגרים בניסוח "אין מענה", ושלב העסקה עומד במקום בעוד הלקוח כבר מוכן לדון בתנאים. על איש קשר חם המנהל לומד אחרון — כשזה כבר התקרר או עבר למי שהשיב מהר יותר.
המחצית השנייה של הבעיה נמצאת בלוגיקה של המשפך עצמו: המעבר בין השלבים קשור לפעולה ידנית, ולא לאירוע במייל (פתיחה, מעבר בקישור, תשובה). בלי זה, משפכי האימייל של Bitrix24 נשארים תפוצה לפי לוח זמנים, ולא כלי מכירה.
נפרק כיצד זה נסגר: מהגדרת יכולת מסירה וחיבור התיבה עם הלידים ועד מעברים אוטומטיים בין שלבים ובקרת זמני תגובה.
מה משתנה לאחר הגדרת שרשראות המיילים ב-CRM
איזה חלק מהמיילים מגיע ונפתח
שרשרת המיילים ב-CRM נשלחת לא לפי לוח זמנים של תפוצה המונית, אלא לפי אירוע של שינוי שלב בעסקה — המייל מגיע בעוד העניין בדיאלוג חי, ונכנס לכרטיס של אותו איש קשר.
את יכולת המסירה קובעים שלושה דברים: דומיין שולח מאושר, היעדר שליחות פזורות על פני כל הבסיס, וטיפול תקין בהסרות מרשימת התפוצה. כשזה מוגדר, שיעור הנמסרים נשמר מעל 95%, ושיעור פתיחות המיילים בשרשרת גבוה פי כמה מאשר בתפוצה בודדת.
כמה פניות מגיעות לכדי עסקה
ב-Bitrix24 תשובת הלקוח אינה שוקעת בתיבה נפרדת: היא מקושרת לעסקה ומסירה את המשימה מהמנהל. מהירות התגובה לתשובה נמדדת בדקות, ולא בימים — ובזכות זה השיחה לא מתקררת, והמעבר בין השלבים מתועד בהיסטוריה, ולא מהזיכרון.
מכאן האפקט נראה על המשפך: פניות אוטומטיות מפסיקות להיתקע בין השלבים, כי כל מייל סוגר התנגדות מסוימת ודוחף לשלב הבא. כתוצאה מכך עולה שיעור הפניות שהגיעו לשלב העסקה, ולא רק מספר המיילים שנשלחו.
ומכאן המסקנה העיקרית: הערך אינו נובע מטקסט המייל כשלעצמו, אלא מהחיבור של המייל לשלב, לזמן התגובה ולאחראי.
תרחישים, מצבים ומגבלות של משפכי אימייל
בשיווק CRM המשפך מורכב משתי מכניקות שונות מיסודן. תרחיש אירועי נקשר לשינוי שלב או שדה של העסקה ושולח מייל בתגובה לפעולה. תפוצה המונית יוצאת לפי סגמנט של הבסיס ואינה יודעת דבר על שלבי העסקה.
שתיהן פועלות באותו פורטל ומשתמשות באותה תור שליחה, ולכן ערבוב שלהן בזרימה אחת ללא תנאי הפעלה ברורים — הוא המקור העיקרי לכפילויות ולמיילים שלא בזמן.
שרשראות אירועיות מול תפוצות המוניות
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| שרשרת ברכה חד-פעמית | פנייה ראשונה, 2-4 מיילים לפי טיימר | מופעלת פעם אחת לאיש קשר; עריכת הטקסט אינה מפעילה מחדש את מי שכבר בתהליך |
| תרחיש אירועי לפי שלבי העסקה | מכירה בשלבים, המייל קשור לפעולה | מגיב רק לאירוע מתועד; החזרת העסקה אחורה מפעילה את השלב שוב |
| תפוצה המונית לפי סגמנט של הבסיס | הכרזה, מבצע, עדכון לפי חתך שדות | אינה רואה שלבים והתכתבות; הסגמנט מחושב ברגע ההפעלה |
| החייאת אנשי קשר "רדומים" | אין פעילות מעבר לפרק זמן מוגדר | דורשת הסכמה מפורשת, אחרת עולות ההסרות והתלונות |
הבחירה נקבעת לא לפי מה ש"חזק יותר", אלא לפי היכן נמצא הסימן. אם המייל חייב לחפוף לפעולת הלקוח — רק שרשרת אירועית. אם צריך לעבור פעם אחת על חתך של הבסיס — תפוצה המונית.
מגבלות של תרחישים ומנויים טיפוסיים
תרחיש מופעל רק על אירוע שאכן מתועד בעסקה — תנאי שרירותי לפי שדה מחושב לא יפעיל אותו. לכן הסימן "המייל נשלח" נשמר בנפרד, והשלב אינו חוזר על עצמו כשהעסקה מוחזרת אחורה.
ההסכמה לתפוצה נמצאת בכרטיס איש הקשר, ולא בעסקה: בעת ייבוא הבסיס היא אינה מסומנת, והתרחיש רשמית שולח מייל, אך בפועל אוסף תלונות. הסרה בתפוצה המונית חייבת לכבות גם את השלבים האירועיים — אחרת השרשרת לפי שלבים ממשיכה לפגוע במי שכבר סירב.
כיצד אנחנו מטמיעים שרשרת מיילים: שלבי העבודה
סדר העבודות זהה לתרחיש חדש ולעיבוד מחדש של מה שכבר נשלח: תחילה בוחנים מה קיים, אחר כך מתכננים את הסכימה, ואז בונים ובודקים על אנשים אמיתיים. דילוג על כל שלב מוביל לכפילויות של מיילים, לשליחה לכתובות לא תקינות ולנפילה של מוניטין הדומיין — ולכן השלבים הולכים בקפדנות זה אחר זה.
ביקורת מיילים, בסיס ותרחישים קיימים
- מייצאים את בסיס אנשי הקשר ואת היסטוריית השליחות: מחפשים כתובות לא פעילות, כפילויות, מנויים חוזרים ותלונות על ספאם. כתובות כאלה נכנסות מיד לחריגים — כל מייל אליהן פוגע ביכולת המסירה של כל השאר.
- מפרקים תפוצות שכבר פועלות: לפי אילו אירועים הן מופעלות, באיזו תדירות והיכן הן מפריעות זו לזו. ממצא נפוץ — שלושה מיילים ביום אחד מתרחישים שונים.
- בודקים את דומיין השליחה: רשומות אימות, הפרדה של מיילים טרנזקציוניים והמוניים לתת-דומיינים שונים, קישור להסרה מהתפוצה בכל תבנית.
בדיקת התרחיש על סגמנט בדיקה
- בונים את סכימת התרחיש על הנייר: אירוע ההפעלה, תנאי ההסתעפות, ההשהיה בין המיילים, תנאי היציאה מהשרשרת בעת רכישה או הסרה.
- מכינים את המיילים: השתלת נתוני הלקוח, נושא, שורת תצוגה מקדימה, תגי מקור לאנליטיקה.
- מריצים את השרשרת על סגמנט בדיקה — עובדים ומדגם קטן של הבסיס האמיתי. בודקים הפעלה של כל שלב, הסתעפות, היעדר כפילויות ויציאה תקינה מהתרחיש.
- מוסרים לעבודה: סכימה, טקסטים, נוהל עריכות ואחראי על השינויים. מכאן התרחיש חי בלעדינו, והמדדים של כל שלב נראים בפאנל.
הגדרות, סגמנטים ונוהלים שאנחנו מוסרים
הגדרת משפכי אימייל ב-Bitrix24 אינה מסתיימת בהפעלת התפוצה הראשונה, אלא במסירת מתאר עבודה לצוות. להלן מה שנשאר בחשבון שלכם לאחר המסירה: בלי סיכומים בעל פה ובלי הגדרות "מהזיכרון בממשק".
סכימת התרחיש ומפת הסגמנטים
- סכימת התרחיש: טריגרים, תנאי הסתעפות, השהיות בין המיילים ונקודות יציאה — גם במסמך וגם ברובוט עצמו.
- מפת הסגמנטים: אילו שדות של איש הקשר ושל העסקה יוצרים את הסגמנט, לפי איזה כלל הוא מחושב מחדש, ומה קורה בעת שינוי סטטוס.
- תבניות מייל: נושא, פריהדר, גרסה טקסטואלית וגרסה מעוצבת, השתלות נתונים, תגים לאנליטיקה — עם הערות מה אפשר לשנות בלי סיכון.
- כללי טיפול בתשובות: כיצד התשובה חוזרת ל-CRM, למי היא מוקצית, כמה זמן ממתינה לתגובה, כיצד נחסמות תשובות אוטומטיות.
נוהל עבודה עם סירובים ותלונות
- הסרות ותלונות: תרחיש נפרד, הוצאת איש הקשר מהסגמנטים הפעילים, תיעוד הסיבה, עצירת שליחה בעת עלייה בתלונות.
- מיילים שלא נמסרו: ניתוח סירובים לפי סוגים, ניקוי כתובות, כלל ניסיון חוזר.
- תיעוד התפוצות: דרכון התרחיש, היסטוריית עריכות, צ'ק-ליסט לפני הפעלה, נוהל חזרה לגרסה קודמת.
- הנחיות למשווק: כיצד להוסיף מייל או סגמנט בעצמו ובאילו מקרים נדרש מפתח.
הסכימה ומפת הסגמנטים הופכות לנקודת האמת בכל עיבוד מחדש: עובד חדש מוכנס למתאר בלי חקירות ובלי שחזור ההיסטוריה מהתכתובת.
מקרה בוחן: כיצד השרשרת הפסיקה לאבד פניות בכניסה
מחלקת המכירות של מפיץ ניהלה עסקאות ב-Bitrix24, אך הכניסה למשפך האימייל נשארה ידנית: המנהל הרכיב את המייל בעצמו, תשובת הלקוח נפלה לתיבה משותפת, והמשך הדברים היה תלוי בשאלה אם יחזור לדיאלוג הזה.
מה היה לפני ההטמעה
מדידות לאורך חודש הראו שעד 40% מהמיילים של המגע השני והשלישי לא יצאו כלל — המנהל סגר עסקה פעילה ולא חזר לרשימה. תשובות הלקוחות אבדו בין התיקיות: תועדו כ-120 פניות, חלקן צפו רק בשיחה הבאה, לעיתים כעבור שבועיים. לשרשרת לא היה מצב אחיד, ולכן פניות שאבדו לא באו לידי ביטוי לא בדוחות ולא בעבודת המנהל.
מה נהיה אחרי
הרכיבו תרחיש בשיווק CRM: הפעלה לפי האירוע "נוצרה עסקה", תבניות מאושרות מראש, השהיה אוטומטית בעת תשובה וחזרה לרצף אם הלקוח שותק. שיעור המיילים הנמסרים עלה ל-98–99%, והשליחה הידנית יצאה מהתהליך.
הטיפול בתשובות הלקוחות הפסיק להיות תלוי בזיכרון העובד: המייל מקושר לכרטיס, מציב משימה למנהל ומעביר את העסקה לשלב הבא.
מספר הפניות שתועדו עלה בערך פי שלושה — הלקוחות לא התחילו לכתוב יותר, פשוט התשובות הפסיקו ללכת לאיבוד. זמן התגובה הממוצע למייל התקצר מיממה לכמה שעות.
במה שרשרת אירועית נבדלת מתפוצה המונית?
תפוצה המונית יוצאת לפי לוח זמנים: הסגמנט נאסף מראש, המיילים יוצאים לכל הבסיס בשעה שנקבעה, ותגובת הנמען לשלב הבא אינה משפיעה כלל. שרשרת אירועית בנויה אחרת — אותה מפעילה פעולה של הלקוח: טופס שנשלח, הצעה שנפתחה, חשבונית שהתבקשה.
כל ההבדל בין הגישות הוא במי שקובע את הקצב: בתפוצה לפי לוח זמנים — המשווק, בהפעלה לפי אירוע — הלקוח עצמו.
מקור הפעלה שני — שינוי שלב של העסקה. לוגיקת המשפך מתארת את מסע הלקוח כרצף של שלבים, והמעבר ביניהם משנה את מצב הכרטיס. במשפכי האימייל של Bitrix24 השרשרת נרשמת למעבר מסוים: העסקה עברה לאישור — יוצא מייל עם התנאים, עברה למושהים — יוצא אחר. המייל מגיע כשהשאלה פתוחה אצל הלקוח, ולא כשלעורך התפנה חלון.
מכאן ההבדל בצפיות. שליחה המונית נותנת סטטיסטיקה מטושטשת: הפתיחות תלויות ביום בשבוע ובהצלחת הנושא, והפניות אובדות בזרם הכללי. שרשרת אירועית קשורה לשלב מסוים, ולכן רואים היכן בדיוק הלקוח נשר — אחרי איזה מייל ובאיזו השהיה.
מבחינה טכנית השרשרת מורכבת מתנאים, השהיות והסתעפויות: לא פתח את המייל בתוך יממה — יוצאת תזכורת, פתח — השלב מדולג. כניסה חוזרת לשרשרת נחסמת, כדי שבהחזרת שלב אחורה הלקוח לא יקבל את אותו מייל פעמיים.
תשובה קצרה לשאלה: את לוח הזמנים קובע המשווק, את האירוע קובע הלקוח — ולכן המשפך האירועי נותן פניות צפויות.
ספקות טכניים: דומיין, יכולת מסירה, סגמנטים
יכולת מסירה ושלמות הנתונים נבדקות לפני התפוצה הראשונה: כל עוד מוניטין הדומיין לא מאושר, המיילים יוצאים לספאם, והמשפך מאבד אנשי קשר כבר בכניסה. להלן השאלות הנפוצות ביותר שמהנדסים ומנהלים שואלים לפני ההתחלה.
מה עם מוניטין הדומיין, אם לא היו תפוצות קודם?
את השליחה מבצעים מתת-דומיין נפרד, כדי שמוניטין הדומיין הראשי לא יתערבב עם מיילים המוניים. רשומות SPF ו-DKIM ומדיניות DMARC מוגדרות מראש, והנפח גדל בהדרגה — תיבות הדואר מספיקות לסמן את השולח כמוכר.
האם המיילים עלולים להיכפל בהפעלה חוזרת של התרחיש?
כל הצבה של מייל מסומנת בתג של שלב ושל איש קשר, ולכן הפעלה חוזרת של הכלל או התערבות ידנית אינה יוצרת מייל שני. אם התקלה אירעה בין השליחה לרישום הסטטוס, התרחיש משווה מול היומן ומדלג על מה שכבר נמסר.
מה יקרה לתבניות המייל הקיימות?
את התבניות מעבירים יחד עם העיצוב ומשתני ההשתלה, ואחר כך בודקים ששדות ההתאמה האישית מתמלאים מכרטיס איש הקשר, ושהקישורים וההסרה מובילים לכתובות פעילות.
כיצד מתנהג המשפך אם שער הדואר אינו זמין?
המייל נשאר בתור ויוצא לפי לוח החזרות, ולא הולך לאיבוד. איש הקשר אינו נופל מהמשפך: השלב מסומן כלא הושלם, ולאחר השחזור התרחיש ממשיך מאותה נקודה.
כיצד נבדקות ההגדרות לפני ההפעלה?
עוברים צ'ק-ליסט: חתימות הדומיין, שליחת בדיקה, פירוק הסגמנטים, תנאי היציאה מהמשפך, יומן השגיאות. את השליחות הראשונות בודקים ידנית ומתקנים הגדרות לפני התפוצה ההמונית.
נדון במשימה שלכם ונחזור עם תוכנית
כדי שמשפכי האימייל ב-Bitrix24 יעבדו לא כתפוצה לפי לוח זמנים, אלא כשרשרת מנוהלת, אנחנו צריכים לראות את הנתונים והכללים שלכם. ספרו לנו מהיכן מגיעות הפניות, אילו פעולות ב-CRM אמורות להחליף שלב בתרחיש ומה נחשב לסימן לעצור את המיילים.
מה נדרש מכם להתחלה:
- הרכב הנתונים: אילו שדות בכרטיסי הפניות והעסקאות באמת מתמלאים, היכן שדות חובה נשארים ריקים, האם יש כפילויות של אנשי קשר.
- הרשאות גישה: פורטל בדיקה או משפך נפרד, חשבון עם הרשאות לשיווק CRM, גישה לסגמנטים, לתבניות המייל ולדיווח.
- הסכמות והסרות: כיצד מתעדים הסכמה לתפוצה, כיצד מטפלים בסירובים, האם נדרשת היסטוריית התכתובת בתוך הכרטיס.
- סדרי עדיפויות בתרחישים: אילו שרשראות מפעילים ראשונות — ברכה, חימום, החזרת רדומים — ובאיזה סדר.
- ערוצים: דומיין הדואר המחובר, מגבלות על נפח השליחה, חיבור לטפסי האתר ולטלפוניה, אם המייל צריך לצאת לאחר שיחה.
- קריטריוני מוכנות: אילו מדדים נחשבים לתוצאה — שיעור הנמסרים, פתיחות, מעברים לשלב הבא במשפך, הסרות.
מכאן מורכב סדר העבודות: תחילה מנקים ומסמנים את הנתונים, אחר כך בונים את הטריגרים, לאחר מכן בודקים את השרשרת על סגמנט בדיקה ורק אחרי זה מפעילים אותה על הזרם האמיתי.
תארו את המשימה — מה כבר מוגדר, אילו תרחישים נדרשים ואילו אירועים אמורים להפעיל אותם. נחזור עם הערכת זמנים ותוכנית הטמעה, שבה מפורט שלב אחר שלב איזה תרחיש ומתי מוציאים לעבודה.