הגדרת דיוור ב-Bitrix24: לאן נעלמות הודעות הדוא״ל
דיוור המוני לבסיס הנתונים נשלח לספאם או נכנס לתור שליחה — ומבחוץ זה נראה כמו «הודעות לא מגיעות לנמען». למחלקת המכירות נראה שהלקוחות פשוט לא עונים, אבל בפועל שרת הקבלה דוחה את ההודעות: חלק מהכתובות מחזירות סירוב קשיח, והשאר נוחתות בשקט בתיקיית «ספאם» ולא נפתחות לעולם. מחיר הטעות — בסיס נתונים שרוף ומוניטין דומיין שאחר כך משקמים במשך חודשים.
הסיבה כמעט תמיד נמצאת בצירוף של ארבעה דברים. הדומיין לא מאומת: ברשומות SPF ו-DKIM חסרים הערכים הנדרשים, ולכן הנמען לא יכול לוודא שההודעה אכן נשלחה על ידכם. הדיוור יוצא מתיבות אישיות של מנהלים, בלי פילוחים ובלי התחשבות במי שכבר ביטל הרשמה. וקצב השליחה לא הוגבל על ידי איש — הצד המקבל רואה פרץ של הודעות זהות וחוסם את הזרימה כולה.
הדבר הראשון שכדאי להסתכל עליו הוא יומן שליחת הדואר ב-Bitrix24. שם, עבור כל הודעה, רואים אם היא התקבלה, הועברה לתור או נדחתה, עם איזה קוד תגובה ואיזו כתובת בדיוק החזירה סירוב.
זה מסיר את הניחושים: במקום «הדיוור לא עובד» מופיעה רשימה של סיבות קונקרטיות — מפורמט כתובת שגוי ועד הגבלה בצד ספק הדואר.
בשלב הבא נפרט איך זה נסגר: מאמתים את הדומיין, מגדירים תרחישי דואר ב-CRM, מפצלים את בסיס הנתונים לפי פעילות ומציבים מגבלת קצב. יכולת המסירה של ההודעות מפסיקה להיות תלויה במי ומתי לחץ על כפתור השליחה.
מה נותנת שליחת דואר מסודרת: כיסוי, תגובה, מוניטין
התוצאה של שליחה נכונה נראית לא בהגדרות, אלא בדוחות הקמפיינים. הדבר הראשון שמשתנה הוא שיעור ההודעות שנמסרו: דומיין השליחה מאומת וחתום, זרימות המוניות וזרימות שירותיות מופרדות, וההודעות מפסיקות להישלח לספאם ולכרטיסיית הפרומו. האפקט מורגש כבר באלף הכתובות הראשון וממשיך להצטבר.
המדד השני הוא אחוז הביטולים. הוא יורד כשהדיוור יוצא לפי פילוחי פעילות ועניין, ולא לכל בסיס הנתונים בבת אחת: הלקוח מבטל את ההרשמה לא מהחברה, אלא מזרימה לא רלוונטית. תדירות שליחה הוגנת מחזקת את אותו הדבר — התגובה להודעות עולה, והרוגז לא.
השלישי הוא מהירות התגובה של הלקוח. כשההודעות על פנייה, חשבונית, משלוח או רכישה שלא הושלמה נשלחות אוטומטית וברגע הנכון, הלקוח מגיב תוך שעה, ולא אחרי שיחת טלפון מהמנהל. זה מקצר ישירות את מחזור העסקה.
הרביעי הוא העומס על המנהלים. תשובות אוטומטיות, שרשראות חימום והנחיות ברורות מסירות שאלות טיפוסיות, והזמן מוקדש למי שמוכן לדון בתנאים. בדוחות זה נראה כגידול בפניות איכותיות עם אותו מספר עובדים.
כל המדדים האלה נשענים על המוניטין של דומיין השולח: הוא נבנה לאט, אבל הולך לאיבוד כבר בתלונות הראשונות על ספאם ובבסיס נתונים «מלא זבל». אפשר לבדוק את האפקט בתקופת דיווח אחת — השוו את שיעור המסירה, הביטולים, הזמן עד לתגובה ומספר הפניות למנהל לפני ואחרי ההגדרה.
פילוחים ומגבלות דיוור: איך לא להיחסם
דיוור המוני לבסיס הנתונים והודעות טרנזקציוניות עם חשבונית עוברים דרך אותו דומיין, אבל חיים לפי כללים שונים. אם מערבבים אותם בזרימה אחת, תלונות על מהדורה פרסומית פוגעות במוניטין הדומיין, והלקוח מפסיק לקבל חשבונית — סוג הסירוב היקר ביותר, שאחר כך מחפשים אותו שבועות.
את המצב בוחרים לפי המשימה, לא לפי נוחות הממשק:
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| שליחה טריגרית (רובוטים ותהליכים עסקיים בפורטל) | הודעה לפי אירוע: ליד חדש, שינוי שלב בעסקה, תזכורת לתשלום | רק לפי אירוע, אי אפשר לייצא פילוח שרירותי, הקצב נקבע על ידי פעולות העובדים |
| הודעות טרנזקציוניות עם חשבונית, אישור, גישה | התראה בעקבות פעולה ממערכת הנהלת החשבונות | לא לשיווק, נדרש תבנית וקישור למסמך, ביטול הרשמה לא נכלל |
| דיוור המוני לבסיס הנתונים דרך שירות מובנה | פילוח של כמה אלפי כתובות, מהדורות קבועות | מגבלת הודעות בשעה לפורטל, נדרש חימום ופריסה בזמן |
| דיוור המוני דרך שירות דואר חיצוני | בסיס גדול, נדרש דומיין שליחה נפרד וסטטיסטיקה לפי דומייני נמענים | סנכרון בסיס הנתונים, הגדרת אימות תת-דומיין, המגבלות תלויות בתוכנית הנבחרת |
קצב שליחת ההודעות הוא פרמטר שלרוב מתעלמים ממנו. התחלה חדה על כל בסיס הנתונים יוצרת פרץ תלונות, והספקים מתחילים לקצץ במסירה לכל הדומיין, כולל חשבוניות.
לכן המהדורות יוצאות בגלים: קודם הפילוחים הפעילים ביותר, כמה מאות כתובות בכל פעם, עם הפסקה בין גלים, וביטולי הרשמה וסירובים קשיחים מוצאים מהבסיס מיד, אחרת הם מצטברים ומקלקלים את הסטטיסטיקה של המהדורות הבאות.
אימות הדומיין מוגדר בשני המסלולים — בלי חתימות מאומתות חלק מההודעות נשלחות לספאם עוד לפני הערכת התוכן. שירות חיצוני ניקח כשבסיס הנתונים ותדירות המהדורות עוברים את מגבלות הפורטל; את המובנה נשאיר לטריגרים ולפילוחים מתונים. ניתוח המשימה יראה איזה מצב מתאים בדיוק לכם.
שלבי העבודה: מביקורת הדומיין ועד מסירת נהלים
הגדרת דיוור ב-Bitrix24 מתחילה לא מתבנית הודעה, אלא מניתוח האופן שבו הדואר יוצא כעת. כברירת מחדל הסוכן שולח דרך תיבת דואר ארגונית, ובהיקף של כמה מאות הודעות ביום הספקים מתחילים לקצץ בחיבורים או להעביר הודעות לספאם. להלן סדר העבודות, שבו כל שלב נשען על הנתונים של השלב הקודם.
- ביקורת דומיין וחתימות הודעות. בודקים רשומות SPF, DKIM ו-DMARC, DNS הפוך, היסטוריית מוניטין הדומיין ושיעור הנפילה הנוכחי לספאם. מתעדים מה חסר לשליחה לגיטימית.
- תרשים השליחה. מנתחים מה יוצא דרך שירות דואר ומה דרך שרת ארגוני, איך מופרדות זרימות טרנזקציוניות והמוניות, לאילו דומיינים מתבצע הדיוור.
- חיבור שירות דואר. מאמתים את הדומיין אצל הספק, רושמים את הרשומות, קובעים מגבלות לפי זרימות וכלל התנהגות בעת כשל שליחה.
- הרכבת פילוחים. מסמנים את בסיס הנתונים לפי פעילות, מקור וותק ההסכמה, כדי שהודעות המוניות לא יישלחו למי שלא פותח אותן כבר זמן רב.
- בדיקה על בסיס נתונים לניסיון. מריצים הודעות בתיבות של ספקים שונים: בודקים מסירה, פריסה בממשקים, פעולת קישור ביטול ההרשמה והצבת שדות.
- מסירת נהלים. מוסרים הוראה: איך להוסיף פילוח, היכן לראות סטטיסטיקת סירובים ומה לעשות כששיעור המסירה יורד.
מה נשאר אצלכם: תרשימים, דומיינים, תבניות, נהלים
אנחנו לא משאירים את התוצאה בהתכתבות: לצוות שלכם נשארת ערכת עבודה של נכסים, שלפיה אפשר להפעיל, לבדוק ולפתח את הדיוור בלעדינו. להלן מה בדיוק מוסרים ואיך כל מסמך משמש בעבודה היומיומית.
- מפת תרחישי שליחה — טבלה «אירוע → הודעה → פילוח → אחראי»: הרשמה, עגלה נטושה, שינוי סטטוס עסקה, הפעלה מחדש. לפיה רואים מיד היכן משוכפלים טריגרים ולאן תיכנס הודעה חדשה.
- דומיין מוגדר ורשומות — SPF, DKIM ומדיניות DMARC בצורה מסוכמת, תת-דומיין נפרד להודעות המוניות, כדי שמוניטין הדומיין הראשי לא יהיה תלוי בדיוור, בתוספת הוראות בדיקה.
- כללי פילוח בסיס הנתונים — לפי אילו שדות מחלקים אנשי קשר, באיזו תדירות מרכיבים מחדש פילוחים, מה עושים עם כתובות לא פעילות וביטולי הרשמה. הכללים חיים בתוך Bitrix24, ולא כקובץ נפרד.
- תבניות הודעות — סט אחד עם פריסת בלוקים: כותרת, גוף, כותרת משפטית תחתונה, משתני הצבה. מהדורה חדשה נבנית מבלוקים, בלי לגעת בפריסה.
- נוהל לבסיס אנשי קשר — תדירות ניקוי כתובות לא תקינות וסירובים קשיחים, סדר עדכון הסכמה להרשמה, מי מטפל במקרים שנויים במחלוקת ובאיזה מועד.
- הוראה למנהלים — תזכורת קצרה: איך לשלוח הודעה ידנית, איך לבדוק שאיש הקשר לא ברשימת חסימה, מה לעשות בתלונה על ספאם והיכן לתעד אותה.
נהלים אנחנו כותבים בהתאם לתהליך שלכם, ולא «לפי ספר לימוד»: מתאמים עם השיווק, התמיכה והמכירות, כדי שהמסמכים לא יסתרו את אופן העבודה בפועל.
מקרה בוחן: דיוור לבסיס הנתונים בלי חסימות וניקוי ידני
לקוח שלח מבצעים ורצפים טריגריים מדומיין אחד ומזרימה אחת: בסיס המנויים הצטבר במשך שנים והגיע לכ-180 אלף כתובות. עד שלב הניתוח המסירה עמדה על 88%, ביטולי הרשמה ותלונות — על 2%, והכנת דיוור אחד ארכה 5–6 שעות: הפילוחים הורכבו בייצוא לטבלה, כפילויות וכתובות לא תקינות נוקו ידנית.
הסיבות התבררו כשלוש: הדומיין לא היה מאומת, הודעות טרנזקציוניות והמוניות יצאו מאותה כתובת שליחה, והמערכת לא הגיבה לתלונות ולהחזרות. הפרדנו את הזרימות לפי תת-דומיינים, הגדרנו SPF, DKIM ו-DMARC, הגבלנו את מהירות השליחה בתקופת החימום והפעלנו השבתה אוטומטית של כתובת לאחר החזרה קשיחה.
את הפילוחים ב-Bitrix24 הרכבנו לפי פעילויות — פתיחות, מעברים, תאריך ההזמנה האחרונה — במקום ייצואים קבועים.
| מדד | לפני | אחרי |
|---|---|---|
| שיעור ההודעות שנמסרו | 88% | 98.7% |
| שיעור התלונות והביטולים | 2% | 0.4% |
| זמן הכנה לדיוור | 5–6 שעות | 40 דקות |
| פעולות ידניות לפני שליחה | ייצוא, בדיקה, ניקוי ידני של בסיס הנתונים | לא נדרשות |
| סוג הסירובים | קשיחים: תיבות לא קיימות, חסימות | זמניים: תיבה מלאה |
סירובים קשיחים נעלמו כסוג — נשארו רק זמניים, שאותם סוגרת ניסיון חוזר. הודעות הפסיקו להגיע למי שלא קורא אותן, ולכן ביטולי ההרשמה ירדו פי חמישה, ומוניטין הדומיין הפסיק לרדת אחרי כל שליחה גדולה. הכנת הדיוור התקצרה מחצי יום עבודה ל-40 דקות, והמשווק כבר לא מעביר פילוחים ידנית.
מה לעשות אם ההודעות כבר נשלחות לספאם או שהבסיס לא מחומם
קודם מפרידים בין שתי אבחנות: אימות הדומיין והמוניטין שלו. אם חתימות ההודעה מוגדרות ואזור ה-DNS ההפוך תואם לשולח, אבל ההודעות נופלות לספאם — הסיבה אינה טכנית, אלא בתגובת הנמענים: תלונות, מחיקות בלי פתיחה וכתובות מלכודת בתוך הבסיס. אז העבודה מתנהלת בסדר ההפוך: קודם ניקוי וחימום, אחר כך החזרת ההיקפים.
ניקוי כתובות לא פעילות הוא רשימת חסימה, לא מחיקה. אליה נכנסים סירובים קשיחים, תלונות על ספאם, תיבות תפקידיות כמו info@ וכפילויות. אנשי קשר בלי פתיחות במשך 90–180 יום לא זורקים, אלא מעבירים לפילוח נפרד להחזרת קהל ופונים אליהם בסדרת הודעות קצרה.
חימום בסיס אנשי הקשר נבנה מהליבה הפעילה: ראשונים מקבלים מי שפתח הודעות בחודש האחרון, אחר כך מחברים פילוח של עד 90 יום, ורק לאחר מכן — את השאר. ההיקפים גדלים במנות, עם בקרה של ביטולי הרשמה, תלונות והגעה ל«דואר נכנס» בתיבות של ספקים שונים.
החזרה מדורגת לשליחה מוחזקת לפי ספי מדידה: תלונות — עשיריות האחוז, ביטולי הרשמה — בטווח של כמה אחוזים, סירובים — קרוב לאפס. ברגע שהמדד יוצא מהמסגרת, חוזרים אחורה להיקף הקודם ונותנים לבסיס זמן להתייצב. ב-Bitrix24 הקצב נקבע לפי מגבלות שליחה ופילוחים, ולכן הירידה נראית בכל שלב, ולא רק אחרי חסימה בפועל.
בנפרד מפרידים בין זרימות טרנזקציוניות לזרימות שיווקיות: תת-דומיינים ושולחים שונים, כדי שפרץ תלונות על דיוור לא יגרור אחריו התראות שירות.
ספקות טכניים נפוצים לפני ההתחלה
הספקות לפני ההתחלה הם כמעט תמיד אותם ספקות: האם המגבלות יספיקו, אפשר לכתוב מהדומיין שלכם, מה עושים עם ביטולי הרשמה ואילו הרשאות יידרשו. להלן תשובות קצרות, כדי לא לברר את זה כבר במהלך ההגדרה.
האם המגבלות על שליחת הודעות יספיקו?
בתכנון נכון — כן. לפורטל בענן יש מגבלה יומית: כשממצים אותה, ההודעות נכנסות לתור או לא נשלחות בכלל. אנחנו מחשבים את ההיקף לפי פילוחים, פורסים את השליחה על פני זמן, ובבסיסים גדולים מחברים שירות שליחה חיצוני — הפורטל נשאר הממשק, ואת הדיוור מבצעת תשתית נפרדת.
אפשר לבצע דיוור מהדומיין שלכם?
כן, וזו האפשרות הנכונה. הדומיין נשאר שלכם, אנחנו רושמים בו רשומות שירות — אימות השולח וחתימת ההודעות — בודקים את הדומיין ורק אחר כך מתחילים את השליחה. בלי הרשומות האלה הודעות המוניות נשלחות לספאם או נדחות על ידי שרתי הדואר של הנמען.
איך מטפלים בביטולי הרשמה?
קישור ביטול ההרשמה מוצב בהודעה אוטומטית, והעובדה עצמה נכנסת לכרטיס איש הקשר. מהפילוח הכתובת מוחרגת מיד, ושליחה חוזרת אליה כבר לא תצא. אין צורך לנהל רשימות חסימה ידנית בנפרד.
אילו הרשאות נדרשות מהצד שלכם?
הרשאות מנהל בפורטל או תפקיד נפרד עם גישה לדיוור, גישה לפאנל הדומיין לעריכת רשומות שירות ותיבת בדיקה לבדיקת מסירה. ההרשאות ניתנות לתקופת העבודה ונשללות לאחר המסירה.
האם הדיוור קשור למשימות ולעסקאות?
כן. הודעות מופעלות לפי שלבי עסקה ולפי משימות: שינוי סטטוס מפעיל את התרחיש המתאים. כל ההתכתבות נשמרת בכרטיס — המנהל רואה מה ומתי הלקוח קיבל.
נדון במשימה: מה לשלוח ובמה נתחיל
כדי לחזור עם הערכה ותוכנית עבודה, ולא עם מחשבות כלליות, אנחנו צריכים נתוני פתיחה בשני מסלולים — דואר ובסיס אנשי קשר. להלן רשימה מינימלית: בדרך כלל היא מסירה חצי מהשאלות עוד לפני שיחה.
- דומיינים וכתובות שמהם מתבצע או מתוכנן להתבצע דיוור, כולל תת-דומיינים לשליחות המוניות.
- מצב רשומות SPF, DKIM ו-DMARC: מה כבר פורסם, מי מנהל את האזור ויכול לבצע עריכות.
- היקף בסיס הנתונים, מקור אנשי הקשר (CRM, טפסי אינטרנט, ייצואים) ובאיזו תדירות הוא מתעדכן.
- עקרונות הפילוח: לפי אילו מאפיינים הקהל מחולק כעת ומה קורה לו בהמשך.
- סטטיסטיקת השליחות האחרונות: שיעור אי-המסירה, תלונות על ספאם, ביטולי הרשמה, פניות חוזרות.
- תוכנית התעריפים הפעילה ומגבלות יומיות על היקף השליחה.
- מי מצד הלקוח מאשר את הטקסטים ואחראי למסירת ההרשאות.
הלאה הסדר פשוט: דנים במשימה, מנתחים את נתוני הפתיחה וחוזרים עם הערכה ותוכנית עבודה — מה סוגרים קודם, ומה אפשר לדחות בשקט. לאחר אישור — מסירת הרשאות, הגדרה על דומיין אחד ופילוח ניסיון, בדיקת המסירה והתגובות, ואז פריסה לשאר הזרימות.