Kiekvienas klientas nori bendruomenės: vadovas „Pirmiausia apibrėžk, tada kurk“

Santrauka

Pirmojo įvadinio pokalbio metu beveik kiekvienas narystės klientas sako „norime bendruomenės“ — ir ši frazė gali tyliai išplėsti projektą į portalą su forumais, renginiais, kursais ir tiesioginėmis patalpomis, kurių paleidimo metu niekas nenaudos. Šis straipsnis agentūroms pateikia pakartojamą apimties nustatymo pokalbį, kaip tą neaiškų prašymą paversti maža, pristatoma narystės svetaine. Jis prasideda sakinio testu („nariai moka, nes gauna ___“), priverčia klientą pasirinkti vieną verslo modelį, atideda bendruomenės funkcijas, kol atsiras reali auditorija, ir traktuoja kiekvieną funkcijos prašymą kaip pakeitimą. Straipsnyje pateikiamas vienas praktinis pavyzdys, kai klientas norėjo pilnos bendruomenės, o vietoj to paleido ieškomą archyvą ir kas mėnesį vykstantį tiesioginį klausimų atsakymų seansą. Taip pat įspėjama nežadėti įsitraukimo: gali pristatyti duris, bet negali priversti žmonių pro jas įeiti. Rezultatas — produktų linija, o ne gelbėjimo misija, ir klientai, kurie dėkoja už tai, ko atsisakėte kurti.

Pirmojo įvadinio pokalbio metu klientas sako: „Norime bendruomenės.“ Jūs linktelite, įsirašote žodį į užrašus ir jaučiate, kaip jūsų planas tyliai padvigubėja. Nes „bendruomenė“ gali reikšti forumą, privačią pokalbių grupę, mokamą prieigą, kursų biblioteką, renginių seriją, narių katalogą arba visus išvardytus dalykus. Jei leisite, kad tai reikštų viską, praleisite ketvirtį kurdami dalykus, kurių niekas nenaudos, o paskui išrašysite klientui sąskaitą už tai, kad žiūrėjote, kaip jie to nenaudoja. Sprendimas nėra gudresnė platforma. Tai nuoširdesnis pokalbis, kurį kiekvieną kartą vedate vienodai, kad jūsų kiti septyni klientai netaptų vienetiniais projektais.

Šis straipsnis parengtas remiantis klausimais, į kuriuos nuolat atsakome šiame darbe. Ne „ką įrankį naudoti“ — tai ateina vėliau — o klausimais, kurie lemia, ar projektas pristatomas laiku, lieka pelningas ir palieka klientui pojūtį, kad žinojote, ką darote.

„Norime bendruomenės“ — ką iš tikrųjų parduodame?

Paprašykite kliento užbaigti vieną sakinį, prieš net paminėdami platformas: „Nariai moka mums, nes gauna ___.“ Štai ir viskas. Jei jie negali įrašyti konkretaus dalyko į tarpą, dar nesate pasirengę pasirinkti platformos, eskizuoti puslapio ar pateikti kainos. Visa narystės svetainė — mokama prieiga, pakopos, įjungtos funkcijos — yra tik to atsakymo pristatymo mechanizmas.

Ką dauguma klientų iš tikrųjų perka sakydami „bendruomenė“, paprastai patenka į keturias kategorijas. Kartodami apimties nustatymą, priverčiame sprendimą patekti į vieną iš jų:

Už ką nariai moka	Ką iš tikrųjų kuriate	Ką galite saugiai atidėti
Turinys (kursai, archyvai, įrankiai)	Uždara biblioteka, mokėjimo srautas, pagrindinis grotuvas	Tiesioginės patalpos, renginių kalendoriai, sertifikatai
Prieiga (produktas, paslauga ar įrankis)	Nario prisijungimas, teisės, paskyros užtvaros	Viešas forumas ir socialinis kanalas
Ryšys (bendraminčiai, atskaitomybė, tinklaveika)	Viena diskusijų erdvė, profiliai, kvietimai	Pilna kursų platforma, turinio dozavimas, sertifikatai
Statusas (vidiniai, ankstyvoji prieiga, išskirtinės privilegijos)	Pakopinė prieiga, ženklelių/etikečių logika, paprastos privilegijos	Forumai, vartotojų kuriamas turinys, tiesioginiai renginiai

