לקוח חדש נרשם, צוות המכירות חוגג, והדשבורד מציג עלייה במספר המשתמשים. חודש אחר כך, אותו לקוח כמעט לא נכנס למערכת, לא השלים את תהליך ההטמעה, ובסוף גם לא חידש. זו הסיבה שמדדי מוצר SaaS אינם יכולים להסתכם במספר ההרשמות או במסך יפה של נתונים. המדדים הנכונים צריכים להראות אם המוצר יוצר ערך חוזר, היכן המשתמשים נתקעים, ואילו החלטות פיתוח באמת משפרות את העסק.
במוצר SaaS, נתון ללא הקשר עלול לייצר ביטחון כוזב. צמיחה במספר החשבונות אינה בהכרח צמיחה בהכנסות, עלייה בשימוש אינה בהכרח שימוש בעל ערך, ושיעור נטישה נמוך בתחילת הדרך עשוי פשוט להעיד שהלקוחות עדיין בתוך תקופת ניסיון. לכן המדידה צריכה להתחיל במודל העסקי ובתהליך העבודה שהמוצר אמור לשפר - ורק אחר כך בכלי האנליטיקה.
מדדי מוצר SaaS מתחילים בהגדרת ערך
לפני בחירת מדד, צריך לענות על שאלה אחת בצורה מדויקת: מהו הרגע שבו לקוח מקבל את הערך שהובטח לו? בפלטפורמה לניהול לידים זה יכול להיות ליד שמנותב אוטומטית לאיש המכירות הנכון. במערכת לניהול תפעול, זה עשוי להיות תהליך שאושר, בוצע ותועד ללא העברה ידנית בין מערכות. בכלי BI, הערך יכול להיות דוח שמאפשר למנהל לקבל החלטה בזמן.
רגע הערך הזה הוא הבסיס להגדרת מדד הפעלה, או Activation. לא מדובר בהכרח בפתיחת חשבון או בהתחברות ראשונה. משתמש שהתחבר, הסתכל במסך ויצא, עדיין לא הוכיח שהמוצר עובד עבורו. מדד הפעלה טוב יתאר פעולה שיש לה משמעות עסקית: חיבור מקור מידע, הקמת אוטומציה ראשונה, הזמנת חברי צוות, או השלמת תהליך ליבה.
הבחירה תלויה במורכבות המוצר. במוצר פשוט אפשר להגדיר הפעלה כבר בפגישה הראשונה. במוצר ארגוני הכולל הרשאות, אינטגרציות ותהליכי אישור, הגיוני למדוד הפעלה לאורך כמה שלבים. העיקר הוא להימנע מהגדרה נוחה מדי רק משום שקל לאסוף אותה.
לא כל שימוש מעיד על אימוץ
מספר משתמשים פעילים יומיים או חודשיים הוא מדד שימושי, אך אינו תשובה מספקת. מערכת יכולה להציג אלפי כניסות בגלל שמשתמשים מחפשים מידע, מתקנים תקלות או נאלצים לבצע עבודה ידנית שהמוצר היה אמור לחסוך. שימוש גבוה הוא סימן שדורש פירוש, לא הוכחה להצלחה.
כדאי להבחין בין שלוש שכבות. הראשונה היא הגעה למוצר: כמה משתמשים נכנסו. השנייה היא שימוש בפיצ'ר: כמה ביצעו פעולה מסוימת. השלישית, והחשובה ביותר, היא תוצאה: כמה השלימו פעולה שמקדמת את התהליך העסקי של הלקוח.
לדוגמה, מערכת תפעולית יכולה למדוד כמה משתמשים פתחו משימה, כמה הקצו אותה, וכמה משימות נסגרו בתוך זמן היעד. אם שיעור פתיחת המשימות עולה אבל שיעור הסגירה יורד, הבעיה אינה בהכרח באימוץ. ייתכן שהממשק לא ברור, שההתראות יוצרות עומס, או שהאוטומציה מייצרת משימות לא רלוונטיות.
במקום להסתפק במדד יחיד, הגדירו אירועי מוצר סביב מסלול עבודה שלם. כך אפשר לזהות האם משתמשים נתקעים לפני פעולה קריטית, חוזרים שוב ושוב לאותו מסך, או זונחים תהליך לאחר חיבור אינטגרציה מסוימת.
המדדים שמחברים מוצר להכנסות
מוצר SaaS חייב לייצר ערך למשתמשים, אבל גם מודל הכנסות יציב. לכן מדידת מוצר ומדידת הכנסות צריכות להיות מחוברות, גם כאשר הצוותים שמנהלים אותן שונים.
הכנסה חודשית חוזרת, MRR, מציגה את היקף ההכנסות המנוייות בחודש נתון. הכנסה שנתית חוזרת, ARR, שימושית יותר לתכנון שנתי ולחברות עם חוזים ארוכים. שני המדדים חשובים, אך ללא פילוח הם יכולים להטעות. צמיחה ב-MRR שמגיעה בעיקר מלקוחות חדשים אינה בהכרח בריאה אם לקוחות ותיקים עוזבים או מצמצמים שימוש.
כאן נכנס מדד שימור הכנסות נטו, NRR. הוא בוחן מה קרה להכנסות מאותה קבוצת לקוחות לאורך זמן, לאחר שדרוגים, הרחבות, צמצומים ונטישות. NRR מעל 100% מצביע על כך שההכנסות מהלקוחות הקיימים גדלות במצטבר. זהו סימן חזק להתאמת מוצר-שוק, אך גם כאן יש הסתייגות: לקוח ארגוני אחד גדול יכול לעוות את התמונה. לכן יש לפלח לפי גודל לקוח, מסלול תמחור, ענף ותקופת הצטרפות.
מדד נוסף הוא עלות גיוס לקוח, CAC, ביחס לערך החיים של הלקוח, LTV. היחס הזה עוזר להבין אם אפשר להשקיע בצמיחה בלי לבנות מודל הפסדי. עם זאת, בשלבי MVP מוקדמים, LTV הוא לעיתים תחזית לא יציבה ולא עובדה. במצב כזה עדיף להתמקד במשך הזמן עד שהלקוח מגיע לערך, בשיעור ההפעלה ובסיכויי החידוש הראשונים, ולא להעמיד פנים שיש ודאות פיננסית מלאה.
שימור הוא מבחן האמת של המוצר
שיעור נטישה, Churn, הוא מדד מרכזי, אבל צריך להחליט מה בדיוק נוטשים: משתמשים, חשבונות או הכנסות. במוצר שמבוסס על צוותים, משתמש בודד יכול להפסיק להיכנס בלי שהחשבון כולו בסיכון. במערכת עם שימוש אישי, נטישת משתמשים עשויה להיות האות המוקדם ביותר לבעיה.
הדרך הנכונה להבין שימור היא באמצעות קבוצות הצטרפות, או Cohorts. בוחנים לקוחות שהצטרפו באותו חודש או דרך אותו ערוץ, ואז בודקים כמה מהם ממשיכים לבצע את פעולת הליבה לאחר שבוע, חודש או רבעון. כך אפשר לזהות אם עדכון מוצר שיפר את ההפעלה, אם קמפיין הביא קהל לא מתאים, או אם לקוחות ממגזר מסוים זקוקים לתהליך הטמעה אחר.
חשוב למדוד גם נטישה שקטה. לקוח יכול להמשיך לשלם במשך חודשים, במיוחד בחוזה שנתי, אך להפסיק לקבל ערך מהמוצר. ירידה בתדירות פעולות הליבה, פחות משתמשים פעילים בצוות, או כשל חוזר בסנכרון נתונים הם אותות שדורשים התערבות לפני מועד החידוש.
אמינות טכנית היא מדד מוצר, לא רק מדד פיתוח
כשמערכת SaaS מנהלת לידים, חשבוניות, הזמנות או תהליכים תפעוליים, תקלה אינה רק אירוע טכני. היא פוגעת באמון, מאריכה עבודה ידנית ולעיתים מייצרת נזק ישיר להכנסות הלקוח. לכן זמינות, זמן תגובה, שיעור שגיאות והצלחת אינטגרציות צריכים להופיע באותה תמונת ניהול שבה מופיעים נתוני שימוש ושימור.
זמינות גבוהה כשלעצמה אינה מספיקה. מערכת יכולה להיות זמינה אך איטית, או להעביר בקשות בהצלחה טכנית בזמן שתהליך עסקי נכשל בשל נתון חסר או הרשאה שגויה. מדדו את הצלחת התהליך מקצה לקצה: ליד שנקלט, נותב, קיבל תגובה ותועד ב-CRM; הזמנה שנוצרה, שולמה והועברה למערכת התפעול; אוטומציה שרצה בלי התערבות ידנית.
גישה זו משנה גם את סדרי העדיפויות בפיתוח. במקום לרדוף אחר פיצ'רים שמייצרים הדגמה טובה, אפשר לזהות צווארי בקבוק שמסכנים שימור: זמני טעינה במסך קריטי, כשלי API אצל לקוח גדול, או תהליך הרשאות שמונע מהצוות להתחיל לעבוד.
כך בונים מסגרת מדידה שאפשר לנהל לפיה
הטעות הנפוצה היא להתחיל מאיסוף אינסופי של אירועים ואז לחפש משמעות בדיעבד. תהליך מדידה אפקטיבי עובד בכיוון ההפוך: מגדירים החלטות, מזהים את הנתונים הדרושים להן, ורק אז מתכננים את ההטמעה הטכנית.
בשלב האפיון, הגדירו את יעד העסק לשישה עד שנים-עשר החודשים הקרובים. האם המטרה היא להוכיח ביקוש, לשפר המרה מניסיון לתשלום, לצמצם נטישה או להתרחב ללקוחות גדולים? לכל יעד יש מדד מוביל ומדד תוצאה. לדוגמה, כדי לשפר חידושים, מדד התוצאה יהיה שימור הכנסות, ומדדים מובילים יכולים להיות השלמת הטמעה, שימוש בפעולת הליבה ופתרון תקלות בתוך זמן מוגדר.
לאחר מכן, מנסחים מילון מדדים. לכל אירוע צריך להיות שם עקבי, הגדרה ברורה, מקור נתונים, בעלים עסקי ותנאים למדידה. ללא משמעת כזו, אותו "לקוח פעיל" יקבל הגדרה אחרת אצל מוצר, מכירות והנהלה, והדשבורד יהפוך למקור לוויכוחים במקום לכלי החלטה.
לבסוף, יש לקבוע קצב פעולה. מדדים תפעוליים כמו שגיאות או זמינות דורשים ניטור רציף. מדדי הפעלה ושימוש אפשר לבחון שבועית. שימור והכנסות דורשים לרוב הסתכלות חודשית ורבעונית. אין צורך להגיב לכל תנודה קטנה, אבל כל מדד חייב להיות מחובר לפעולה אפשרית: שינוי במסלול ההטמעה, תיקון זרימת עבודה, עדכון תמחור או השקעה בתשתית.
ב-DevCo Solutions אנחנו מתייחסים למדידה כחלק מארכיטקטורת המוצר, לא כתוספת שמחברים אחרי ההשקה. כשאירועים, אינטגרציות ודשבורדים מתוכננים לפי תהליך העבודה האמיתי, ההנהלה מקבלת תמונה אמינה יותר והצוות יודע מה לבנות קודם.
הדשבורד הטוב ביותר אינו זה שמציג הכי הרבה גרפים. הוא זה שמאפשר ביום שני בבוקר להצביע על בעיה, להבין את השפעתה על הלקוחות, ולהחליט מי מטפל בה ומה ייחשב שיפור. זו הנקודה שבה נתונים מפסיקים להיות דיווח והופכים למערכת ניהול מוצר.