עיצוב התוכניות שלך

התחילו ממצבי לקוח שונים

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

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

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

כתבו את ההבטחה לפני רשימת התכונות

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

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

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

השתמשו במטריצת FitSite כדוגמת עבודה

• Starter — המחשה בלבד, $49 לחודש: אתר אחד לסטודיו עם תבנית Studio Essential, מידע עסקי בסיסי ודרך ליצירת קשר. ציינו בבירור אם קישורי הזמנות ודומיינים מותאמים אישית כלולים.
• Growth — המחשה בלבד, $99 לחודש: אתר אחד עם אפשרויות תבנית נוספות ותהליך הזמנות או תוכן שנבדק ומתאים לקונה. כללו גבולות תמיכה ואינטגרציה.
• Pro — המחשה בלבד, $199 לחודש: תמיכה בהסדר מוסכם של ריבוי מיקומים, כגון עד חמישה אתרים, עם התבניות הרלוונטיות והיקף התחזוקה.

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

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

תרגמו את המטריצה להגדרות מוצר

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

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

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

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

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

לקוח צריך להבין מה משתנה בעת מעבר בין תוכניות. ב-Ultimate Multisite, בדקו את הגדרות קבוצת התוכניות והשדרוג/הורדת הדרגה עבור הגרסה המותקנת, ולאחר מכן בדקו את המעברים המותרים. סדר חזותי כגון Starter, Growth, Pro שימושי רק כאשר התנהגות המעבר הבסיסית תואמת לו.

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

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

הוסיפו תוספות אופציונליות במשורה

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

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

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

לפני שממשיכים

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

מקורות וקריאה נוספת

עובד מתוך השיעור המקורי לעסקי אתרים. Ultimate Multisite: תוכניות, מגבלות ובקרות תוספים

השיעור הקודם · עיינו בכל 14 השיעורים