Всеки клиент иска общност: Ръководството „Определи обхвата, преди да построиш“

Резюме

На първото въвеждащо обаждане почти всеки клиент за членски сайт казва „искаме общност“ — и тази фраза може тихо да разшири проекта до портал с форуми, събития, курсове и стаи за живо предаване, които никой няма да използва при стартирането. Тази статия дава на агенциите повтарящ се разговор за определяне на обхвата, за да превърнат това неясно искане в малък, доставящ се членски сайт. Започва с теста на изречението („членовете плащат, защото получават ___“), принуждава клиента да избере един бизнес модел, отлага функциите за общност, докато не се появи реална публика, и третира всяко искане за функция като заявка за промяна. Статията включва един работен пример за клиент, който искаше пълна общност и вместо това стартира архив с възможност за търсене плюс месечни въпроси и отговори на живо. Тя също предупреждава да не обещавате ангажираност: можете да доставите вратата, но не можете да накарате хората да минат през нея. Резултатът е продуктова линия вместо спасителна мисия и клиенти, които ви благодарят за това, което сте отказали да построите.

На първото въвеждащо обаждане клиентът казва: „Искаме общност.“ Вие кимате, записвате думата в бележките си и усещате как пътната карта тихо се удвоява. Защото „общност“ може да означава форум, частна чат група, пейуол, библиотека с курсове, поредица от събития, указател на членове или всичко по-горе. Ако позволите да означава всичко по-горе, ще прекарате три месеца в изграждане на неща, които никой не ползва, а след това ще таксувате клиента за това, че ги гледа как не ги ползват. Решението не е по-умна платформа. То е по-честен разговор, провеждан по един и същ начин всеки път, така че следващите ви седем клиенти да не се превърнат всеки в индивидуален проект по поръчка.

Този материал е изграден около въпросите, на които реално продължаваме да отговаряме в тази работа. Не „кой инструмент да използваме“ — това идва по-късно — а въпросите, които решават дали проектът ще бъде пуснат навреме, ще остане печеливш и ще остави клиента с усещането, че знаете какво правите.

„Искаме общност“ — какво всъщност продаваме?

Накарайте клиента да довърши едно изречение, преди дори да споменете платформи: „Членовете ни плащат, защото получават ___.“ Това е. Ако не могат да попълнят празното място с нещо конкретно, не сте готови да изберете платформа, да скицирате страница или да цитирате цена. Целият членски сайт — пейуолът, нивата, функциите, които оставяте включени — е просто механизмът за доставка на този отговор.

Това, което повечето клиенти всъщност купуват, когато казват „общност“, обикновено попада в четири категории. Когато определяме обхвата многократно, ние насилваме решението в една от тях:

За какво плащат членовете	Частта, която реално изграждате	Частта, която можете спокойно да отложите
Съдържание (курсове, архиви, инструменти)	Ограничена библиотека, платежен поток, основен плейър	Стаи на живо, календари за събития, сертификати
Достъп (продукт, услуга или инструмент)	Вход за членове, права, контрол на достъпа	Публичен форум и социална емисия
Връзка (връстници, отчетност, мрежа)	Едно пространство за дискусии, профили, покани	Пълна курсова платформа, дозирано съдържание, сертификати
Статус (инсайдъри, ранен достъп, ексклузивни привилегии)	Нива на достъп, логика за значки/етикети, прости привилегии	Форум, потребителско генерирано съдържание, събития на живо

Таблицата е измамник за определяне на обхвата, а не меню. Клиентът получава една категория. Ако се опита да слее две, трябва да вдигнете ръка и да забавите темпото, защото разходите ви току-що се увеличиха. Капанът е да правите всичките четири за един клиент и да го наречете „ангажирана платформа за общност“. Това не е продукт; това е портал и порталите не се пускат навреме.

Тази таблица е умишлено малка. В момента, в който позволите на членския сайт да бъде четири неща едновременно, сте спрели да строите продукт и сте започнали да управлявате малка медийна компания. Клиентът рядко иска медийна компания; той иска повтарящи се приходи. Запазете обхвата достатъчно малък, така че моделът на приходи да се вижда от началната страница.

Когато клиент каже „курс“ и „форум“ в едно изречение, попитайте кое плаща сметките. Ако отговорът е „и двете“, всъщност виждате клиент, който все още не знае какво продава. Някои от тях го разбират по време на определянето на обхвата и се връщат с по-ясно предложение; тези, които не го разберат, ви казват, че не са готови. Това е полезно нещо, което да научите, преди да напишете оферта, а не след това.

