כפילויות רשומות ב-CRM: איך עוצרים אותן בזמן?

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

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

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

איך נוצרות כפילויות רשומות ב-CRM?

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

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

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

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

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

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

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

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

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

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

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

איך מונעים כפילויות רשומות מלכתחילה?

מניעה זולה בהרבה מניקוי, וברוב המערכות היא עניין של כמה החלטות תפעוליות ולא של פיתוח.

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

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

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

מתי כפילויות רשומות הן לא באמת הבעיה?

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

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

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