Lentelė yra apimties nustatymo apgaulės lapelis, o ne meniu. Klientas gauna vieną kategoriją. Jei jie bando sujungti dvi, turėtumėte pakelti ranką ir sulėtinti tempą, nes jūsų išlaidos ką tik padidėjo. Spąstai yra daryti visus keturis vienam klientui ir vadinti tai „aktyvia bendruomenės platforma“. Tai ne produktas; tai portalas, o portalai laiku nepaleidžiami.

Ši lentelė sąmoningai maža. Kai tik leidžiate narystės svetainei būti keturiems dalykams vienu metu, nustojate kurti produktą ir pradedate valdyti mažą žiniasklaidos įmonę. Klientas retai nori žiniasklaidos įmonės; jis nori nuolatinių pajamų. Išlaikykite apimtį pakankamai mažą, kad pajamų modelis būtų matomas iš pagrindinio puslapio.

Kai klientas tame pačiame sakinyje pasako „kursas“ ir „forumas“, paklauskite, kuris iš jų apmoka sąskaitas. Jei atsakymas yra „abu“, iš tikrųjų matote klientą, kuris dar nežino, ką parduoda. Kai kurie išsiaiškina to per apimties nustatymą ir grįžta su aiškesniu pasiūlymu; tie, kurie neišsiaiškina, sako jums, kad jie dar nepasiruošę. Tai naudinga sužinoti prieš rašant pasiūlymą, o ne po jo.

Bet jie jau šimtą kartų pasakė „bendruomenė“

Čia pateikiu prieštaringą mintį, ir tai nėra kuklus pasigyrimas: dauguma narystės svetainių iš viso neturėtų paleisti bendruomenės funkcijų. „Bendruomenė“ nėra funkcija. Tai elgsena, kuri atsiranda, kai maža grupė žmonių gauna nuolatinę naudą vieni iš kitų, ir jokia platforma negali to sukurti pagal poreikį. Šis žodis tapo „prenumeratos pajamų“ pakaitalu, todėl kiekvienas klientas jį sako. Būsite jiems naudingesni, išversdami tai atgal.

Atlikite bendruomenės realybės patikrą, prieš leisdami apimčiai išaugti. Užduokite tris klausimus:

1. Pirmąją savaitę, kokį tikslų elgesį norite, kad naujas narys atliktų? (Ne „įsitrauktų“ — „parašytų prisistatymą“, „paliktų komentarą“, „baigtų pirmąją pamoką“.)
2. Kas jūsų komandoje pirmąjį mėnesį praleis laiko šioje erdvėje, atsakydamas, vadovaudamas ir tvarkydamas netvarką?
3. Ar jau yra saujelė žmonių, kurie turi šią problemą ir pažįsta vieni kitus, ar tikitės, kad nepažįstamieji taps komanda vien todėl, kad svetainė egzistuoja?

Jei į visus tris klausimus gaunate neaiškius atsakymus, kuriate ne bendruomenę; kuriate tuščią kambarį ir vadinate tai architektūra. Praktinis žingsnis — atidėti visas bendruomenės funkcijas ir vietoj to paleisti narystės skeletą. Visada galite pridėti diskusijų erdvę vėliau, o kai pridėsite ją prie grupės, kuri jau turi priežasčių ateiti, ji turės galimybę veikti. Visas klausimas nusipelno ilgesnio aptarimo — bendruomenė turėtų ateiti po to, kai turite realių narių — tačiau vieno sakinio versija: nestatykite amfiteatro, kol auditorijos dar nėra.

Kas yra mažiausias dalykas, kuris galėtų veikti?

Kai klasifikavote pasiūlymą, suprojektuokite paleidimą kaip skeletą. Viena mokėjimo parinktis, viena pakopa, vienas užtvertas turtas, vienas komunikacijos ciklas. Paimkite savo platformos funkcijų sąrašą ir išjunkite viską kita. Taip, platforma gali tiesioginius vaizdo kambarius, narių profilius, renginių valdymą ir analitikos skydelius. Būtent tai ir yra problema.

