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