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