Но те вече са казали „общност“ сто пъти

Ето контрапункта и това не е скромно хвалене: повечето членски сайтове изобщо не трябва да стартират с функции за общност. „Общност“ не е функция. Това е поведение, което възниква, когато малка група хора получават повтаряща се стойност един от друг и никоя платформа не може да го произведе по поръчка. Думата се е превърнала в заместител на „приходи от абонамент“, поради което всеки клиент я казва. Ще бъдете по-полезни за тях, като я преведете обратно.

Направете проверка на реалността за общността, преди да позволите обхватът да расте. Задайте три въпроса:

1. През първата седмица какво точно поведение искате нов член да извърши? (Не „ангажира се“ — „публикува представяне“, „остави коментар“, „завърши първия урок.“)
2. Кой от вашия екип ще прекарва време в това пространство през първия месец, отговаряйки, насочвайки и разчиствайки безпорядъка?
3. Има ли вече шепа хора, които имат този проблем и се познават, или се надявате непознати да станат екип, защото уебсайтът съществува?

Ако и трите отговора са неясни, вие не изграждате общност; вие строите празна стая и я наричате архитектура. Практическият ход е да отложите всяка функция за общност и вместо това да стартирате скелета на членския сайт. Винаги можете да добавите дискусионно пространство по-късно, а когато го добавите към група, която вече има причини да се появява, то има шанс да проработи. Целият въпрос заслужава по-подробно разглеждане — общността трябва да дойде, след като имате реални членове — но версията в едно изречение е: не строете амфитеатъра, преди публиката да съществува.

Кое е най-малкото нещо, което би могло да проработи?

След като класифицирате офертата, проектирайте стартирането като скелет. Една опция за плащане, едно ниво, един ограничен актив, една комуникационна верига. Вземете списъка с функции на платформата си и изключете всичко останало. Да, платформата може да прави стаи за видео на живо, профили на членове, управление на събития и табла за анализи. Точно това е проблемът.

Клиент дойде при нас с това, което нарече пълна визия за общност за техния B2B SaaS продукт. Говореха за форуми, календар за събития, библиотека с ресурси и секция „В центъра на вниманието членове“. По време на определянето на обхвата ги накарахме да довършат изречението: „Членовете плащат, защото получават ___.“ Техният отговор беше архив с възможност за търсене на съветите на основателя плюс месечни въпроси и отговори на живо. Така че това стартирахме. Без форум, без профили на членове, без календар за събития. Не след дълго архивът се използваше, в Q&A имаше редовни участници и клиентът поиска частна дискусионна група, защото членовете вече си говореха извън продукта. Групата беше изградена, след като имаше причина да съществува. Това е редът, който работи.

Ако бяхме изградили пълната визия, щяхме да стартираме със закъснение, с повече движещи се части и без начин да разберем коя от тях всъщност е създала навика. Архивът можеше да посочи реално поведение; стая на живо, която никога не беше използвана, щеше да бъде просто сметка. Урокът е скучен, но надежден: колкото по-малко е стартирането, толкова по-вероятно е клиентът да ви каже какво всъщност работи. Стройният продукт също ви дава пространство да направите добре следващото нещо — добавете ниво, отворете форум — като умишлена заявка за промяна, а не като бърза добавка, втъпкана в месеца на стартиране. Ако търсите повтарящ се начин да мислите за нивата и структурата на приходите, това е материалът за членски нива за повтарящи се приходи, но определянето на обхвата е на първо място.

Какво се случва, когато заявките се трупат?

Нека бъдем честни как умират повечето членски проекти: не от некомпетентност, а от „още едно нещо“. Клиентът вижда демо на общността на конкурент и иска съответстваща функция. Правилният отговор не е „да“ и не е „не“ — той е „нека го добавим към списъка за отлагане“.

Направете списъка с отложени функции първокласен резултат във вашия проект. Поставете го в офертата, дръжте го видим и добавяйте към него всяка заявка извън обхвата. Дайте на всяка точка условие за задействане. Не „някой ден“, а „това се пуска, когато 200 активни членове са били в пространството в продължение на месец“ или „когато клиентът отдели два часа служителско време на седмица, за да го модерира“. Не сте трудни; давате на функцията причина да съществува.

По този начин спирате да преизграждате същия членски сайт за всеки клиент: като третирате всеки нов клиент като конфигурация на скелет, който вече сте доставили, със списък на нещата, които умишлено не сте построили. Ако дадена функция е в списъка за отлагане, това е бъдещ проект, който е и бъдещ приход. Представете го по този начин и клиентът обикновено ще се съгласи.

