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

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

למה כפילויות במאגר לקוחות נוצרות

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

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

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

איך למנוע כפילויות במאגר לקוחות: מתחילים בהגדרת זהות

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

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

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

נרמול נתונים לפני השוואה

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

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

בונים מניעת כפילויות בכל נקודת כניסה

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

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

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

אינטגרציות: לא רק להעביר מידע, אלא לנהל אותו

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

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

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

מנקים את המאגר הקיים בלי לאבד מידע

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

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

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

מדדים ובקרות שמחזיקים לאורך זמן

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

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

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

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