מדוע ההסרה מ-Bitrix24 נכשלת ומה נשבר בדיוורים
ההסרה נכשלת לא בגלל כפתור במכתב, אלא בגלל אי-התאמות בין התבנית, יומן השליחה ופרופיל המנוי.
קישור ההסרה נבנה ברגע ההצבה ונושא מזהה נמען והאש הגנה; אם ערכו את התבנית ידנית או העבירו אותה בין פרויקטים, ההצבה מפסיקה להתאים למאגר — וקישור ההסרה לא עובד: מוביל לדף שנמחק, לאזור בלי מטפל או למסך ריק. האדם לוחץ, לא קורה דבר, והמשלוח הבא מסומן כספאם.
הכשל הטיפוסי השני — מצב המנוי לא משתנה. הסירוב נרשם במקום שבו המטפל של הדף שם אותו, והדיוור קורא את סימן ההסכמה ממקום אחר: מכרטיס איש הקשר, מהסגמנט או מרשימת הכתובות שהועברה למערכת חיצונית.
כל עוד המקורות האלה לא מאוחדים, פורמלית אפשר להסיר את המנוי, אבל בפועל לא: הכתובת נשארת במדגם וממשיכה לקבל מכתבים.
השכבה השלישית — שליחה מושהית. גם כשהמצב התעדכן כראוי, חלק מהמכתבים כבר עומדים בתור, והמשימה המתוזמנת ממשיכה לעבד את הסגמנט הקודם. המנוי מקבל עוד מכתב או שניים אחרי הסירוב — ועליהם בדיוק מגיעות התלונות על דיוורים.
המחיר של שלושת הכשלים משותף: שיעור התלונות עולה, הדומיין נכנס למסנני ספאם, יכולת המסירה יורדת בכל המאגר, לא רק אצל מי שהסיר. נפרט איך סוגרים את זה.
מה נותנת הסרה מנוהלת: השפעה בנתונים ובתהליכים
ניהול מנויים הוא לא קישור קוסמטי במכתב, אלא חלק מתשתית המסירה. כשההסרה פועלת בקליק אחד, וההסכמות נשמרות בכרטיס איש הקשר, לא רק חוויית הנמען משתנה — גם מדדי המוניטין של השולח משתנים. Bitrix24 מעבירה את האירועים האלה ל-CRM, ולכן ההשפעה נראית בנתונים, לא בתחושות.
שיעור התלונות על דיוורים יורד
הכפתור "זה ספאם" הוא אמצעי קיצון שאליו נועזרים כשההסרה מוסתרת בכותרת התחתונה או דורשת מכתב לתמיכה. קישור מפורש בכותרת המכתב וטיפול בסירוב מיד מסירים את העצבנות לפני לחיצה על "התלונן". שיעור התלונות יורד לעשיריות האחוז ונשאר שם — זו עבודה ישירה על מוניטין הדומיין.
הסרה ידנית של מנוי יוצאת מהתמיכה
בעבר בקשות "תוציאו אותי מהדיוור" הגיעו למנהל או לתיבה כללית וטופלו ידנית, עם סיכון לשכוח או לעשות פעמיים. אחרי ההגדרה הסירוב נרשם אוטומטית: בכרטיס איש הקשר נשארים הסיבה, התאריך והערוץ. שיעור ההסרות הידניות של מנויים מצטמצם כמעט לאפס, וזמן התגובה לבקשת לקוח — משעות לדקות.
יכולת מסירת המכתבים הופכת לצפויה
סגמנטים נבנים לפי מצב ההסכמה המעודכן, ולכן הדיוור יוצא למי שבאמת מחכה לו. פחות תלונות וכתובות נטושות — יכולת מסירת המכתבים גבוהה יותר ופחות נפילות לתיקיית "ספאם". דוח נפרד מראה איזה סגמנט ואיזה מכתב נותנים הסרות — נוצר נושא לניהול, לא ניחושים.
אפשרויות ההסרה ב-Bitrix24: מובנית, תבניתית, באמצעות אינטגרציה
סירוב לדיוור הוא אירוע שצריך לתפוס ולרשום, לא רק סימון בכרטיס איש הקשר. ב-Bitrix24 ההסרה המובנית סוגרת את התרחיש הבסיסי: במכתב יש קישור, קליק עליו מכניס את הכתובת לרשימת החסומים, והשליחות הבאות לאיש הקשר הזה לא יוצאות.
המגבלה היא שהמנגנון חי רק בתוך המערכת — אם חלק מהמכתבים יוצאים דרך שירות חיצוני, ההסרות שלו לא ייראו על ידי הלוגיקה המובנית.
השוואת גישות
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| הסרה מובנית | כל הדיוורים יוצאים מ-Bitrix24 | לא רואה סירובים משירותים חיצוניים, אין סיבות סירוב |
| תבנית מכתב עם הסרה | צריך טקסט משלך ודף סירוב | דורש דף ומטפל משל עצמו, אחרת הקישור לא עובד |
| אינטגרציה עם שירות דיוור ו-וובהוק הסרה | השליחה עוברת דרך פלטפורמה חיצונית | צריך סנכרון רשימות והגנה על הוובהוק מפני קריאות מזויפות |
הבחירה מצטמצמת לשאלה היכן פיזית נוצרת השליחה ומי מחזיק את רשימת המאסטר של המנויים. בתרחיש משולב כמעט תמיד צריך וובהוק הסרה: השירות החיצוני שולח אירוע סירוב, והמקבל מעדכן את איש הקשר ב-CRM.
את הטיפול בסירוב אנחנו עושים אידמפוטנטי — קריאה חוזרת לא יוצרת כפילות — ובודקים את חתימת הבקשה, אחרת רשימת החסומים מנופחת מבחוץ.
קריטריון קבלה אחד: אחרי הסירוב אף דיוור — לא מובנה ולא מהשירות — לא יוצא לכתובת הזו, ובכרטיס רואים מתי ומאיזו סיבה המנוי הוסר.
סדר העבודות: מביקורת מנויים ועד מסירת נהלים
הגדרת הסרה היא לא סימון בממשק, אלא מצב מנוי: הוא חי במאגר הכתובות, בכרטיס איש הקשר ובסגמנטי הדיוור בו-זמנית. כל עוד המקומות האלה לא מחוברים, הכתובת שהוסרה חוזרת לשליחה הבאה — מכאן התלונות על ספאם וירידת יכולת המסירה.
את סדר העבודות בונים כך שכל שלב נבדק בנפרד ולא שובר את הנתונים שכבר נצברו:
- ביקורת דיוורים. מייצאים דיוורים, סגמנטים ומקורות כתובות, ומסמנים היכן מצב המנוי לא נשמר בכלל, והיכן הוא מונח בשני מקומות וסותר.
- סכימת מצבי מנוי. קובעים מילון: פעיל, הוסר, הסרה לפי נושא, תלונה, כתובת לא תקינה. לכל מצב ממנים מקור ראשי וכלל התנהגות בעת קונפליקט.
- הגדרת הסרה. קישור בכותרת התחתונה של המכתב, דף אישור וטיפול במעבר: הבקשה צריכה לשנות מצב, לא רק להציג "הוסרת".
- חיבור ל-CRM. המצב נכתב לשדה של איש הקשר — המנהל רואה את ההסרה לפני שיחה, והמדגם לשליחה הבאה כבר לא לוקח את הכתובת הזו.
- שליחת בדיקה. הרצה על כתובות בקרה: המכתב מגיע, קליק על ההסרה משנה מצב תוך שניות, שליחה חוזרת לכתובת הזו לא יוצאת.
- ייבוא וחריגים. בודקים שטעינת מאגר חיצוני לא מחייה מנויים שהוסרו, ושתלונה נרשמת כמצב נפרד, לא כמחיקת רשומה.
- מסירת נהלים. מוסרים מסמך: מילון מצבים, מי ובאיזה ממשק משנה אותם, איך לטפל בבקשה "החזירו אותי לדיוור", איך לבדוק תוצאה אחרי עדכון.
סדר כזה סוגר את הבעיה המרכזית: ההסרה מפסיקה להיות תיקון חד-פעמי והופכת למצב מנוהל. ערוצים חדשים מחברים אחר כך בהרחבת סכימת המצבים, לא בכתיבה מחדש של הלוגיקה.
מה נשאר אצלכם: תבניות מכתבים, כללים ותיעוד
אחרי ההשקה נשאר אצלכם לא רק מנגנון הסרה עובד, אלא גם סט מלא של חומרים עבורו. הכול מונח בתיקייה אחת: תבניות, כללים, סכימת מצבים ונוהל עבודה עם מאגר המנויים. בודקים את המסירה בפשטות — מנהל חדש צריך לסגור בקשת מנוי טיפוסית בלי לשאול אותנו אפילו שאלה אחת.
- תבנית מכתב — טקסטים לאישור הסרה, לדיוורי שירות ולדיוורים שוטפים, עם הצבות מוכנות וקישורים עובדים. את הניסוחים משנים בעצמכם, והלוגיקה לא נשברת.
- כללי טיפול בהסרות — אילו אירועים סוגרים מנוי, איך מפרשים הסכמה מחודשת, מה עושים עם תלונה על דיוור ואיך מחזירים כתובת לפעילות.
- סכימת מצבים — פעיל, הוסר, מושהה, תלונה: מעברים בין מצבים, עילה לכל אחד ומי רשאי לשנות אותו.
- נוהל דיוורים — תדירות מגעים, מרווחים בין מכתבים, מגבלות לפי סגמנטים. עמידה בהם מורידה את שיעור ההסרות בלי לאבד תגובה.
- הוראות לתמיכה — תרחישים שלב אחר שלב: הסרה ידנית לפי פנייה, בדיקת היסטוריית הסכמות, ייצוא המוני, פעולות בעת כשל שליחה.
- מפת נתונים ויומן — אילו שדות על המנוי נשמרים ומאיפה הם מגיעים, מה ומתי נרשם, ואיך לפי הרשומות להוכיח את העובדה והזמן של ההסרה.
החומרים מתארים פעולות קונקרטיות ומכילים דוגמאות, לא עקרונות כלליים. אפשר להעביר אותם לקבלן חדש או לצוות פנימי — העבודה עם המנויים תימשך בלי ההשתתפות שלנו.
מקרה בוחן: איך הסירו תלונות על דיוורים והסרות ידניות של מנויים
הלקוח — רשת קמעונאית עם מאגר מנויים של כמה עשרות אלפי כתובות. הדיוורים יצאו דרך שירות חיצוני, ומצבי המנויים חיו בשני מקומות בו-זמנית: בכרטיסי אנשי קשר בפורטל ובמאגר של השירות.
אדם הסיר את עצמו דרך קישור במכתב, השירות סימן סירוב, אבל בפורטל איש הקשר נשאר פעיל — והדיוור הבא יצא שוב.
מה שינו
את מקור האמת עשו הפורטל: Bitrix24 מקבלת אירוע על ההסרה, שמה סימון בכרטיס איש הקשר וברשימת ההסרות המאוחדת. הזרימה ההפוכה — תיקונים של מנהלים וייבוא — יוצאת לשירות לפי עובדת השינוי, לא בייצוא מלא. החלפת המידע מתבצעת לפי תזמון, ולכן פרץ הסרות אחרי דיוור גדול לא הולך לאיבוד. הסרה ידנית של מנוי נסגרה כפעולה: להחזיר איש קשר לדיוור אפשר רק לפי בקשה מפורשת של הלקוח.
מדדים לפני ואחרי
לפני ההגדרה: כ-400 תלונות "זה ספאם" בחודש ו-6–8 הסרות מנוי ידניות בשבוע — מנהלים תיקנו מצבים בידיים. אחרי: התלונות ירדו בסדר גודל, הפעולות הידניות נעלמו מהתהליך, והפער בין המאגרים הצטמצם לאפס — התאמה מראה מצב זהה בפורטל ובשירות. ההסרות הפסיקו להיות שגרה: השיווק רואה רשימה מאוחדת ולא מסכן את יכולת מסירת המכתבים.
במה שונה הסרה מניהול הסכמות בשירות דיוור
הסרה והסכמה הן ישויות שונות, ובלבול ביניהן נותן מכתבים למי שכבר סירב. הסרה היא אירוע טכני: הכתובת נכנסת לרשימת החסומים של שירות הדיוור, ומכתבים אליה לא יוצאים. הסכמה היא רשומה בעלת תוקף משפטי: מי, מתי ובאיזה טופס הרשה לעבד את הנתונים שלו ולקבל דיוורים.
שירות דיוור לא יכול להיות מקור אמת. הוא רואה כתובת ועובדת סירוב, אבל לא יודע את העילה, הערוץ והמועד. אם ההסרה נשארת רק כתגית בתוך פלטפורמת הדיוור, המנהל ממשיך לכתוב מכרטיס הלקוח — הרי שם עדיין "מסכים".
מחלקים את תחומי האחריות לפי אירועים:
| אירוע | היכן נרשם | מהות הדבר |
|---|---|---|
| קליק "הסר" במכתב | שירות דיוור → כרטיס לקוח | תגית טכנית בתוספת ביטול הסכמה |
| סימון סירוב בכרטיס | מערכת ניהול | ביטול הסכמה בעל תוקף משפטי, עילה להחרגה |
| הסכמה דרך טופס באתר | מערכת ניהול | קבלת הסכמה עם מקור ותאריך |
| תלונה על מכתב | שירות וספק דואר | אות להחרגה מיידית של הכתובת |
מקור אמת אחד — כרטיס הלקוח ב-Bitrix24: הסכמה, המקור שלה, התאריך והביטול חיים שם, ושירות הדיוור מקבל מצב לפי החלפה ונשאר מבצע. הסרה במכתב יוצרת רשומת ביטול, ושינוי מצב בכרטיס מיד מוציא את הכתובת מהסגמנטים של הדיוור.
כל שינוי נרשם עם תאריך וערוץ — זה גם סנכרון מצבים וגם בסיס ראיות בבירור תלונה. הסכמה מחודשת נרשמת באותו אופן: עם מקור ותאריך, אחרת אין במה לאשר את הסירוב.
שאלות טכניות על מנויים והסרה
מכתב שיצא אחרי הסרה יקר יותר מדיוור שהוחמץ: הוא נותן תלונה ומוריד את יכולת המסירה של כל הדומיין. לכן תרחישי ההרשמה והסירוב מוחזקים במערכת אחת — מצב בכרטיס איש הקשר, רשימת חסומים משותפת ויומן שינויים עם מחבר ועילה.
להלן השאלות שצפות לרוב בקבלה: איך זה מועבר, מה קורה בהרשמה מחדש והאם אפשר לבטל הסרה המונית.
היכן נשמר מצב המנוי והאם הוא ישרוד העברה לפורטל אחר?
הסימון קשור לאיש הקשר ולכתובת, לא לדיוור נפרד, ולכן מועבר יחד עם הכרטיסים. אם אותה כתובת מופיעה בכמה כרטיסים, קובעים עדיפות: לוקחים את המצב מהרשומה המאוחרת ביותר ביומן, ואת האחרות מסמנים ככפילות.
איך עובדת הרשמה מחדש אחרי סירוב?
רק לפי פעולה מפורשת של האדם — אישור במכתב או דרך טופס, עם רישום תאריך ומקור ההסכמה. הרשמה מחדש שקטה בטעינה הבאה של המאגר לא עוברת: הייבוא לא דורס את הסירוב, אלא מוסיף רשומה ליומן.
מה קורה בהסרה המונית והאם אפשר לבטל אותה?
הסרה המונית עוברת דרך רשימת החסומים, וכל שינוי נרשם ביומן עם מקור. ביטול נעשה לפי היומן — נקודתית או בקבוצה לתקופה הרצויה. תרחישים אוטומטיים קוראים את אותה רשימה, ולכן מי שהוסר לא יקבל מכתב מענף מקביל.
אילו הרשאות צריך ומה נראה בהיסטוריית השינויים?
מספיקות הרשאות לסעיף הדיוורים ולרשימת החסומים, אין צורך בגישת מנהל מלאה. היסטוריית השינויים רושמת את המחבר, הזמן והעילה — מכתב, טופס, מפעיל או טעינה. היומן מיוצא לטבלה, כדי שהתמיכה תבדוק פניות בלי להיכנס לפורטל.
נדון במשימה: מה צריך להכין לקראת תחילת העבודה
כדי לחזור עם הערכה ותוכנית הטמעה, ולא עם מילים כלליות, אנחנו צריכים נתוני פתיחה על המערכת שלכם. להלן מה שכדאי להכין לדיון במשימה; את השאר נברר בשיחה.
- פורטל: Bitrix24 בענן או גרסה מקומית, אילו מערכות חיצוניות מחליפות איתו נתונים.
- היכן כרגע חיים המנויים: דיוורים, התראות, סגמנטים, עסקאות — ומי אחראי על ההגדרה שלהם.
- תרחיש ההסרה הנוכחי: האם יש קישור במכתב, מה קורה בקליק, לאן מגיעות תלונות וסירובים.
- ערוצים וסוגי הודעות שצריך להבחין ביניהם בהסרה: שירותיות, שיווקיות, טרנזקציוניות.
- דרישות ליומן המנויים: מה חייב להירשם, למי צריך ייצוא ובאיזו תדירות.
- מגבלות: נהלים לנתונים אישיים, אינטגרציות שאסור לשנות, ולוחות זמנים שצריך להיות מוכנים אליהם.
סדר הפתיחה כזה: שיחה, ניתוח נתוני הפתיחה, אישור הסכימה הרצויה — ואנחנו חוזרים עם הערכת העבודה ותוכנית הטמעה: שלבים, נקודות בקרה, סדר ביטול. אם חלק מהנתונים לא זמינים, חלק נוריד בעצמנו לפי הרשאות. תארו את המשימה בשני-שלושה פסקאות — זה מספיק כדי להתחיל.