כל לקוח רוצה קהילה: המדריך להגדרת היקף לפני בנייה

תקציר

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

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

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

"אנחנו רוצים קהילה" — מה אנחנו בעצם מוכרים?

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

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

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

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

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

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

אבל הם כבר אמרו "קהילה" מאות פעמים

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

בצע בדיקת מציאות לקהילה לפני שאתה נותן להיקף לגדול. שאל שלוש שאלות:

1. בשבוע הראשון, איזו התנהגות מדויקת אתה רוצה שחבר חדש יעשה? (לא "להתערב" — "לפרסם היכרות," "להשאיר תגובה," "לסיים את השיעור הראשון.")
2. מי בצוות שלך יבלה זמן במרחב הזה במהלך החודש הראשון, יענה, ינתב ויפנה את העומס?
3. האם יש כבר חופן אנשים שיש להם את הבעיה הזו ומכירים זה את זה, או שאתה מקווה שזרים יהפכו לצוות בגלל שהאתר קיים?

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

מהו הדבר הקטן ביותר שיכול לעבוד?

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

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

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

מה קורה כשהבקשות נערמות?

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

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

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

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

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

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

כשהם מתעקשים על קהילה בכל זאת, מה אנחנו מפעילים?

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

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

איך אנחנו מתמחרים את זה כקו מוצרים, לא משימת חילוץ?

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

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

החלק שאף אחד לא רוצה לשמוע

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

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