Vienas klientas atėjo pas mus su tuo, ką jie vadino pilna bendruomenės vizija savo B2B SaaS produktui. Jie kalbėjo apie forumus, renginių kalendorių, išteklių biblioteką ir „narių akcentų“ skyrių. Apimties nustatymo metu privertėme juos užbaigti sakinį: „Nariai moka, nes gauna ___.“ Jų atsakymas buvo ieškomas įkūrėjo patarimų archyvas ir kas mėnesį vykstantis tiesioginis klausimų-atsakymų seansas. Todėl būtent tai ir paleidome. Jokio forumo, jokių narių profilių, jokio renginių kalendoriaus. Netrukus archyvas buvo naudojamas, klausimų-atsakymų sesija turėjo nuolatinius dalyvius, o klientas paprašė privačios diskusijų grupės, nes nariai jau kalbėjosi vieni su kitais už produkto ribų. Grupė buvo sukurta po to, kai atsirado priežastis egzistuoti. Tokia tvarka veikia.

Jei būtume sukūrę pilną viziją, būtume paleidę vėlai, su daugiau judančių dalių ir be galimybės pasakyti, kuri iš jų iš tikrųjų sukūrė įprotį. Archyvas galėjo parodyti realų elgesį; tiesioginis kambarys, kuris niekada nebuvo naudojamas, būtų buvęs tik sąskaita. Pamoka nuobodi, bet patikima: kuo mažesnis paleidimas, tuo didesnė tikimybė, kad klientas galės pasakyti, kas iš tikrųjų veikia. Liesas produktas taip pat suteikia erdvės gerai atlikti kitą dalyką — pridėti pakopą, atidaryti forumą — kaip sąmoningą pakeitimą, o ne skubotą papildomą darbą, įspraustą į paleidimo mėnesį. Jei ieškote pakartotino būdo galvoti apie pakopas ir pajamų struktūrą, tai yra straipsnis apie narystės pakopas nuolatinėms pajamoms, bet pirmiausia yra apimties nustatymas.

Kas atsitinka, kai prašymai kaupiasi?

Būkime sąžiningi, kaip miršta dauguma narystės projektų: ne dėl nekompetencijos, o dėl „dar vieno dalyko“. Klientas pamato konkurento bendruomenės demonstraciją ir nori atitinkančios funkcijos. Teisingas atsakymas yra ne „taip“ ir ne „ne“ — tai „įtraukime tai į atidėtų funkcijų sąrašą“.

Padarykite atidėtų funkcijų sąrašą pirmos klasės projekto rezultatu. Įtraukite jį į pasiūlymą, laikykite matomą ir prie jo pridėkite kiekvieną su apimtimi nesusijusį prašymą. Kiekvienam elementui suteikite aktyvavimo sąlygą. Ne „kažkada“, o „tai pristatoma, kai 200 aktyvių narių erdvėje bus mėnesį“ arba „kai klientas įsipareigos skirti dvi valandas darbuotojų laiko per savaitę moderavimui“. Jūs nesate sunkūs; jūs suteikiate funkcijai priežastį egzistuoti.

Taip nustojate iš naujo kurti tą pačią narystės svetainę kiekvienam klientui: traktuodami kiekvieną naują klientą kaip jau pristatyto skeleto konfigūraciją, su sąrašu dalykų, kurių sąmoningai nesukūrėte. Jei funkcija yra atidėtų sąraše, tai ateities projektas, kuris taip pat yra ateities pajamos. Taip pateikę, klientas paprastai sutinka.

Kaip neleisti klientui kaltinti mūsų dėl tuščio forumo?

Turite nustatyti lūkesčius dėl to, ką galite ir ko negalite kontroliuoti, anksti ir raštu. Galite pristatyti mokėjimo srautą, užtvaras, el. laiškų automatizavimą ir dizainą. Negalite pristatyti žmonių, kurie nusprendžia kalbėtis vieni su kitais. Kliento „įsitraukimo problema“ nėra kūrimo problema; tai veiklos problema, ir ji yra jų atsakomybė.

Tai svarbu, nes klientai tyliai pradės klausti, kodėl „bendruomenė“ tyli praėjus trims savaitėms po paleidimo. Jei nustatėte ribą nuo pat pradžių, galėsite vesti naudingą pokalbį apie paskatas ir įsėjimą. Jei ne, derinsite platformą, kuri nėra sugedusi. Praktinis būdas tai įforminti: įtraukite atskirą eilutę „bendruomenės priegloba ir įsėjimas“ į savo priežiūros užmokestį arba duokite klientui įsėjimo kontrolinį sąrašą, kuris yra jų projekto įvade. Esmė — aiškiai apibrėžti darbo pasidalijimą. Įrankis nėra išlaikymo strategija; narystės svetainių mitai paprastai yra kaltininkas, kai žmonės tikisi, kad platforma parduos už juos.

