לקוח שביקש להסיר וממשיך לקבל הודעות בערוץ אחר חווה עסק אחד שמתעלם ממנו. איך בונים רשומת הסרה אחת שכל הערוצים בודקים לפני שליחה.
עיקרי הדברים
- כל כלי מנהל רשימת הסרה משלו, וזו בדיוק הבעיה.
- מפתח הזיהוי חייב להיות משותף - טלפון מנורמל ודוא"ל - אחרת ההסרה לא תופסת.
- כדאי להפריד בין הסרה משיווק לבין הודעות תפעוליות, ולהסביר זאת.
- הבדיקה לפני שליחה היא הרכיב היחיד שבאמת מונע את התקלה.
הלקוח לא רואה ערוצים - הוא רואה עסק אחד. כשהוא מסיר את עצמו מהדיוור וממשיך לקבל SMS, מבחינתו העסק התעלם מהבקשה. הפתרון הוא רשומת הסרה אחת שכל ערוץ בודק לפני שליחה, ולא רשימה נפרדת בכל כלי.
איך נוצרת התקלה
| המצב | מה קורה | מה הלקוח חווה |
|---|---|---|
| הסרה בדיוור בלבד | ה-CRM עדיין שולח SMS | "ביקשתי להסיר וזה לא עובד" |
| הסרה בוואטסאפ | מערכת הדיוור לא יודעת | אותו דבר, בערוץ אחר |
| מספר בפורמט שונה | ההסרה לא מתאימה לרשומה | נשלח שוב בטעות |
| שתי כתובות לאותו אדם | הסרה תופסת רק לאחת | נשלח שוב לכתובת השנייה |
| ייבוא רשימה ישנה | הסרות קודמות נדרסות | חוזר לקבל אחרי שנתיים |
השורה האחרונה היא הגרועה מכולן, והיא נפוצה: ייבוא של קובץ ישן שמחזיר לרשימה אנשים שהסירו את עצמם מזמן.
מה צריך להיות ברשומת ההסרה
- מפתח זיהוי - טלפון מנורמל, דוא"ל, ורצוי גם מזהה לקוח.
- מאיזה סוג הסרה מדובר - שיווק, ערוץ ספציפי, או הכול.
- מתי ומאיפה הגיעה הבקשה.
- מי קלט אותה - הלקוח בעצמו, נציג, או מערכת.
- סטטוס - פעיל, או בוטל על ידי הלקוח עצמו.
השדה השני הוא שמאפשר לשמור על שירות: לקוח שביקש להפסיק קבלת מבצעים בדרך כלל עדיין רוצה אישור הזמנה ותזכורת לפגישה, ואי אפשר להסיק את זה בלי שדה שמבדיל.
איך בונים את זה בלי פרויקט גדול
- לבחור מקום אחד שיחזיק את הרשומה - בדרך כלל ה-CRM או תוכנת החשבוניות.
- לנרמל מפתחות - טלפון בפורמט אחיד, דוא"ל באותיות קטנות.
- לייבא את ההסרות הקיימות מכל כלי, ולאחד.
- להוסיף בדיקה לפני שליחה בכל ערוץ, גם אם היא ידנית בהתחלה.
- לחסום ייבוא שדורס הסרות קיימות.
שלב 5 הוא זה שמונע את החזרה: כל ייבוא עתידי חייב לבדוק מול הרשומה ולא להפך. אותו היגיון של מפתח זיהוי יחיד מתואר בכפילויות לקוחות בין מערכות, וכאן הוא קריטי במיוחד כי טעות גורמת לשליחה שאסור היה לשלוח.
מה קורה כשההסרה מגיעה בשיחה
חלק ניכר מההסרות בישראל נאמרות בטלפון או נכתבות בוואטסאפ - "תסירו אותי מהרשימה" - ולא נלחצות בכפתור. אלה ההסרות שנעלמות, כי אף מערכת לא קלטה אותן.
הפתרון הוא נוהל פשוט: לכל נציג יש דרך אחת לרשום הסרה, והיא לוקחת שניות. כשזה לוקח יותר מזה, זה לא נרשם - והלקוח יקבל את ההודעה הבאה, יתעצבן, והפעם גם יחסום.
מה להגיד ללקוח
הודעת אישור אחת אחרי הסרה חוסכת פניות: מה בדיוק הוסר, מה ימשיך להגיע (אישורים, עדכוני משלוח), ואיך לחזור אם ירצה. זו גם ההזדמנות היחידה לשאול בעדינות למה - שאלה אחת, לא סקר.
מה שלא כדאי: להקשות על ההסרה, לדרוש התחברות, או לשלוח "בטוח?" פעמיים. הקושי לא מקטין הסרות אלא הופך אותן לתלונות ולחסימות, וחסימה גרועה בהרבה מהסרה מסודרת - כי אחריה גם ההודעות התפעוליות לא מגיעות.
מה למדוד
- שיעור הסרות לכל סוג הודעה, לא במצטבר.
- כמה הסרות נקלטו ידנית על ידי נציגים - זה מדד לשימושיות הנוהל.
- כמה פעמים נשלחה הודעה למי שהסיר - המדד היחיד שחייב להיות אפס.
- כמה חסימות בוואטסאפ, כי הן הסימן שההסרה לא עבדה.
המדד השלישי הוא זה ששווה לבדוק אחרי כל שליחה בחודשיים הראשונים. כשהוא לא אפס, הבעיה כמעט תמיד במפתח הזיהוי - מספר שנשמר בפורמט אחר - ולא בכוונה של מישהו.
למה זה נשבר דווקא בעסקים מסודרים?
דווקא עסק שמשתמש בכמה כלים טובים נופל בזה יותר מעסק שמנהל הכול בגיליון אחד. מערכת הדיוור מצוינת בניהול הסרות - שלה. מערכת ה-SMS מצוינת בניהול הסרות - שלה. ווואטסאפ מנהל אופט-אאוט משלו. כל אחד מהם עושה את עבודתו נכון, ואף אחד מהם לא יודע על האחרים.
לכן הפתרון אינו להחליף כלי אלא להוסיף שכבה דקה מעליהם: מקום אחד שמרכז, וכלל שאומר שאף שליחה לא יוצאת בלי בדיקה מולו. בעסקים קטנים זה יכול להיות גיליון; בעסקים גדולים יותר זו טבלה ב-CRM עם בדיקה אוטומטית. מה שלא משתנה הוא העיקרון: הכלי ששולח אינו הכלי שמחליט למי מותר לשלוח.
יש לזה גם יתרון שלא חושבים עליו מראש: כשההסרות מרוכזות במקום אחד, אפשר לראות מגמה. עלייה פתאומית בהסרות אחרי סוג מסוים של הודעה היא מידע שימושי, והוא פשוט לא קיים כשכל כלי מחזיק את הנתון שלו בנפרד.
מה לעשות כשגילינו ששלחנו בטעות
זה קורה, וההתנהלות אחרי קובעת אם זו תקלה או תלונה. מה שעובד: לזהות מיד למי נשלח בטעות, לרשום אותם ברשומה המרכזית, ולשלוח התנצלות קצרה רק למי שכבר פנה - ולא גל התנצלויות שמייצר הודעה נוספת למי שביקש שלא לקבל.
מה שחשוב יותר הוא למצוא את הסיבה: ייבוא שדרס, פורמט מספר שלא תאם, או נציג ששלח מרשימה ישנה ששמר אצלו. שלוש הסיבות האלה מכסות כמעט את כל המקרים, ולכל אחת יש תיקון מבני שמונע את הפעם הבאה.
הסיבה השלישית היא גם הפחות טכנית והקשה ביותר לתיקון: רשימות פרטיות אצל אנשים. הפתרון אינו איסור אלא לתת חלופה נוחה - כשקל לשלוח מהמערכת, אין סיבה לשמור קובץ בצד. כשזה קשה, אנשים תמיד ימצאו דרך מהירה יותר, וזו בדיוק הדרך שאין בה בדיקת הסרה.
מקורות
שאלות נפוצות
כמה מהר צריך לכבד הסרה?
תפעולית, כמה שיותר מהר - ובעיקר לפני השליחה הבאה. הבעיה הנפוצה היא קמפיין שכבר "בתור" ויוצא אחרי שההסרה נקלטה, ולכן שווה לבנות את הבדיקה ברגע השליחה ולא ברגע בניית הרשימה.
מה עם לקוח שהסיר וחזר לקנות?
קנייה אינה הסכמה לדיוור, ולכן ההסרה נשארת בתוקף עד שהוא מאשר מחדש. מה שכן אפשר לשלוח הוא מה שקשור לעסקה עצמה - אישור, קבלה, עדכון משלוח - וזו בדיוק הסיבה להפריד בין סוגי ההודעות ברשומה.
אפשר לשלוח לו הודעה אחת לבדוק אם השתנה?
לא בערוץ שממנו הוסר. אם הוא הסיר מהדיוור, אפשר לשאול בהזדמנות אחרת - למשל בשיחה או בטופס באתר - אבל שליחה נוספת "רק כדי לבדוק" היא בדיוק מה שהוא ביקש שלא יקרה.
איך מנהלים הסרה כשאין CRM?
גיליון אחד עם שתי עמודות - טלפון מנורמל ודוא"ל - ותאריך, מספיק לחלוטין. מה שחשוב הוא שיהיה רק אחד, שכל מי ששולח יפתח אותו לפני שליחה, ושייבוא לרשימות ייבדק מולו.
להמשך קריאה
שירות רלוונטי
WhatsApp Cloud API
תבניות, אינבוקס דו-כיווני ותזכורות על ה-API הרשמי של Meta.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה מנסה להפוך לאוטומטי או לבנות, ואומר לך מהי הדרך המהירה והאמינה ביותר ליישם את זה.