הגדרת תבניות דיוור בדואר אלקטרוני של Bitrix24

תבניות דיוור אימייל של Битрикс24 שלא מגיעות אל הנמען

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

תבנית מכתב ב-Битрикс24 נבנית בדרך כלל מבלוקים של בונה התבניות, ושם בדיוק מופיעים הפגמים הראשונים.

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

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

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

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

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

יכולת מסירה, סגנון אחיד ומהירות הוצאה של מכתבים

ב-Битрикс24 תבנית מכתב היא לא רק פריסה, אלא צירוף: דומיין שולח, נושא ושורת תצוגה מקדימה, שדות הצבה, סט בלוקים וכללי אישור.

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

מה בודקים ומה משתנה בכל סעיף:

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

דרכים להרכבת מכתבים: השוואה של גישות ומגבלות

בחירת הדרך נקבעת לא לפי טעם, אלא לפי מי יערוך את התבנית אחרי ההשקה וכמה קריטית תצוגה זהה בתוכנות דואר שונות. ב-Битрикс24 יש לכך ארבע סכמות עבודה, וכל אחת סוגרת סוג אחר של משימות.

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

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

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

סדר העבודה: מניתוח המכתבים ועד מסירת הנהלים

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

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

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

מה הלקוח מקבל לידיו: תבניות, סכמות, נהלים

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

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

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

מקרה בוחן: איך הדיוור הפסיק ליפול לספאם ולהישבר

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

תבניות דיוור אימייל ב-Битрикс24 נבנו ידנית לכל מהדורה: נושא מתוך הצבות, פריסת טבלאות בלי גרסת טקסט, ושורת התצוגה המקדימה נחתכה באמצע. שיעור המכתבים שלא נפתחו עמד על כמחצית מהרשימה, ההסרות מהרשימה גדלו ממהדורה למהדורה, וחלק מהכתובות קיבלו מכתב בלי תמונות.

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

אחרי: מסירה צפויה והוצאה לאור בשעות

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

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

מה לעשות אם הדיוור כבר עובר דרך שירות חיצוני

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

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

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

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

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

ספקות טכניים: נמענים, מצב כהה, הסרות מהרשימה

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

איך התבנית מתנהגת באפליקציות המובייל?

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

הסרות מהרשימה — איך הן קשורות למאגר?

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

דומיין השולח — מה צריך להגדיר?

רשומות אימות הדומיין (SPF, DKIM, DMARC) מוגדרות בצד ה-DNS. מצד התבנית אנחנו אחראים לכתובת השולח ולכותרת התחתונה: הן חייבות להתאים לדומיין האמיתי, אחרת המכתב נופל לספאם או ללשונית הקידום.

מה נכלל בבדיקה לפני השליחה?

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

נדבר על הדיוור: ננתח את התבניות ונחזור עם תוכנית

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

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

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

תארו את המשימה בשתיים-שלוש שורות וצרפו את מה שיש מהרשימה — נחזור עם הערכה ותוכנית.