דיוורים טריגריים ב-Bitrix24: היכן נשברת השרשרת
דיוורים טריגריים ב-Bitrix24 מתוכננים כחלק ממשפך: אירוע בכרטיס משנה שלב, השלב מפעיל מכתבים אוטומטיים לפי אירוע. כשהתרשים על הנייר, הכל מסתדר. בזרימה חיה של עסקאות השרשרת נשברת במקומות שלא נראים בבונה הרובוטים — והלקוח לא מקבל לא מכתב ולא שיחה.
צוואר הבקבוק הראשון — תנאי מעבר סטטוס שנחשבים כלא סגורים. הכלל ממתין לשדה עסקה מלא או לאישור מהלקוח, אך בפועל לא יכול לפעול, ותסריט ההתראות פשוט נשאר במצב המתנה.
השני — שדות ריקים ולא סטנדרטיים בכרטיס: ההחלפה בתבנית המכתב לוקחת ערך ממאפיין שלא קיים, והשליחה נדחית או יוצאת עם שורות ריקות.
לאחר מכן מתערבת העבודה הידנית. המנהל מעביר את העסקה לשלב הבא דרך הרשימה, תוך דילוג על הטופס, — חלק מהכללים לא פועלים, וחלק מופעלים פעמיים. כשכמה תסריטים חלים על שלב אחד, כללים מתנגשים משתיקים זה את זה: המכתב הראשון יוצא, השני כבר לא עובר את בדיקת התנאים.
זה מסתכם בכך שצוואר בקבוק במשפך המכירות נוצר עוד לפני השיחה הראשונה עם המנהל. לקוח שהשאיר פנייה ממתין לאישור יום-יומיים, מתקרר או עובר למי שהגיב מהר יותר. מחלקת המכירות לומדת על הבעיה מהלקוח עצמו, ולא מהמערכת, ומבזבזת זמן על מכתבי השלמה ידניים במקום על עסקאות.
להלן נבחן כיצד זה נסגר: היכן לראות את יומן השליחות, כיצד לבדוק את תנאי המעבר וכיצד להפריד תסריטי התראות בין שלבים, כדי שמכתבים לא יישלחו פעמיים ולא יאבדו.
מה נותנת אוטומציה של מכתבים לפי אירועים בעסקאות
תזכורות ידניות ללקוחות נשענות על הזיכרון של המנהל: כל עוד יש עשרות עסקאות, זה עובד, לאחר מכן חלק מהשלבים פשוט לא מגיעים לנמען.
אוטומציה של מכתבים לפי אירועים ב-Bitrix24 מסירה את התלות הזו — המכתב יוצא עם שינוי השלב, הוצאת חשבונית, תגובת הלקוח או הפסקה בהתכתבות, ולא לפי שארית תשומת הלב של המבצע.
מהירות התגובה של המנהל מתחילה להימדד לפי הגדרה, ולא לפי המשמעת של המחלקה: במצב ידני המגע הראשון אורך בין כמה שעות ליממה, בעבודה לפי אירועים — דקות. התגובה לפעולת הלקוח מגיעה כשהעניין עוד חי, וזה נראה מיד בשיעור התגובות למכתב הראשון.
שיעור הפניות האבודות יורד מסיבה אחרת: האירוע פועל ללא תלות בעומס, בחופשה או בהחלפת האחראי. העסקה הועברה לעובד אחר — השרשרת נמשכה לפי אותו נוהל, ואף פנייה לא נותרה ללא מענה בגלל גורם אנושי.
העומס הידני נמדד בפשטות: כמה מכתבים ביום העובד כתב בעצמו וכמה מהם היו חזרות על אותו נושא. לאחר המעבר לאירועים נשארים רק אותם הודעות שבהן באמת נדרש אדם — דיון בתנאים, בקשה לא סטנדרטית, מועד שנוי במחלוקת.
צפיות התקשורת — האפקט הסופי: לכל עסקה יש מערכת שלבים זהה ויומן מובן, מי ומתי קיבל מכתב. לפני ההפעלה מקבעים קריטריונים: אילו אירועים ניקח, כמה זמן ממתינים לתגובה עד תזכורת, מי מקבל התראה בעת כשל בשליחה.
מצבי דיוור: אירוע, לוח זמנים, תנאי
מצב ההפעלה קובע מתי יוצא המכתב: מיד לאחר אירוע ב-CRM, ברגע שנקבע או לאחר הצטברות תנאים. מכך תלוי גם התנהגות הדיוור בעת שינוי סטטוס העסקה, וגם כמה עבודה ידנית נשארת למנהל. להלן ארבעה מצבים והמגבלות שלהם, שלרוב צפים כבר בעבודה.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| הפעלה לפי אירוע | שינוי שלב בעסקה, ליד חדש, פנייה ראשונה | פועל פעם אחת לאירוע; ייבוא המוני של אנשי קשר יוצר כפילויות |
| הפעלה לפי לוח זמנים | רשימות תקופתיות, תזכורות, החזרת בסיס "רדום" | לא מכיר הקשר: לאותה כתובת יישלח אותו מכתב |
| תסריטי דיוור מותנים | דחיפה לפי סימנים מצטברים: לא פתח, לא השיב, סכום העסקה | נדרש חישוב נכון של תנאים והגנה מפני שליחות חוזרות |
| שרשראות משולבות | אירוע, אחר כך הפסקה, בדיקת תנאי, קשר חוזר | קשה יותר לנפות, חובה תרשים שרשרת |
מצב משולב — אינו מנגנון נפרד, אלא הרכבה מבסיסיים: המכתב יוצא לפי אירוע, אחר כך הפסקה, בדיקת תנאי וצעד שני. עבור כמה משפכי מכירות, הכללים מבודדים לפי משפך ושלב, אחרת הליד יקבל מכתב מתסריט זר. כל מצב מריצים על משפך בדיקה לפני ההפעלה — זה זול יותר מאשר לעצור את הדיוור לאחר התלונות הראשונות.
יישום בשלבים: מתרשים ועד הפעלה
יישום מכתבי טריגר ב-Bitrix24 מתחילים לא מתבניות, אלא ממלאי של מה שכבר עובד. בחשבון בדרך כלל חיים רובוטים בשלבים, תהליכים עסקיים וכללים ישנים: חלקם משכפלים זה את זה, חלקם שותקים בגלל תנאי שלא התקיים, ורק דרך יומן השליחות אפשר לראות זאת.
- ביקורת תסריטים — מייצאים כללים, רובוטים בשלבים ותבניות, ומשווים ליומן: איפה כפילויות, איפה המכתב לא יוצא, איפה הנמען כבר ביטל רישום.
- תרשים אירועים — טבלה «אירוע → תנאי → תבנית → השהיה → אחראי». עליה רואים הצטלבויות: העסקה נכללת גם במכתב לפי שלב וגם בדיוור לפי סגמנט.
- הגדרת כללי שליחה — תנאי הפעלה, תנאי עצירה (לקוח השיב, עסקה נסגרה, ביטול רישום) והגבלת תדירות: לא יותר ממכתב אחד לאיש קשר בתקופה נתונה.
- תבניות ומשתנים — החלפת שדות עסקה ואיש קשר, בדיקה שבערך ריק המכתב לא יוצא עם מקום ריק בטקסט.
- שליחת בדיקה — הרצה על עסקאות בדיקה: יוצרים כפילויות כרטיסים, מזיזים שלבים, בודקים החלפה, אזורי זמן, נפילה לספאם ועבודת קישור ביטול הרישום.
- בדיקת עמידות לתקלות — התנהגות בהיעדר כתובת, כניסה חוזרת של העסקה לאותו שלב, החלפה ידנית של האחראי.
- מסירת הגדרות והדרכה — תרשים, הרשאות, הוראות, תיאום עם העובדים; בשבוע הראשון משווים את היומן לתכנית.
חבילת מסירה: תרשימים, כללים, נהלים
חבילת מסירה — זו לא תיקייה עם קבצים «ליתר ביטחון», אלא מערכת מסמכים שלפיהם מנהל מערכת חדש או מנהל עבודה משחזר את עבודת הדיוור בלי לפנות אלינו. להלן מה בדיוק נשאר אצל הלקוח לאחר מסירת המערך של דיוורים טריגריים.
- מפת תסריטים — תרשים תסריטים עם נקודות הפעלה: איזה אירוע ב-CRM או באתר מפעיל את הדיוור, אילו תנאים נבדקים לפני השליחה, באיזה ענף המכתב יוצא, ובאיזה המשתמש נופל מהשרשרת.
- נהל שליחה — כללי הפעלה: חלונות זמן, מגבלות על מספר מכתבים ביום לנמען אחד, כללי שליחה חוזרת לאחר פתיחה או קליק, תנאי עצירת הסדרה בעת רכישה או ביטול רישום.
- תבניות מכתבים ומשתנים — התבניות עצמן עם החלפות משדות עסקה, איש קשר וחברה, כדי שהמשווק יתקן את הטקסט בלי לשבור את לוגיקת ההחלפה.
- מטריצת הרשאות גישה להגדרות — מי יכול ליצור ולהפעיל תסריט, מי רק עורך תבנית, מי רואה סטטיסטיקה: הרשאות גישה להגדרות מופרדות לפי תפקידים, ולא ניתנות לכולם על ידי מנהל המערכת.
- הוראות למנהלים — מסמך קצר לפעולות תכופות: כיצד להשהות את הדיוור ללקוח מסוים, כיצד להוציא כתובת מהסדרה, מה לעשות בתלונה על ספאם.
- סדר שינויים — תיעוד הדיוור מתנהל במקום אחד: עריכת תסריט עוברת בדיקה על איש קשר לבדיקה, וגרסת הכללים מתועדת, כדי להבין מדוע המכתב יצא דווקא כך.
חבילה כזו מסירה את התלות במבצע מסוים: תסריטים, נהל שליחה והרשאות מתוארים מספיק כדי שצוות הלקוח יערוך אותם בעצמו, ואנחנו נתחבר רק בשינויים מורכבים.
מקרה בוחן: לפני ואחרי — סירובים, תגובה, עומס
הפרויקט — ספק ציוד תעשייתי: 250–300 פניות בחודש, מחלקה של חמישה מנהלים, כל העבודה עם הלקוח ב-Bitrix24. הדיוורים היו תלויים על אירוע «נוצר ליד» ולא התחשבו בחזרת הלקוח: אדם עם עסקה כבר פתוחה קיבל מכתב מגע ראשון בשנית, והנרשמים לביטול נשארו במדגם. שיעור סירובי המכתבים עמד על כ-17%, וספקי הדואר יותר ויותר שלחו את הזרם כולו לספאם.
מה נשבר לפני התיקונים
- הטריגר פעל על יצירת ישות, ולא על שינוי שלב — בפנייה חוזרת המכתבים שוכפלו.
- ביטולי רישום נכנסו ליומן, אך לא הוצאו ממדגמים עתידיים.
- לאחר תשובה אוטומטית הפנייה נשכבה ברשימה כללית בלי אחראי: הלקוח חיכה למנהל חי 5–6 שעות.
מה שינו ומה נהיה
תנאי ההפעלה הועברו לשינוי שלב ולהופעת ערוץ פנייה חדש, לפני השליחה הוספה בדיקה מול בסיס הנתונים. ביטולי רישום ועסקאות סגורות הועברו לרשימת חריגים נפרדת, זרמי הודעות שירות ושיווק הופרדו עם חתימות דומיין שונות. לפניות חדשות הוגדרה הסלמה: אם מנהל לא לקח תוך 15 דקות — התראה נשלחת לממונה ומועברת למנהל פנוי.
שיעור השליחות הכושלות ירד מ-17% ל-2–3%, תלונות על ספאם כמעט נעלמו, וזמן הטיפול הממוצע בפנייה הצטמצם מ-5–6 שעות ל-25–30 דקות. שליחה ידנית — כ-40 הודעות ביום — עברה לטריגרים לחלוטין: כל מנהל פינה כמעט שעתיים לשיחות ולהתאמת ציוד.
מה לעשות אם חלק מהתסריטים כבר מוגדרים ידנית
מתחילים במלאי של דיוורים: מייצאים את כל הרובוטים, הטריגרים, כללי ה-CRM האוטומטיים, תבניות המכתבים והתהליכים העסקיים שנוגעים לעסקאות וללידים. עבור כל כלל מתעדים את תנאי ההפעלה, קהל היעד, הערוץ ותאריך העריכה האחרונה.
לעתים קרובות כבר בשלב זה רואים שחלק מהתסריטים המוגדרים לא פעלו אף פעם, וחצי משכפלים זה את זה באותו שלב.
כפילויות והתנגשויות מנתחים לפי האפקט: אם בעסקה אחת יוצאים שני מכתבים בהפרש של דקה, הלקוח קורא את השני כדחיפה, ובכרטיס מופיעה פעילות כוזבת. זוגות כאלה מאחדים לתסריט אחד עם תנאי משותף ונקודת כניסה אחת — במקום שני כללים שנויים במחלוקת נשאר אחד צפוי.
העברת כללים ידניים מתבצעת בלי לעצור מכירות: את הכלל הישן לא מוחקים, אלא מעבירים למצב כבוי, את התסריט החדש מפעילים על סגמנט צל. חלק מהעסקאות הולכות לפי הלוגיקה החדשה, חלק לפי הקודמת — משווים הפעלות ותוכן מכתבים.
פער הופך לעילה לשפר את התנאי, ולא לכבות הכל בבת אחת; החזרה לאחור — פעולה אחת, הכלל הקודם מופעל מחדש.
לאחר מכן מחליפים בבלוקים, משלב לשלב, עם הפסקה לבדיקת המדגם. Bitrix24 שומר היסטוריית שינויים של רובוטים, לכן רואים מי ומתי שינה את הלוגיקה — בניתוח התנגשויות זה חוסך שעות.
תקלות נפוצות: ספאם, כפילויות, מגעים חוזרים
דיוור טריגרי ב-Bitrix24 נשבר בדרך כלל לא בבונה, אלא בגבול עם שרת הדואר ובאירועים חוזרים. הלקוח רואה סימפטום — מכתב בספאם, שני מכתבים זהים ברצף, מגע חוזר לאחר החזרת העסקה אחורה — ומסיק שהאוטומציה לא עובדת.
מדוע מכתבים נופלים לספאם, למרות שהטקסט לא נראה כמו פרסומת?
דומיין השליחה לא מאומת: בלי רשומות SPF, DKIM ו-DMARC ספקי הדואר לא נותנים אמון לשולח, גם אם הכתובת ארגונית. גורם שני — מגבלות שליחה: בהתחלה חדה מדומיין חדש חותכים את הנפח והתדירות, לכן קובעים מגבלת מכתבים לשעה, מפרידים זרמים לתת-דומיינים ומחממים את המוניטין בהדרגה.
לקוח מקבל שני מכתבים ברצף — זו תקלה או הגדרה?
הגדרה. טריגר לעתים קרובות תלוי גם ביצירת ישות וגם בשינוי, והעסקה במהלך העבודה מחליפה אחראי ושדות. שמים תנאי «הסטטוס השתנה לנדרש», מוסיפים שדה שירות-דגל «מכתב נשלח» ומסננים כפילויות לפי מזהה העסקה.
העסקה חזרה לשלב קודם — המכתב יישלח שוב?
כן, אם ההפעלה מתבצעת לפי הערך הנוכחי של הסטטוס: חזרה ומעבר חוזר מפעילים את הטריגר מחדש — כך מופיעות כפילויות של מכתבים. אנחנו קושרים את השליחה לחתימת הזמן של המגע האחרון ומנהלים יומן שלבים, לכן החזרת סטטוס העסקה לא יוצרת כפילות.
לפני ההפעלה מריצים את התסריטים על תיבת בדיקה: שינוי סטטוס, החזרה אחורה, פתיחה מחדש של עסקה, החלפת אחראי — ומשווים את יומן השליחות ללוגיקה הצפויה.נדון במשימה ונחזור עם תוכנית עבודה
כדי שהערכת היישום תישען על עובדות ולא על הנחות, את ניתוח המשימה מתחילים מנתונים ראשוניים. שיחת ועידה אורכת כשעה: בודקים את מבנה המשפכים, כרטיסי הישויות ומה מהאירועים הפורטל כבר מתעד בעצמו, ומה יהיה צורך להוסיף.
להכין מראש כדאי את הדברים הבאים — זה מספיק כדי שנחזור עם תוכנית עבודה לדיוורים, ולא עם שאלות הבהרה:
- הרשאות גישה לפורטל עם זכויות מנהל ומערך בדיקה נפרד, אם הוא כבר קיים;
- רשימת אירועי מקור: שינוי שלב בעסקה, פנייה נטושה, משימה באיחור, פנייה חוזרת;
- סגמנטים וסימנים שלפיהם מחלקים אנשי קשר — מאין מגיעים השדות האלה בכרטיס;
- ערוצי מסירה: דואר, מסרים מיידיים, הודעות בתוך הפורטל;
- טקסטים של מכתבים ותבניות או הלוגיקה שלפיה צריך להרכיב אותם;
- מגבלות תדירות: כמה הודעות ביממה מותר לאיש קשר אחד ובאילו שעות שולחים;
- מערכות חיצוניות — 1C, טלפוניה, אתר, מחסן: מה כבר מחובר ובאילו שדות מתחלף;
- מדדים שלפיהם תשפטו את התוצאה: פתיחות, מעברים, שהגיעו לעסקה.
שלחו את הרשימה בכל צורה — בטבלה, בהערות או בצילומי מסך של כרטיסים. אנחנו נשווה אותה לתצורת הפורטל הנוכחית, נראה אילו נתונים כבר קיימים ואילו יהיה צורך להזין, ונחזור עם תוכנית עבודה: שלבים, סדר הפעלה, נקודות בדיקה.
את הלוגיקה נריץ על מערך בדיקה, כדי שלפני ההפעלה על לקוחות חיים נראה אילו אירועים פועלים ומה יוצא לדיוור.