Zagon članstva, ki dejansko steče.

Povzetek

Ko stranka zaprosi za člansko spletišče, funkcije, ki jih našteje, skoraj nikoli niso produkt. Produkt je ponavljajoče se plačilo v zameno za nekaj konkretnega – in vse ostalo je zamuda, preoblečena v funkcijo. Za agencijo to pomeni standardizacijo pogovora o zagonu: opredelite menjavo vrednosti v enem stavku, določite najmanjši nabor funkcij, ki to podpira, in zavrnite izdelavo po meri za vodovod, ki ga platforma že opravlja. Ta članek obravnava ugovore, ki jih boste slišali od strank in notranjih deležnikov, ter ponuja protargumente, ki ohranjajo časovnico iskreno. Člansko spletišče lahko zaženete v tednih, ne četrtletjih, ko nehate obravnavati 'skupnost' in 'gostovanje tečajev' kot zahtevi za zagon.

Zakaj se vsak projekt članskega spletišča spremeni v devetmesečno epopejo?

Ker še naprej obravnavamo zagon kot trenutek, ko oživi celotna vizija stranke. Nikoli ni. Vizija je preglednica funkcij s prodajne strani platforme; zagon je prva točka, kjer nekdo zamenja denar za dostop. Za agencijo je razlika med izdajo treh članskih spletišč na leto in izdajo enega v zmožnosti, da to razliko glasno poudarite, večkrat, ne da bi stranka imela občutek, da je prikrajšana.

To ni vodnik po določeni platformi. Je terenski vodnik po argumentih, ki jih bodo uporabili proti vam, in robnih primerih, ki bodo poskušali požreti vaš časovni okvir.

"Ne moremo zagnati, dokler se ne zdi dokončano."

Začnite z besedami stranke: "Priložnost za prvi vtis imamo samo enkrat." To velja za njihovo blagovno znamko, ne za njihov seznam funkcij. Le malo članov prekine naročnino, ker prvi dan ni bilo sistema značk; prekinejo jo, ker tisto, za kar so plačali, ni prišlo. Pravzaprav večinoma tiho odidejo, a to je tema za drug članek.

Trg platform za članstvo je zasnovan tako, da ta ugovor še poslabša. Standardni meni izdelkov vključuje prostore za razprave, sobe za video v živo, profile članov, upravljanje dogodkov, analitiko, gostovanje tečajev, obdelavo plačil in večstopenjski dostop – vse v eni naročnini. Vsaka od teh je legitimna zmogljivost. Nobena ni zahteva za zagon. Če odprete prazen projekt in vprašate "kaj naj vključimo?", bo stranka rekla "vse". To ni problem obsega, ampak problem menija.

Zato obrnite okvir. Zagon ni trenutek, ko se izdelek zdi dokončan. Zagon je trenutek, ko se zanka sklene: član plača, član dobi tisto, zaradi česar je prišel, član meni, da je naslednje plačilo vredno. Vse ostalo je poznejša ponovitev.

Uporaben način za sporočanje tega je tristolpčna tabela:

Obljuba menija platforme	Kaj zagon dejansko potrebuje	Kaj lahko počaka
Forum/prostori za razprave	Zanesljiv način dostave osrednje vsebine	Ko nekdo dejansko postavlja vprašanja
Sobe za video v živo	Urnik in nekdo, ki vodi	Ko dokažete, da se bodo ljudje udeležili
Profili članov/imenik	Delujoča prijava in plačilo, ki prispe	Ko je občinstvo dovolj veliko, da to potrebuje
Analitika	Ena nadzorna plošča, ki pove, ali prihaja do podaljšanj	Preostali podatki, ki jih še niste pripravljeni brati

To je vsakič ista poteza: vzemite seznam funkcij, ki vam ga je dal marketing platforme, in ga razvrstite v "izda zdaj", "izda naslednje četrtletje" in "morda nikoli". Ugotovili boste, da je dejanski seznam za zagon nerodno kratek. To je cilj.

"Ampak vaš postopek ne zna ravnati s tem, kakšni so naši člani."

Vsaka stranka verjame, da so njeni člani izjema. Strokovno združenje "potrebuje" nekaj drugega kot podjetje B2B SaaS "potrebuje" kot ustvarjalec "potrebuje." Platforme same to krepijo z razdeljevanjem svojih sporočil za združenja, podjetja SaaS in ustvarjalce. Segmentacija je resnična; sklep ni.

