חיבור הדיוור ל־CRM: אילו נתונים צריכים לעבור?

מגדירים חוזה נתונים מצומצם

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

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

בוחנים זהות, כפילויות ושינויים מזהים

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

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

מבדילים בין אירועים, מצבים ופעולות

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

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

מתכננים טיפול בכשל לפני הפעלה מלאה

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

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

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