המאמר מיועד לעסקים שעובדים עם מערכת CRM, ולמי שאחראי בהם על נתוני הלקוחות. הוא מתאר תהליך מסודר לניקוי המצב הקיים, וכללים שמונעים מהבלגן לחזור. בסופו תוכלו לתכנן ניקוי ראשון, בלי לאבד היסטוריה ובלי להחזיר לרשימת הדיוור מישהו שביקש לצאת ממנה.
מערכת CRM טובה כמו הנתונים שבה. כשאותו לקוח מופיע שלוש פעמים, כשמספרי טלפון נשמרים בחמישה פורמטים, וכשחצי מהרשומות בלי עיר או בלי מקור הגעה, אי אפשר לסמוך על דוחות, דיוורים נשלחים פעמיים, ואנשי המכירות מבזבזים זמן בחיפוש. הבעיה לא נוצרת ביום אחד, ולכן גם לא נפתרת בניקוי אחד. צריך שני דברים: ניקוי מסודר של המצב הקיים, וכללים שימנעו את החזרה.
המאמר מתאר תהליך שמתאים לרוב מערכות ה-CRM. הכלים המדויקים — מיזוג, ייבוא, שדות חובה — שונים בין מערכות, ולכן כדאי לבדוק את התיעוד של המערכת שלכם.
לפני שמתחילים: גיבוי והחלטות
- גיבוי מלא של הנתונים לפני כל פעולה של מיזוג או מחיקה. מיזוג רשומות הוא לרוב פעולה שקשה לבטל. על מדיניות גיבוי ראו גיבוי, שמירה ומחיקה של נתונים.
- הגדרת "לקוח": האם הרשומה היא אדם, חברה, או שניהם? מערכות רבות מפרידות בין איש קשר לארגון, וזה משפיע על זיהוי כפילויות.
- בעלים לתהליך: מי מחליט כשיש ספק אם שתי רשומות הן אותו לקוח.
שלב 1: אבחון
לפני שמנקים, מודדים. ייצוא של כל הרשומות לגיליון מאפשר לבדוק:
- כמה רשומות יש, וכמה מהן עם כתובת דוא"ל או טלפון כפולים.
- כמה רשומות בלי שדות שאמורים להיות מלאים.
- אילו פורמטים קיימים לכל שדה: טלפונים עם ובלי קידומת, ערים בכתיב שונה.
- כמה רשומות לא עודכנו או לא היו בקשר מעל תקופה שתגדירו.
התוצאה היא תמונת מצב, שתשמש גם כנקודת השוואה אחרי הניקוי. על מדדים שאפשר לעקוב אחריהם לאורך זמן ראו איכות נתונים: איך מודדים.
שלב 2: אחידות פורמט
לפני שמחפשים כפילויות, מאחידים פורמטים. אחרת, אותו מספר טלפון בשני פורמטים לא יזוהה ככפול.
- טלפונים: פורמט אחד, למשל ספרות בלבד עם קידומת, בלי מקפים ורווחים.
- דוא"ל: אותיות קטנות, בלי רווחים בתחילה ובסוף.
- שמות: הפרדה בין שם פרטי למשפחה, אם המערכת תומכת.
- ערים וארצות: רשימה סגורה של ערכים במקום טקסט חופשי.
שלב 3: זיהוי כפילויות
כפילויות מזהים לפי מפתחות, מהחזק לחלש:
- אותה כתובת דוא"ל — לרוב אותו אדם.
- אותו מספר טלפון — לרוב אותו אדם, אבל לפעמים טלפון משרד משותף.
- אותו שם ואותה חברה — מועמד לבדיקה ידנית.
מומלץ לא למזג אוטומטית כפילויות שזוהו רק לפי שם. שני אנשים באותו שם בהחלט יכולים להיות שני לקוחות שונים.
שלב 4: מיזוג
במיזוג קובעים לכל שדה איזה ערך נשמר. כללים מקובלים:
- הרשומה הישנה יותר נשמרת כרשומה הראשית, כדי לשמור על ההיסטוריה.
- לכל שדה נשמר הערך העדכני והמלא ביותר.
- היסטוריית פעילות, הזמנות ופניות מכל הרשומות מאוחדת לרשומה הראשית.
- הסכמות לדיוור: אם רשומה אחת מסומנת כמי שביקש לא לקבל דיוור, הסימון הזה צריך להישמר ברשומה הממוזגת. מיזוג אסור שיחזיר לרשימה מישהו שביקש להסיר אותו.
דוגמה בדיונית: במשרד ייעוץ נמצאו שתי רשומות של אותה לקוחה: אחת מטופס באתר, עם הסכמה לדיוור, ואחת מאירוע, שבה ביקשה מאוחר יותר לא לקבל דיוור. הכלל שנקבע: במיזוג, סימון של "לא לדיוור" גובר תמיד. כך הרשומה הממוזגת שיקפה את הבקשה האחרונה שלה.
שלב 5: רשומות ישנות
רשומות שלא היה איתן קשר זמן רב אינן בהכרח מיותרות, אבל כדאי להחליט מה עושים בהן: לסמן כלא פעילות, לבדוק שוב, או למחוק לפי מדיניות השמירה של העסק. מחיקה של מידע אישי שכבר אין בו צורך היא גם עניין של פרטיות. ראו פרטיות ואבטחת מידע של נתוני לקוחות.
כללי הזנה: איך מונעים את החזרה
- שדות חובה רק למה שבאמת נחוץ. שדה חובה שאין דרך למלא אותו בצורה נכונה מייצר ערכי זבל כמו "אין" או "000".
- רשימות סגורות במקום טקסט חופשי: מקור הגעה, תחום, עיר, סטטוס.
- בדיקת כפילות בהזנה: מערכות רבות מתריעות כשמזינים דוא"ל או טלפון שכבר קיימים.
- טפסים באתר שמזינים ישירות ל-CRM, עם אותם שדות ואותם פורמטים.
- מסמך כללים קצר: מה ממלאים בכל שדה, ואיך. מסמך כזה חשוב במיוחד כשכמה אנשים מזינים נתונים.
רשימת בדיקה
- בוצע גיבוי מלא לפני הניקוי.
- נמדד מצב פתיחה: כפילויות, שדות ריקים, פורמטים.
- הפורמטים אוחדו לפני זיהוי הכפילויות.
- כפילויות לפי שם בלבד נבדקו ידנית.
- במיזוג נשמרה בקשה לא לקבל דיוור.
- הוגדרו שדות חובה, רשימות סגורות ובדיקת כפילות בהזנה.
- יש מסמך כללי הזנה, וכל מי שמזין נתונים מכיר אותו.
הצעד הבא
התחילו בשלב האבחון: ייצוא, ספירה של כפילויות ושדות ריקים, ושמירת התוצאה כנקודת השוואה. אל תמזגו דבר לפני שיש גיבוי מלא ונוהל ברור לבקשות הסרה. לליווי אפשר להיעזר בעמוד ניהול נתונים.
שאלות ותשובות
IBASTOM.CO.IL
אפשר למזג כפילויות אוטומטית?
את הכפילויות הוודאיות, כמו אותו דוא"ל ואותו טלפון, כן, אחרי גיבוי. התאמות חלקיות, כמו שם דומה וטלפון אחר, דורשות בדיקה של אדם, כי מיזוג שגוי מאחד שני לקוחות שונים וקשה לפרק אותו.
מה עושים עם רשומות ישנות שלא היה איתן קשר שנים?
קובעים מדיניות לפני שמוחקים: אילו רשומות שומרים בגלל חובה חוקית או חשבונאית, אילו מעבירים לארכיון ואילו מוחקים. החזקת מידע אישי שאין בו צורך מגדילה את הסיכון במקרה של דליפה.
אילו שדות להגדיר כחובה?
מעט, רק מה שבאמת נחוץ לתהליך, למשל שם ודרך יצירת קשר אחת. יותר מדי שדות חובה גורמים לעובדים להזין נתונים מומצאים כדי לעבור הלאה, וזה גרוע משדה ריק.
איך מונעים שהכפילויות יחזרו?
בכללי הזנה: חיפוש לפני יצירת רשומה, פורמט אחיד לטלפון ולדוא"ל, ובדיקת כפילות בטפסים ובחיבורים. בודקים גם מאיפה הגיעו הכפילויות: לרוב מחיבור לטופס או למערכת אחרת שיוצר רשומה חדשה בכל פנייה.
צריך לגבות לפני ניקוי?
כן, תמיד. ייצוא מלא של הרשומות לפני כל מיזוג או מחיקה, ושמירה של הקובץ במקום מאובטח לתקופה מוגדרת. זה מאפשר לשחזר רשומה שנמחקה בטעות.
