איחוד אוטומטי של רשומות כפולות ב-CRM באמצעות AI

הסרת כפילויות אנשי קשר באמצעות AI: מדוע כפילויות מעוותות את נתוני ה-CRM

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

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

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

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

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

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

מה נותן מיזוג אוטומטי של כפילויות ב-CRM

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

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

מה הצוות מתעד כתוצאה מדידה של היישום:

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

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

מצבי התאמה: כללים, מודל AI, בדיקה ידנית

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

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

כיצד זה נבנה בפועל

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

שלבי היישום: מסקר הבסיס ועד למסירה

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

1. סקר בסיס הלקוחות. מייצאים אנשי קשר ועסקאות, מחשבים את שיעור החזרות לפי מקטעים ובודקים מאילו ערוצים הם מגיעים.
2. פרופיל הכפילויות. מנתחים היכן בדיוק נבדלות הרשומות: איות השם, פורמט הטלפון, לטינית מול קירילית, שדות ריקים. כאן גם מחליטים אילו מאפיינים נחשבים אמינים ואילו הסתברותיים.
3. סכמת ההתאמה. התאמה מדויקת של מזהה המפתח מובילה למיזוג אוטומטי, התאמה מטושטשת בכמה שדות — להסגר לבדיקה ידנית.
4. הגדרת מיזוג הרשומות. קובעים עדיפות מקורות לכל שדה: טלפון נלקח ממערכת אחת, סטטוס העסקה — מאחרת, כדי שהאיחוד לא ימחק את היסטוריית האינטראקציות.
5. בדיקה על נתונים היסטוריים. מריצים את הכללים על עותק של הבסיס ומחשבים את שיעור ההתראות השגויות, ולא רק את מספר המיזוגים. את סף הוודאות מכיילים לפני שהאוטומציה נוגעת בבסיס הפעיל.
6. חזרה לאחור של האיחוד. כל מיזוג נרשם ביומן עם מצב הרשומה לפני ואחרי — איחוד שגוי מוחזר לאחור, והכרטיס חוזר למצבו המקורי.
7. מסירה. מוסרים תקנון, יומן מיזוגים, ערכי ספים והוראות לתמיכה.

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

כללי התאמה, ספי דמיון ותקנון המיזוג

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

• כללי התאמה: אילו שדות משתתפים בהשוואה (טלפון, דואר, שם, חברה, כתובת), באיזה סדר הם נבדקים ומה מנורמל לפני ההשוואה — הבאת הטלפון לפורמט אחיד, פירוק קיצורים בשמות הארגונים.
• ספי דמיון מכוילים בנפרד לכל שדה: התאמה נוקשה לדואר ולטלפון, השוואה מטושטשת לשמות ולשמות חברות, עם ציון הערך שבו הזוג ממוזג אוטומטית וזה שבו הוא עובר לבדיקה ידנית.
• מדיניות עדיפות השדות: מכרטיס איזה נלקח הערך אם הרשומות נבדלות — הכלל «רשומה מלאה יותר», «רשומה ממקור אמין יותר», «העדכון האחרון» או שילוב שלהם לפי סוגי שדות.
• תקנון מיזוג הכרטיסים: מה מועבר לרשומה הראשית, מה נכנס לארכיון, כיצד נשמרת היסטוריית השינויים והעסקאות, המשימות וההתכתבות המקושרות.
• כללי טיפול בזוגות מחלוקתיים: לאן מגיעות התאמות דו-משמעיות, מי מטפל בהן ובאיזה מועד, וכיצד מחזירים לאחור מיזוג שגוי.
• תיעוד האינטגרציה: אובייקטים ב-CRM שהתהליך נוגע בהם, אירועי הפעלה, מגבלות על תדירות הפניות וסדר ההרצה החוזרת לאחר תקלה.
• סט זוגות אב של אנשי קשר, שעליו נבדק לפני כל שינוי בספים שהלוגיקה עדיין עובדת על הנתונים שלכם.

מקרה בוחן: כיצד מיזוג אוטומטי הסיר כפילויות בבסיס פעיל

נקודת הפתיחה

בסיס של 480 אלף אנשי קשר ב-amoCRM התמלא מטפסי אינטרנט, מייבוא מתערוכות ומהקלדה ידנית של מנהלים, ולכן אותו אדם נשמר שלוש פעמים: «Иван Петров», «Ivan Petrov», «Петров И.» — עם טלפונים שונים ועסקאות שונות.

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

כיצד ארגנו את בקרת איכות המיזוג

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

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

מדדים לפני ואחרי

שיעור הכפילויות בבסיס ירד מ-9–11% ל-0,3% ונשאר ברמה הזו: הרצה לילית משלימה זוגות חדשים לאחר כל ייבוא. זמן הטיפול בבסיס הצטמצם מחודשים של הצלבה ידנית להרצה לילית ועוד בדיקה מדגמית של המפעיל על כ-2% מהמקרים.

מספר האיחודים השגויים — 0,1% מכלל המיזוגים, וכל אחד מהם מוחזר לאחור בפעולה אחת לפי היסטוריית האיחודים.

מה עושים אם הכפילויות כבר התפזרו בין עסקאות ומשימות?

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

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

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

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

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

ספקות טכניים: מיזוג, חזרה לאחור, שימור ההיסטוריה

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

האם ניתן להחזיר לאחור איחוד?

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

מה יקרה להיסטוריית איש הקשר: שיחות, מכתבים, משימות?

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

האם המערכת תקרוס ומי יקבל גישה לנתונים?

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

נדון במשימה: נחזור עם הערכה ותוכנית עבודה

כדי שההערכה תהיה ריאלית ולא «ממוצע שוק», אנו זקוקים לעובדות על הבסיס שלכם. שלחו ייצוא של אנשי קשר ב-CSV — אנונימי, ללא נתונים אישיים: מזהה הרשומה, מקור, תאריכי יצירה ועדכון אחרון, ערכי השדות חברה, טלפון, דואר וכתובת בצורה שבה הם נמצאים במערכת. זה מספיק כדי לחשב את שיעור הכפילויות, לנתח תרחישי התאמה אופייניים ולהעריך את היקף העבודה הידנית.

כדאי לצרף לייצוא:

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

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

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