Как да предотвратим клиентът да ни обвинява за празния форум?

Трябва да поставите очакванията относно това какво можете и какво не можете да контролирате, рано и в писмен вид. Можете да доставите платежния поток, ограничаването, имейл автоматизациите и дизайна. Не можете да доставите хора, които решават да си говорят помежду си. „Проблемът с ангажираността“ на клиента не е проблем на изграждането; това е операционен проблем и той е в техните ръце.

Това е важно, защото клиентите тихо ще започнат да питат защо „общността“ е тиха три седмици след стартирането. Ако поставите границата от самото начало, можете да проведете полезен разговор за стимули и първоначално захранване. Ако не сте го направили, ще търсите проблеми в платформа, която не е счупена. Практичен начин да го формализирате: включете отделен ред за „хостинг и захранване на общността“ в договора си за поддръжка или дайте на клиента контролен списък за захранване, който е част от стартирането на проекта. Смисълът е да направите разделението на труда изрично. Инструментът не е стратегията за задържане; митовете за членските сайтове обикновено са виновникът, когато хората очакват платформата да върши продажбите вместо тях.

Когато настояват за общност въпреки всичко, какво включваме?

Ако клиентът премине проверката на реалността и наистина управлява общност, включете точно един формат за дискусия. Не три. Форумът е нишковиден, с възможност за търсене и асинхронен; стаята на живо е незабавна, ефимерна и изисква много персонал. Не можете да модерирате добре и двете с малък екип и опитвайки се да го направите, ще научите клиента си, че „общност“ означава постоянна активност, което е стандарт, който не трябва да обещавате.

Практическо правило: едно пространство, един формат, един посочен модератор. Изберете формата, който съответства на поведението, което сте идентифицирали в проверката на реалността. Ако желаното поведение е „задай въпрос и получи отговор“, започнете с форум. Ако е „ела във вторник по обяд, за да обсъдим предизвикателствата“, започнете със събитие на живо. След това задайте лека метрика за първите деветдесет дни: не общ брой членове, не регистрации, а брой членове, които са извършили целевото поведение поне два пъти. Две споменавания на активност са достатъчни, за да знаете дали пространството е живо или музей.

Как да оценим това така, че да е продуктова линия, а не спасителна мисия?

Направете самия разговор за проучване продаваем продукт. Създайте пакет за настройка на членски сайт с фиксирана такса, който включва разговора за определяне на обхвата, изграждането на скелета (да, наистина), конфигурирането на плащанията и един кръг от ревизии. Всичко отвъд това — дизайн на общността, персонализирани функции, часове за модериране, интеграции — е отделна декларация за работа. Това е целият трик. Когато цитирате всяка опционална функция като заявка за промяна, клиентът изведнъж се научава да приоритизира. Когато групирате всичко в една ескалираща оценка, учите ги, че повече обхват е безплатен.

Повтарящ се процес изглежда така: въпросник, който изпращате преди разговора, едностранична декларация за работа с фиксирана цена, график за изграждане, който екипът ви е изпълнявал преди, и шаблон за списъка с отложени функции. Трябва да можете да кажете на клиента датата на пускане, преди да съществува дизайнерското табло. Получавате и по-добър разговор: клиентът вижда колко струва абсолютният минимум, колко струват екстрите за общността и колко струва собственото му време. Ако се поколебаят да платят за скелет, ще научите това, преди да ви заболи.

Частта, която никой не иска да чуе

Всеки членски сайт е залог за повтарящо се поведение. Платформата е просто пликът. Вашата работа, като човек, който изгражда това за много клиенти, е да адресирате и запечатате плика, като се уверите, че никой не се е записал да доставя живо представление на ръка. Не можете да накарате общността да се случи. Можете да създадете условията, да изберете възможно най-малката версия и да дадете на клиента ясен списък на това, което не изграждате.

Последната част е вашата истинска стойност. Клиентът ви е наел, защото не вижда какво да изпусне. Така че го изпуснете за тях — уверено, нарочно, в писмен вид. След като определите обхвата, доставката става почти скучна: стартирането на членски сайт наистина се случва, когато е малко и решенията са взети предварително. Празните форуми и разпръснатите персонализирани портали са скъпи. Скелетът, доставен навреме, струва много повече от „мощната платформа за общност“, която така и не стартира напълно.