A CRM that actually works: why implementations fail and how to prevent it
Most CRM rollouts fail for the same three reasons, and none of them is technological. How to build a system your team really uses.
כמעט כל ארגון שאני פוגש כבר ניסה CRM. אצל חלקם הוא פעיל חלקית, אצל אחרים הוא קיים אך ריק, ואצל רבים הוא הפך לשדה טקסט חופשי אחד גדול. המערכת כמעט אף פעם לא אשמה.
סיבה ראשונה: המערכת נבנתה סביב דוחות ולא סביב עבודה
כשמעצבים CRM לפי מה שההנהלה רוצה לראות, מקבלים טופס עם עשרים שדות חובה שהעובד בשטח ממלא בלחץ ובבדיחות. דאטה שנאספה בכפייה היא דאטה גרועה. התחילו דווקא מהשאלה מה מקל על מי שמזין, ורק אחר כך מה מפיקים.
סיבה שנייה: אין הגדרה אחת מוסכמת
מה זה «ליד»? מתי פנייה נחשבת «סגורה»? אם שני אנשים בארגון עונים אחרת, כל דוח שתפיקו יהיה חסר משמעות. מילון מונחים קצר — עמוד אחד, עשרה מושגים — שווה יותר מכל מודול מתקדם.
סיבה שלישית: המידע לא מגיע לשם לבד
אם עדכון רשומה דורש כניסה נוספת, העתקה ידנית, או זכירה — זה לא יקרה. המערכת צריכה להתמלא כתוצר לוואי של העבודה הרגילה: מהטופס באתר, מהמייל, מהשיחה. כל נקודה שבה בן אדם מעתיק ידנית בין מערכות היא נקודה שבה הדאטה תמות.
CRM אינו מקום שבו רושמים מה עשיתם. הוא המקום שבו העבודה עצמה מתרחשת.
בדיקת איכות דאטה בחמש דקות
- כמה רשומות כפולות יש על אותו שם או אותו מספר טלפון?
- באיזה אחוז מהרשומות שדה הסטטוס ריק או «אחר»?
- מתי עודכנה בפועל הרשומה הממוצעת?
- כמה מידע קריטי קיים רק במייל של אדם מסוים?
- האם מישהו יודע מי אחראי על נכונות הנתונים?
אם התשובות מדאיגות, זה לא כישלון — זו נקודת פתיחה. ניקוי דאטה הוא העבודה הכי פחות זוהרת ובעלת ההחזר הגבוה ביותר בכל פרויקט מערכות.
מה לעשות לפני שמחברים AI
AI על גבי דאטה גרועה מייצר תשובות גרועות בביטחון רב. סדרו קודם את ההגדרות, את הכפילויות ואת מקור האמת לכל סוג מידע. השקעה של חודש כאן חוסכת שנה של תיקונים אחר כך.
Questions & answers
כדאי להחליף מערכת או לתקן את הקיימת?
ברוב המקרים לתקן. החלפה מעבירה את אותן בעיות למערכת חדשה, רק עם עלות הגירה נוספת. החליפו כשהמערכת באמת חוסמת תהליך מרכזי, לא כשהיא פשוט לא נוחה.
כמה שדות חובה זה יותר מדי?
אם אי אפשר למלא רשומה חדשה בפחות מדקה, הצוות ימצא דרך לעקוף אותה.
