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

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

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

שאלות נפוצות

תבניות דיוור email ב-Bitrix24: היכן אובדים מכתבים

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

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

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

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

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

אפקט מדיד: מה נותנת מערכת מכתבים אחידה

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

מהירות הוצאת תבנית

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

שיעור המכתבים שנמסרו

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

סוג החזרות שנפתר

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

זמן השבתה ללא בנייה מחדש ידנית

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

אפשרויות הרכבת תבניות: עורך, פריסה, מערכת חיצונית

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

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

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

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

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

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

מה נשאר אצלכם: קונפיגורציה, תבניות, תקנונים

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

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

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

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

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

מה היה לפני השינוי

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

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

מה שינינו ומה התקבל

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

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

לאחר מכן הוצאת מכתב אורכת 3–4 שעות במקום יומיים-שלושה, שיעור המכתבים שנמסרו עלה ל-97–98%, החזרות קשות ירדו מ-11% לרמה נמוכה מ-1%, ותלונות על דואר זבל הפסיקו להגיע בכמויות לאחר כל שליחה המונית.

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

מה לעשות אם מכתבים נשלחים ממספר מערכות

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

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

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

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

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

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

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

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

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

מכתבים נופלים לדואר זבל — מה לעשות עם זה?

יכולת המסירה תלויה לא בטקסט של המכתב, אלא במוניטין של הדומיין ובתקינות רשומות האימות — SPF, DKIM ו-DMARC.

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

כיצד לעקוב אחר פתיחות ומעברים?

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

יש לנו תבניות מוכנות בשירות אחר — תעבירו אותן?

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

נדון במשימה: נשלח הערכה ותוכנית עבודה

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

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

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

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