ענף

חברות טכנולוגיה ותוכנה

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

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

מה מחכה בזמן שבונים את המוצר?

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

איפה מודלים ואוטומציה משתלמים בחברת טכנולוגיה?

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

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

אילו מהפתרונות שלנו מתאימים?

איך מתחילים?

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

שאלות ותשובות

יש לנו מהנדסים. למה לא לבנות את זה לבד?

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

הנתונים שלנו יושבים בבסיס הנתונים של המוצר, ב-CRM ובמערכת החיובים. זה מספיק?

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

זה יכול לרוץ בחשבון הענן שלנו?

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