מסלול חינמי במוצר תוכנה: איך מאפיינים מכסות ושינויי מסלול?

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

מה מלמד השינוי ההיסטורי של Flickr?

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

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

מתחילים בערך שהמשתמש אמור לקבל

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

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

מפרידים בין מכסה, קצב ותקופת ניסיון

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

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

מגדירים מה קורה בגבול לפני שכותבים קוד

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

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

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

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

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

מתכננים שינוי בלי להמציא מדיניות בזמן תקלה

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

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