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