איך לזהות עלויות נסתרות בהצעת מחיר לפרויקט CRM

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

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

איפה מסתתר הפער בין ההצעה למציאות

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

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

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

לפני חתימה, הולכים עם תהליך אחד עד הסוף

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

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

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

איך להבחין בין מחיר זול למחיר חסר

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

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

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

מה כדאי לעשות עם ההצעה לפני שמתקדמים

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

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

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