הגדרת רצפי אימייל ב-Bitrix24: אוטומציה של שיווק CRM

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

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

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

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

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

מה משתנה אחרי ההטמעה: זמן, שיעור המסירה, החזרות

הימים הראשונים: תרחיש במקום בקשה לפיתוח

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

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

שיעור האימיילים הנמסרים עולה הודות לדומיין שולח מוגדר, חתימה, טיפול נכון בהסרות מרשימת התפוצה וחימום הדרגתי של המוניטין: 97–99% לעומת 80–85% בשליחה מתיבה משותפת. האימיילים מגיעים אל «הדואר הנכנס» ולא אל «ספאם» — בלי זה כל השרשרת מאבדת את משמעותה.

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

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

מצבי שליחה ב-Битрикс24: השוואה של ארבע גישות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כיצד סודרו התרחישים במקום תזכורות ידניות

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

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

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

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

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

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

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

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

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

שאלות טכניות נפוצות לפני ההטמעה

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

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

מה יקרה אם הלקוח יגיב באמצע הסדרה?

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

כיצד נפתרת סוגיית המסירה של המיילים?

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

האם זה מעמיס מאוד על העובדים?

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

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

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

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

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

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

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

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