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