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