Kai jie vis tiek reikalauja bendruomenės, ką įjungiame?

Jei klientas išlaiko realybės patikrą ir tikrai veda bendruomenę, įjunkite tik vieną diskusijų formatą. Ne tris. Forumas yra gijinis, ieškomas ir asinchroninis; tiesioginis kambarys yra momentinis, trumpalaikis ir reikalaujantis daug darbuotojų. Negalite gerai moderuoti abiejų su maža komanda, o bandydami tai padaryti išmokysite klientą, kad „bendruomenė“ reiškia nuolatinę veiklą, o toks standartas neturėtumėte žadėti.

Praktinė taisyklė: viena erdvė, vienas formatas, vienas paskirtas moderatorius. Pasirinkite formatą, atitinkantį elgesį, kurį nustatėte realybės patikros metu. Jei norimas elgesys yra „atsakyti į klausimą ir gauti atsakymą“, pradėkite nuo forumo. Jei tai „ateik antradienį vidurdienį aptarti iššūkių“, pradėkite nuo tiesioginio renginio. Tada nustatykite lengvą metriką pirmosioms devyniasdešimčiai dienų: ne bendrą narių skaičių, ne registracijas, o skaičių narių, kurie tikslinį elgesį atliko bent du kartus. Dviejų paminėjimų pakanka, kad sužinotumėte, ar erdvė gyva, ar muziejus.

Kaip tai įkainoti, kad būtų produktų linija, o ne gelbėjimo misija?

Padarykite patį atradimo pokalbį apmokamu produktu. Sukurkite fiksuoto mokesčio narystės svetainės įdiegimo paketą, kurį sudaro apimties nustatymo pokalbis, skeleto kūrimas (taip, tikrai), mokėjimo konfigūracija ir vienas pataisymų ratas. Viskas, kas viršija tai — bendruomenės dizainas, pasirinktinės funkcijos, moderavimo valandos, integracijos — yra atskira darbų apimtis. Tai ir yra visas triukas. Kai kiekvieną pasirenkamą funkciją įkainojate kaip pakeitimą, klientas staiga išmoksta prioritetizuoti. Kai viską supakuojate į vieną didėjantį įvertinimą, mokate juos, kad daugiau apimties yra nemokama.

Pakartotinas procesas atrodo taip: klausimynas, kurį išsiunčiate prieš pokalbį, vieno puslapio darbų apimtis su fiksuota kaina, statybos grafikas, kurį jūsų komanda jau vykdė anksčiau, ir atidėtų funkcijų sąrašo šablonas. Turėtumėte galėti pasakyti klientui paleidimo datą, dar prieš egzistuojant dizaino moodboardui. Taip pat gaunate geresnį pokalbį: klientas mato, kiek kainuoja minimalus rinkinys, kiek kainuoja bendruomenės papildymai ir kiek kainuoja jų paties laikas. Jei jie dvejoja mokėti už skeletą, apie tai sužinosite dar neskaudant.

Dalis, kurios niekas nenori girdėti

Kiekviena narystės svetainė yra statymas dėl pasikartojančio elgesio. Platforma yra tik vokas. Jūsų darbas, kaip žmogaus, kuris tai kuria daugeliui klientų, yra užadresuoti ir antspauduoti voką, užtikrinant, kad niekas neįsipareigojo ranka pristatyti gyvo pasirodymo. Negalite priversti bendruomenės atsirasti. Galite sukurti sąlygas, pasirinkti mažiausią įmanomą versiją ir duoti klientui aiškų sąrašą, ko nekuriate.

Paskutinė dalis yra tikroji jūsų vertė. Klientas pasamdė jus, nes nemato, ką palikti neįtraukta. Taigi palikite tai jiems — užtikrintai, sąmoningai, raštu. Kai nustatėte apimtį, pristatymas tampa beveik nuobodus: narystės svetainių paleidimai tikrai išleidžiami, kai jie maži ir sprendimai priimti iš anksto. Tušti forumai ir išsiplėtę pasirinktiniai portalai yra brangūs. Skeletas, pristatytas laiku, vertas kur kas daugiau nei „galinga bendruomenės platforma“, kuri taip ir nebuvo paleista.