סנכרון אנשי הקשר של Google Workspace מעתיק אנשי קשר בין אנשי הקשר של Google לבין מערכת CRM לפי לוח זמנים. כפילויות מופיעות בדרך כלל כאשר שתי המערכות לא מצליחות לזהות את אותו אדם באמצעות מפתח ההתאמה שהוגדר. נתונים עלולים גם ללכת לאיבוד כאשר כלל התנגשות דורס ערך חדש יותר או שמחיקה מתפשטת בין מערכות. אנשי הקשר של Google יכולים לבטל שינויים מ-30 הימים האחרונים, מה שהופך את זה לחלון שחזור מעשי.
סנכרון אנשי קשר לעיתים רחוקות גורם לאובדן נתונים אקראי. רוב הבעיות נובעות משלוש נקודות צפויות בתהליך: כיצד רשומות מתאימות, כיצד עריכות סותרות נפתרות, והאם מחיקות מורשות להתפשט.
צוותים רבים מתייחסים לסנכרון כאל משימת התקנה פשוטה. חברו את Google Workspace, בחרו את שדות אנשי הקשר, בחרו כיוון והפעילו אותו. הבעיות מופיעות בדרך כלל מאוחר יותר, כאשר מישהו מגלה שרשימת אנשי קשר הוכפלה או שמספר טלפון שתוקן ב-CRM הוחלף בערך ישן יותר מאנשי הקשר של גוגל.
תוצאות אלו אינן בהכרח כשלים תוכנה. הן נובעות לעתים קרובות ישירות מאופן תצורת כללי הסנכרון. הגישה הבטוחה יותר היא להבין מה המחבר עושה במהלך כל מחזור סנכרון, לזהות איזו מערכת צריכה לשלוט בשדות חשובים וליצור נקודת שחזור לפני הסנכרון בכמות גדולה הראשון.
כיצד פועל סנכרון אנשי קשר
סנכרון אנשי קשר ב-Google Workspace משווה ומעדכן רשומות בין שתי מערכות נפרדות. בדרך כלל הוא מתוזמן ולא מיידי, כך שכל מחזור בודק מה השתנה מאז ההפעלה הקודמת ולאחר מכן מיישם את הכללים שהוגדרו.
מחזור סנכרון כולל חמישה שלבים:
- המחבר בודק שינויים - הוא מזהה אנשי קשר שנוצרו, נערכו או נמחקו מאז המחזור הקודם. בהתאם למחבר, בדיקות אלו עשויות להתרחש כל כמה דקות ולא באופן מיידי.
- זה תואם שיאים - עבור כל איש קשר שהשתנה, המחבר מחפש את הרשומה המתאימה במערכת האחרת. השדה המשמש להשוואה זו הוא מפתח ההתאמה, וכתובת דוא"ל היא בחירה נפוצה.
- זה ממפה שדות - המחבר קובע אילו שדות מתאימים בין שתי המערכות. שם, דוא"ל, טלפון, חברה ותפקיד עשויים להיות מקבילים ישירים. שדות ללא יעד ממופה אינם מועברים.
- זה פותר סכסוכים - אם אותו איש קשר שונה בשתי המערכות לפני הסנכרון הבא, כלל התנגשות קובע איזה ערך נשמר.
- זה כותב את השינויים - המחבר מחיל את השינויים המתקבלים בהתאם לכיוון הסנכרון ולהרשאות שנבחרו.
הנקודה החשובה היא ש התאמה ופתרון סכסוכים הן בעיות נפרדותהתאמה קובעת האם המחבר חושב ששתי רשומות שייכות לאותו אדם. פתרון סכסוכים קובע איזה ערך שורד כאשר הוא יודע שמדובר באותו אדם.
| הערה חשובה: סינכרון מעתיק נתונים בין שתי מערכות שכל אחת מהן מחזיקה רשומות משלה. זה שונה מ- שילוב CRM של Google Workspace בנוי סביב רשומת לקוח משותפת. אם אתם עדיין בוחרים במערכת CRM, הבחנה זו חשובה מכיוון שרשומה משותפת מפחיתה את כמות נתוני הקשר שיש להתאים בין מערכות נפרדות. |
מה מועבר?
סנכרון אנשי קשר לא בהכרח מעביר כל שדה ממערכת אחת לאחרת.
| סוג מידע | מגעים Google | CRM | תוצאת סינכרון אופיינית |
| שם | יש | יש | בדרך כלל ממופה |
| כתובת אימייל | יש | יש | בדרך כלל ממופה ומשמש להתאמה |
| טלפון | יש | יש | בדרך כלל ממופה |
| החברה | יש | יש | בדרך כלל ממופה |
| הגדרת תפקיד | יש | יש | לעתים קרובות ממופה |
| תוויות | יש | משתנה | לא ניתן להעביר |
| מקור מוביל | לא | יש | בדרך כלל נשאר ב-CRM |
| היסטוריית עסקאות | לא | יש | נשאר ב-CRM |
| שדות CRM מותאמים אישית | לא | יש | בדרך כלל נשארים ב-CRM |
שדה שאינו ממופה לא בהכרח נמחק. פשוט אין לו יעד במערכת השנייה. הסיכון מתעורר כאשר צוותים מניחים ששדה קיים משני הצדדים ואז מגלים שהוא מעולם לא נכלל במיפוי.
סנכרון חד כיווני לעומת סנכרון דו כיווני
כיוון הסנכרון קובע איזו מערכת רשאית לשנות את השנייה. החלטה זו צריכה להתקבל לפני שאתם דואגים למיפוי שדות בודדים, מכיוון שהיא קובעת האם עריכות סותרות יכולות להתרחש בכלל.
| קריטריונים | סנכרון חד כיווני | סנכרון דו-כיווני |
| כיוון השינויים | מקור ליעד | שתי המערכות |
| קונפליקטים | לא בין שתי המערכות | אפשרי |
| רשומות כפולות | עדיין אפשרי | אפשרי |
| עריכות יעד | ניתן להחליף | יכול להתפשט חזרה |
| מורכבות ההתקנה | תחתון | עליון |
| הכי מתאים ל | מערכת אחת הפועלת כמאסטר | צוותים משתמשים באופן פעיל בשתי המערכות |
סנכרון חד-כיווני בטוח יותר כאשר מערכת אחת היא בבירור מקור האמת.
לדוגמה, אם אנשי הקשר של גוגל משמשים רק למילוי מערכת CRM, אין סיבה מועטה לאפשר לעריכות של מערכת ה-CRM לחזור לגוגל.
סנכרון דו-כיווני הגיוני כאשר עובדים באמת מעדכנים אנשי קשר בשתי המערכות.
זה גם מציג דרישה חדשה: אתם צריכים כללים כדי להחליט מה קורה כאשר שתי המערכות מכילות גרסאות שונות של אותו איש קשר.
ההבדל המרכזי הוא פשוט: סנכרון חד-כיווני מפחית את הסיכון להתנגשות, אך אינו מבטל את הסיכון לכפילויות. עדיין ניתן לשכפל רשומה אם המחבר אינו מצליח להתאים אותה לאיש קשר קיים.
למה סינכרון יוצר כפילויות ואובדן
רוב בעיות הסנכרון של אנשי קשר נובעות משלושה מנגנונים: התאמת רשומות כושלת, עריכות סותרות והפצת מחיקות. כל אחת מהן דורשת תיקון שונה, ולכן מיזוג פשוט של כפילויות לאחר כל סנכרון אינו פותר את הבעיה הבסיסית.
מפתח ההתאמה
מפתח ההתאמה הוא השדה שהמחבר משתמש בו כדי להחליט אם שתי רשומות מייצגות את אותו אדם.
כתובת דוא"ל נפוצה משום שהיא ייחודית יחסית. הבעיה היא שהיא לא תמיד קיימת או עקבית.
היכן שהמשחק נכשל
נבחן קשר שקיים בשתי המערכות:
- אנשי קשר של גוגל: [מוגן בדוא"ל]
- CRM: [מוגן בדוא"ל]
אדם יכול לזהות מיד ששתי הרשומות עשויות להיות שייכות לג'ון סמית'. מחבר המשתמש בהתאמה מדויקת של דוא"ל לא יכול להניח הנחה זו. הוא רואה שני ערכים שונים ועשוי ליצור רשומה שנייה.
אותה בעיה מתרחשת כאשר:
- לרשומה אחת אין כתובת דוא"ל.
- במערכת אחת משתמשים בדוא"ל עבודה ובמערכת אחרת בדוא"ל אישי.
- מספרי טלפון משתמשים בפורמטים שונים.
- המחבר תואם לשדה שמשתמשים עורכים באופן קבוע.
- כפילויות כבר היו קיימות לפני שהסנכרון הופעל.
עיצוב טלפון יכול ליצור תוצאות מבלבלות במיוחד. לדוגמה, +44 20 7946 0958 ו-02079460958 עשויים לייצג את אותו מספר אך לא יתאימו אם המחבר משווה את המחרוזות המאוחסנות במדויק.
תקן את המפתח לפני המיזוג
מיזוג כפילויות שימושי רק לאחר תיקון בעיית ההתאמה.
אם מפתח ההתאמה עדיין לא עקבי, הסנכרון הבא יוכל ליצור מחדש את הרשומות הכפולות שזה עתה הסרת. הרצף הנכון הוא:
זהה מדוע ההתאמה נכשלה ← סטנדרטיזציה של השדה ← מיזוג כפילויות קיימות ← הפעלת סנכרון מבוקר.
עבור מסדי נתונים גדולים יותר, כדאי גם לבדוק כמה רשומות חסרות להן מפתח ההתאמה שנבחר לפני הפעלת סנכרון דו-כיווני.
פתרון סכסוכים
התנגשות מתרחשת כאשר המחבר מזהה שתי רשומות כאותו איש קשר אך מוצא ערכים שונים מכיוון ששתי המערכות נערכו לפני הסנכרון הבא.
גישות נפוצות כוללות:
| כלל קונפליקט | מה קורה | סיכון עיקרי |
| כתיבה אחרונה מנצחת | העריכה האחרונה נשמרה | ניתן להחליף תיקון מוקדם ושימושי |
| מערכת רישום | מערכת אחת שולטת בשטח | ייתכן שלא יישמרו שינויים במערכת האחרת |
| כללים ברמת השדה | שדות שונים פועלים לפי כללים שונים | נדרשות יותר התקנה ותחזוקה |
ניצחונות בכתיבה אחרונה (Last Write wins) נוחים אך עלולים לגרום לשינויים שקטים. אם מישהו מתקן מספר טלפון במערכת ה-CRM בשעה 9:00 ועובד אחר עורך את אותו איש קשר בגוגל בשעה 10:00 באמצעות מספר טלפון ישן יותר, העריכה המאוחרת יותר עשויה להחליף את התיקון.
עבור שדות המשפיעים על מכירות או שירות לקוחות, שקלו להקצות מערכת רישומים במקום זאת. מבנה מסד הנתונים של CRM עשוי להכיל מידע שאין להחליף אותו בעריכה בפנקס הכתובות.
הפצת מחיקה
מחיקה ראויה לתשומת לב נפרדת משום שהיא יכולה להסיר מידע שאינו גלוי באיש הקשר עצמו.
בתצורה דו-כיוונית, מחיקת איש קשר בגוגל עלולה למחוק את המקבילה שלו במערכת ה-CRM. אם רשומת ה-CRM מכילה הערות, פעילויות, פרטי עסקה או קישורים לרשומות לקוחות, ההשפעה גדולה יותר מאשר אובדן שם ומספר טלפון.
| פעולה | תוצאה פוטנציאלית |
| עריכת איש קשר | מערכת אחרת מקבלת את הערך החדש |
| צור איש קשר | מערכת אחרת יוצרת רשומה תואמת |
| מיזוג אנשי קשר | ניתן להסיר או לשנות רשומה אחת |
| תמחק קשר | המחיקה עלולה להתפשט |
| שנה את שני הצדדים | כלל הסכסוך קובע את הערך השורד |
אם המחבר שלך מאפשר השבתת הפצת מחיקה, שקול להשאיר אותה כבויה אלא אם כן זרימת העבודה שלך דורשת זאת במפורש.
הגדרת סנכרון בצורה בטוחה
הבקרות היעילות ביותר הן אלו המיושמות לפני הסנכרון הראשון. לאחר שאלפי אנשי קשר שוכפלו או נמחקו, הניקוי הופך לקשה משמעותית מכיוון שצריך להבחין בין נתונים מקוריים לשינויים שנוצרו על ידי הסנכרון.
השלם את הבדיקות הללו לפני המחזור הראשון
- ייצוא שתי המערכות: שמור קובץ CSV של אנשי הקשר של גוגל ושל מערכת ה-CRM מחוץ לשתי המערכות. זה מספק לך נקודת שחזור אם הסנכרון הראשון מתנהג בצורה בלתי צפויה.
- הסר כפילויות קיימות: סנכרון מסד נתונים שכבר מכיל כפילויות מקשה על ההתאמה ויכול להכפיל את הבעיה.
- בדיקת כיסוי מפתח התאמה: גלה לכמה אנשי קשר חסר השדה שאתה מתכנן להשתמש בו להתאמה, ובמיוחד כתובת דוא"ל.
- סטנדרטיזציה של מספרי טלפון: השתמשו בפורמט אחד בשתי המערכות כדי שהבדלי עיצוב לא ימנעו התאמה.
- התחל עם סנכרון חד כיווני: יש לאכלס תחילה את מערכת ה-CRM ולבדוק את התוצאות לפני שתאפשרו לשינויים לזרום בשני הכיוונים.
- השבתת הפצת מחיקה: יש למנוע מעבר אוטומטי של מחיקות בין מערכות אלא אם כן יש סיבה תפעולית ברורה לאפשר זאת.
- בדיקה עם קבוצה קטנה: התחילו עם 20 אנשי קשר במקום עם כל מסד הנתונים שלכם. קבוצת בדיקה מספיקה כדי לחשוף מיפויי שדות וכללי התאמה שגויים.
בדקו את התוצאה לאחר המחזור הראשון
אל תפסיקו לבדוק כאשר הסינכרון הראשון מדווח כ"הושלם". חלק מהמחברים מפעילים מחזורי התאמה נוספים לאחר ההעברה הראשונית. מסד נתונים שנראה תקין מיד לאחר הריצה הראשונה יכול להשתנות שוב כאשר המחזור המתוזמן הבא מעבד רשומות.
בדיקה בטוחה יותר היא:
מחזור ראשון ← בדיקת רשומות ← המתנה למחזור נוסף ← בדיקה נוספת ← הרחב את קבוצת הסנכרון.
| אל תדלגו על זה: אם קבוצת הבדיקה מייצרת כפילויות, יש לעצור את הסנכרון לפני הרחבתו. תיקון מפתח ההתאמה ומיפויי השדות בשלב זה קל בהרבה מאשר תיקון אותה בעיה באלפי רשומות. |
התאוששות מסנכרון לקוי
אם סנכרון כבר החליף או מחק אנשי קשר, יש לעצור את הסנכרון לפני שתנסה לנקות אותו. אחרת, המחבר יכול להמשיך להחיל את אותו כלל בזמן שאתה מנסה להפוך את השפעותיו.
תהליך השחזור צריך לפעול לפי הסדר הבא:
- השבת את הסנכרון.
- ייצוא המצב הנוכחי של שתי המערכות.
- זהה מתי החלו השינויים הלא רצויים.
- השתמש בהיסטוריית השחזור או הגיבוי הזמינים.
- תיקון כפילויות ורישומים שגויים.
- תקן את תצורת הסנכרון.
- הרץ בדיקה קטנה נוספת לפני חיבור מחדש של מסד הנתונים המלא.
מה גוגל יכולה לשחזר
אנשי הקשר של גוגל מספקים בטל שינויים אפשרות שיכולה לשחזר אנשי קשר למצב קודם במהלך 30 הימים הקודמים. גוגל מציינת שהשחזור יכול להחזיר את רשימת אנשי הקשר למצבה בנקודה נבחרת במהלך תקופה זו.
חלון הזמן של 30 יום זה חשוב משום שהוא מגביל את משך הזמן שיש לך לבטל שינוי בקנה מידה גדול של אנשי קשר מצד גוגל. לפני השחזור, ייצא את אנשי הקשר הנוכחיים שלך מכיוון שאנשי קשר שנוספו לאחר נקודת השחזור שנבחרה ניתנים להסרה בעת שחזור מצב ישן יותר.
גוגל מציינת גם כי לא ניתן לשחזר אנשי קשר שהוסרו לצמיתות מהאשפה באמצעות תהליך שחזור זה.
מה חלון ה-30 יום אינו מכסה
חלון השחזור של גוגל חל על אנשי הקשר של גוגל. הוא אינו משחזר אוטומטית נתונים שנמחקו או נמחקו במערכת היחסים שלכם.
לדוגמה, אם סנכרון משנה מספר טלפון של מערכת CRM ולמערכת ה-CRM אין היסטוריית גרסאות עבור שדה זה, פונקציית הביטול של גוגל לא בהכרח משחזרת את ערך ה-CRM.
אותו הדבר חל על מידע המצורף לרשומת CRM. ייתכן שקל לשחזר את שם איש הקשר ואת כתובת הדוא"ל שלו מייצוא, אך ייתכן שלא ניתן יהיה לשחזר את ההערות, הפעילויות, ההזדמנויות והאינטראקציות עם הלקוחות הקשורות אלא אם כן מערכת ה-CRM תשמור אותן בנפרד.
| מקור שחזור | מה זה יכול לעזור להתאושש | הגבלה |
| ביטול אנשי קשר של גוגל | מצב יצירת קשר קודם בגוגל | מוגבל ל-30 יום |
| אשפה של אנשי קשר של גוגל | אנשי קשר שנמחקו לאחרונה | לא ניתן לשחזר את האשפה שרוקנה לצמיתות |
| סל המיחזור של CRM | רשומות CRM שנמחקו | שימור משתנה בהתאם ל-CRM |
| ביקורת/היסטוריה של CRM | ערכי השדה הקודמים | תלוי ב-CRM ובמעקב המופעל |
| ייצוא CSV | תמונת מצב של נתוני איש קשר | מכיל רק את מה שיוצא |
| אם זה כבר השתבש: כבה את הסנכרון לפני מיזוג כפילויות או שחזור רשומות. לאחר מכן, ייצא את המצב הנוכחי, קבע מתי הבעיה החלה, תקן את הנתונים, תקן את כללי הסנכרון וחבר מחדש רק לאחר בדיקה מבוקרת. אחרת, אותה תצורה פגומה עלולה לשחזר את הבעיה בזמן שאתה מתקנת אותה. |
סנכרון אנשי קשר עם Vtiger One
Vtiger One מחבר את נתוני Google Workspace עם רשומות CRM כך שצוותים יכולים לעבוד עם אנשי קשר, דוא"ל, יומנים, קבצים ופגישות מבלי לתחזק רשומות לקוחות נפרדות לחלוטין.
ההבדל החשוב הוא מה קורה לאחר שאיש קשר מגיע למערכת ה-CRM. איש קשר של מערכת ה-CRM יכול להיות משויך להזדמנויות מכירה, מקרי תמיכה, פעילויות, הערות ואינטראקציות עם לקוחות. הקשר זה אינו שווה ערך למידע הקשר הבסיסי המאוחסן בפנקס כתובות.
זו הסיבה שסנכרון אנשי קשר צריך להיחשב כתהליך ניהול נתונים ולא רק כחיבור בין שתי אפליקציות.
השמיים ניהול קשרי לקוחות הרשומה צריכה להישאר שימושית גם כאשר איש הקשר של גוגל מכיל רק שם, מספר טלפון וכתובת דוא"ל. תהליך ניהול לידים מוסיף את הקשר המכירות שפנקס כתובות אינו מכיל.
פחות עותקים ליישוב
ככל שיותר מערכות מתחזקות עותק משלהן של פרטי הלקוחות, כך תצטרכו לתחזק יותר כללי התאמה וניגוד עניינים.
An פלטפורמת CRM הכל באחד יכול להפחית כפילויות אלו על ידי שמירה על אותו רישום לקוח על ידי צוותי מכירות, שיווק ותמיכה. לאחר מכן, Google Workspace יכול להישאר שכבת הפרודוקטיביות בעוד שמערכת ה-CRM נשארת המערכת שבה מתוחזקות היסטוריית הלקוחות ופעילות העסק.
בדיקות התקנה מעשיות
אם אתם מגדירים את Google Workspace עם Vtiger, עיינו בתחומים הבאים לפני הפעלת סנכרון בכמות גדולה:
- סקירה סנכרון אפליקציות גוגל אפשרויות ולהפעיל רק את השירותים שהצוות שלך משתמש בהם בפועל.
- לאשר את אינטגרציה של גוגל CRM כיוון לפני הסנכרון הראשון.
- החל בקרות אבטחה של CRM למשתמשים שיכולים לנהל או להפעיל אינטגרציות.
- התייחסו לייבוא גדול בפעם הראשונה כאל תכנון הגירת CRM פעילות גופנית במקום שינוי הגדרות שגרתיות.
- אם Gmail הוא מרכזי בתהליך העבודה של הצוות, יש להעריך האם CRM שנבנה עבור גוגל מפחית את מספר המערכות הנפרדות שעובדים צריכים לעדכן.
המטרה אינה לבטל כל אינטגרציה. המטרה היא להבהיר איזו מערכת מחזיקה בכל פיסת מידע של לקוח, אילו שדות יכולים לעבור בין מערכות, ומה קורה כאשר שני משתמשים עורכים את אותה רשומה.
Fשאלות שנשאלו לעתים קרובות
למה מערכת ה-CRM שלי ממשיכה ליצור אנשי קשר כפולים?
מכיוון שהסנכרון אינו יכול להתאים את הרשומה הנכנסת לאיש קשר קיים. התאמה משתמשת בדרך כלל בכתובות דוא"ל, כך שאנשי קשר ללא דוא"ל, אנשי קשר עם כתובות דוא"ל שונות בכל מערכת, או אנשי קשר עם עיצוב לא עקבי עשויים להיחשב כרשומות חדשות.
האם סנכרון חד-כיווני מונע כפילויות?
לא. סנכרון חד-כיווני מונע התנגשויות הנגרמות על ידי שתי המערכות עורכות את אותה רשומה, אך אינו מונע התאמה כושלת. אם המחבר אינו יכול לזהות איש קשר קיים, הוא עדיין יכול ליצור כפילות במערכת היעד.
איזו מערכת מנצחת כאשר איש הקשר משתנה בשתיהן?
התוצאה תלויה בכלל ההתנגשות שתצורתו נקבעה עבור המחבר. ברירת מחדל נפוצה היא last-write-wins, כאשר העריכה האחרונה מחליפה את הערך הקודם. אם שדה מסוים חייב להיות נשלט על ידי מערכת אחת, הגדר את המערכת הזו כמקור האמת עבור השדה שבו המחבר תומך בו.
האם ניתן לשחזר אנשי קשר לאחר סנכרון שגוי?
אנשי הקשר של גוגל יכולים לבטל שינויים שבוצעו ב-30 הימים האחרונים. לא ניתן לשחזר אנשי קשר שהוסרו לצמיתות מהאשפה באמצעות פונקציית הביטול של גוגל. האם ניתן לשחזר נתונים שהוחלפו או נמחקו במערכת ה-CRM תלוי בסל המיחזור, בהיסטוריית הביקורת, בהיסטוריית הגרסאות או בגיבויים הזמינים של מערכת ה-CRM.
האם כדאי לי לכבות את סנכרון המחיקה?
עבור רוב הצוותים, השבתת הפצת מחיקות היא הבחירה הבטוחה יותר, אלא אם כן זרימת העבודה דורשת זאת במפורש. אחרת, מחיקה עלולה לעבור מגוגל למערכת ה-CRM ולהסיר את הרשומה ואת היסטוריית העסק המשויכת אליה.
איך אני מתכונן לפני הפעלת סנכרון אנשי קשר?
ייצוא שתי המערכות, הסרת כפילויות קיימות, בדיקת הכיסוי של מפתח ההתאמה שלך, סטנדרטיזציה של פורמטי הטלפון, התחל עם סנכרון חד-כיווני, השבתת הפצת מחיקה ובדיקת המחזור הראשון עם קבוצה קטנה לפני סנכרון מסד הנתונים המלא.
מדוע הופיעו כפילויות לאחר שהסנכרון נראה בתחילה תקין?
חלק מהמחברים מבצעים התאמה במחזורים מתוזמנים מאוחרים יותר. לכן, ההפעלה הראשונה עשויה להיראות מוצלחת לפני שמחזור עוקב יעבד רשומות נוספות. יש לבדוק את קבוצת הסנכרון שוב לאחר מחזור מתוזמן נוסף לפני הרחבתה.
מהו מפתח התאמה בסנכרון אנשי קשר?
מפתח התאמה הוא השדה שמחבר משתמש בו כדי להחליט האם רשומה במערכת אחת מייצגת את אותו אדם כמו רשומה באחרת. כתובת דוא"ל היא נפוץ. אם השדה חסר או לא עקבי, המחבר עשוי ליצור איש קשר חדש במקום לעדכן את איש הקשר הקיים.