Kar se dejansko spreminja med strankami, je menjava vrednosti, ne mehanika. Člansko spletišče je v vsakem primeru plačilni zid okoli nečesa. Pregledi platform vam bodo povedali, da so nekatere platforme boljše za strokovna združenja, druge za ustvarjalce, in ta raznolikost je uporabna – vendar je to zadnja odločitev, ki jo sprejmete, ne prva.

Ponovljiv agencijski postopek je, da napišete en stavek, preden odprete eno samo primerjavo platform. "Člani plačujejo mesečno, da dobijo [X]." Če stranka ne more dokončati tega stavka, jih nobena izbira platforme ne bo rešila. Če lahko, lahko celoten zagon načrtujete okoli dostave X in prezrete funkcije, ki se X-a ne dotikajo.

Na tej točki tudi odložite pogovor o cenah. Mesečne naročnine, letna članstva, enkratna plačila, svežnji tečajev, vrhunske stopnje – vse to so možnosti monetizacije in vse so le različni načini zaračunavanja X-a. Nihče ne potrebuje foruma skupnosti, da bi zaračunal letno pristojbino. V trenutku, ko stranki dovolite, da svoj model opredeli kot "naročnina + skupnost + tečaji", ste se prijavili za tri izdelke namesto enega. Mimogrede, to je tudi razlog, zakaj klasični predlog članskega spletišča netehničnemu šefu običajno spodleti: vsi poskušajo prodati funkcije, ne menjave.

"Naša stranka je zahtevala izdelavo po meri."

Vzemite ves čas, ki ste ga nameravali porabiti za razvoj po meri, in ga vložite v eno vprašanje, na katerega stranka ne more odgovoriti: "Katera od teh funkcij je izdelek in katera embalaža?" Večina zahtevkov po meri je za embalažo, ki jo platforma za članstvo že ponuja kot potrditveno polje. Delo po meri bi moralo biti rezervirano za del izdelka, ki stranko dejansko razlikuje na njenem trgu – ne za imenik članov, ki razvršča po panogi.

Konkreten primer: ena stranka je prišla k nam s seznamom, ki je vključeval imenik certifikatov, sobo za vprašanja in odgovore v živo, četrtletni virtualni vrh in orodje za ujemanje po meri. Orodje za ujemanje je bil izdelek; imenik, soba za vprašanja in vrh so bili vsi embalaža. Delo po meri smo omejili na orodje za ujemanje, zagnali s preprosto prijavo članov in plačilno stranjo ter ostalo pustili na seznamu "pozneje" osemnajst mesecev. Stranka je opazovala, kako je imenik postal nepomemben, in dobila delujoč izdelek brez gradnje s šestmestno ceno. Ta lekcija se je prijela celotne ekipe računov.

Opozorilo: če je stranka v niši, kjer standardne funkcije platforme resnično ne ustrezajo njenemu trgu – recimo združenje, ki mora zaračunavati na stotine članov na ravni podružnic z različnimi poteki odobritev – je lahko izdelava po meri upravičeno cenejša od boja s platformo. A to je niša, ne privzeta možnost. Privzeto je, da gre razvoj po meri tja, kjer projekti članstva porabijo denar za stvari, ki jih člani nikoli ne vidijo.

"Ne moremo upravljati skupnosti."

Dobro. Potem je ne zaženite.

Vsak članek o vključevanju, ki ste ga kdaj prebrali, pravi, da je skupnost ključ do zadrževanja, in to je – sčasoma. Toda skupnost je funkcija zadrževanja, ne funkcija zagona. Forum, v katerega tri mesece nihče ne piše, je slabši kot noben forum; vsem sporoča, da je kraj mrtev. Prazna soba za video v živo je slabša od dobro zasnovanega e-poštnega tečaja. Če stranka nima nikogar, ki bi lahko vsaj nekaj ur na teden odgovarjal na vprašanja in spodbujal razprave, najprej zaženite vsebinski del in dodajte skupnost, ko bo dosežena kritična masa, da bo delovala živo.

To je kontradiktorni del: za agencijo "ne moremo upravljati skupnosti" ni ugovor; je darilo. Pomeni, da lahko zaženete brez zavezovanja stranke k operativnim stroškom, za katere ni predvidela proračuna. Pozneje, ko je baza članov dovolj velika, da se ljudje že želijo pogovarjati med seboj, lahko povečate vključenost v svoji članski skupnosti s funkcijo, ki ima prvaka, ki jo bo vodil.

Ukrepanje tukaj je kontrolni seznam, ki velja za vsako stranko, brez izjem. Za vsako predlagano funkcijo vprašajte: "Kdo je lastnik tega po zagonu?" Če odgovor ni imenovana oseba s časom v koledarju, funkcija ne izide. Profili članov? Potrebuje nekoga, ki odobrava profile. Video v živo? Potrebuje voditelja. Forum za razprave? Potrebuje moderatorja. Platforma lahko zagotovi vodovod; ne more zagotoviti opravila.

"Pred zagonom moramo preseliti vse."

Selitev je najljubša zamuda organiziranih. Stranka ima na tisoče e-poštnih naročnikov, desetletje člankov, PDF tečaj, staro preglednico članov z datumi poteka dostopa, in prepričani so, da mora biti vse to v novem sistemu, preden lahko komurkoli zaračunate.

Ni res. Ob zagonu potrebujete tri stvari: ljudi, ki bodo plačali, način za sprejem denarja in vsebino, za katero plačujejo. Vse ostalo je mogoče preseliti, medtem ko je spletišče živo. Tedenski prehodi, "novi člani dobijo arhiv od tega datuma naprej" in uvoz, ki se izvede čez vikend – karkoli od tega je boljše od zagona, ki čaka na slavo čiščenja podatkov.

To je agencijska poteza: določite datum prehoda selitve in ga spoštujte. Zaženite z minimalno izvedljivim naborom podatkov. Če stranka vztraja, da morajo starejši člani ohraniti dostop do starejše vsebine, je to funkcija za vaš seznam "ni za ta zagon" — platforma skoraj zagotovo podpira ravni dostopa, tako da lahko stari sistem ohranite berljiv in nove člane usmerite na novega. Imate lahko dva sistema v prehodnem obdobju. Ne smete dovoliti, da popolni podatki blokirajo živi izdelek.

"Potrebujemo platformo, ki zmore vse."

Na tej točki bo nekdo na klicu zahteval orodje, ki združuje funkcije članstva, forume skupnosti, gostovanje tečajev, obdelavo plačil in dizajn "vau" po meri ciljne strani. Poimenujte to past vse-v-enem: spremeni gradnjo v iskanje in iskanje se nikoli ne konča, ker noben posamezen izdelek objektivno ni dober v vsem.

Način za rešitev tega je, da nehate ocenjevati platforme kot vesolja vse-v-enem in vprašate, kaj je dejansko najpočasnejši in najbolj tvegan del zagona te stranke. Če je tveganje pri plačilih in dostopu, izberite platformo, ki je pri tem dolgočasno zanesljiva. Če je tveganje pri prodaji samega članstva, potem sta prednostna ciljna stran, ki spreminja obiskovalce v stranke, in zaključek nakupa, ki se zdi razumen – za to ne potrebujete desete funkcije platforme. Ključna vprašanja, ki si jih zastavite pred izbiro platforme za članstvo bi morala biti o zagonu, ne o funkcijah, ki bodo morda prišle nekoč.

In tu je del, ki ga je enostavno preskočiti: ne dovolite, da iskanje funkcij postane način za odlašanje oblikovanja. Ko stranka reče "želimo sodobno, dovršeno podobo, ki odraža našo blagovno znamko", je to resnična potreba. Toda ciljna stran za zagon ne potrebuje platforme, ki bi bila odlična v vsem; mora jasno pojasniti menjavo, pokazati ceno in se umakniti s poti. Za agencijo je stavek "po zagonu bomo preoblikovali" zaveza zagonu, ne kompromis pri kakovosti.

Zaključek: Izdajte najmanjšo stvar, za katero bodo ljudje plačali, nato pa dodajajte.

Ponavljajoči se prihodek ni nagrada za gradnjo popolne vizije; popolna vizija se gradi s ponavljajočim se prihodkom. Če imate ta stavek pred seboj, se ugovori rešijo sami. "Ne moremo zagnati, dokler se ne zdi dokončano" postane "dokončano je premikajoča se tarča, zato zaženite minimum in začnite se učiti." "Naši člani so drugačni" postane "odlično, torej je menjava vrednosti drugačna – napišimo stavek." "Potrebujemo po meri" postane "po meri je za izdelek, ne za vodovod." "Ne moremo upravljati skupnosti" postane "zagnali bomo plačljivo jedro in dodali skupnost, ko bo imela lastnika." "Najprej moramo preseliti" postane "preselili bomo tiste, ki plačujejo, ostalo pa pustili za pozneje."

Ta disciplina je dejanska storitev, ki jo prodajate. Stranka misli, da kupuje člansko spletišče. Kar kupuje, je vaša sposobnost ločiti pravo zanko ponavljajočega se prihodka od funkcij, ki so videti kot izdelek, a ga le zavlačujejo. Če to dobro naredite pri predstavitvi, boste to lahko ponovili za naslednjo stranko – kar je, če ste agencija, bistvo.