Minden ügyfél közösséget akar: Útmutató az építés előtti felméréshez

Összefoglaló

Az első kickoff hívás alkalmával szinte minden tagsági ügyfél azt mondja: „közösséget akarunk” – és ez a mondat csendben felfújhatja a projektet egy portállá fórumokkal, eseményekkel, tanfolyamokkal és élő szobákkal, amelyeket a bevezetéskor senki sem fog használni. Ez a cikk egy ismételhető felmérési beszélgetést ad az ügynökségeknek ahhoz, hogy ezt a homályos kérést egy kis, szállítható tagsági oldallá alakítsák. A mondatteszttel kezdődik („a tagok azért fizetnek, mert ___”), egyetlen üzleti modellbe kényszeríti az ügyfelet, elhalasztja a közösségi funkciókat, amíg nincs valódi közönség, és minden funkciókérést módosításként kezel. A cikk tartalmaz egy kidolgozott példát is egy ügyfélről, aki teljes közösséget akart, és helyette egy kereshető archívumot és havi élő Q&A-t indított. Figyelmeztet továbbá az elköteleződés ígéretére: az ajtót át tudod adni, de azt nem tudod elérni, hogy az emberek bemenjenek rajta. Az eredmény termékcsalád a mentőakció helyett, és olyan ügyfelek, akik megköszönik, amit nem építettél meg.

Az első kickoff hívás alkalmával az ügyfél azt mondja: „Közösséget akarunk.” Bólintasz, beírod a szót a jegyzeteidbe, és érzed, hogy az ütemterved csendben megduplázódik. Mert a „közösség” jelenthet fórumot, privát chatcsoportot, fizetőfalat, tanfolyamkönyvtárat, eseménysorozatot, tagjegyzéket vagy mindezt egyszerre. Hagyd, hogy mindezt jelentse, és egy negyedévet fogsz olyan dolgok építésével tölteni, amelyeket senki sem használ, majd számlázol az ügyfélnek azért, hogy nézitek, ahogy nem használják. A megoldás nem egy okosabb platform. Hanem egy őszintébb beszélgetés, amit minden alkalommal ugyanúgy vezetsz le, hogy a következő hét ügyfeled ne váljon egyedi, projektenként eltérő projektté.

Ez az anyag azokra a kérdésekre épül, amelyeket valóban folyamatosan megválaszolunk ebben a munkában. Nem a „melyik eszközt használjuk” – az később jön –, hanem azokra a kérdésekre, amelyek eldöntik, hogy egy projekt határidőre elkészül-e, nyereséges marad-e, és az ügyfél úgy érzi-e, tudtad, mit csinálsz.

„Közösséget akarunk” – valójában mit adunk el?

Kéresd meg az ügyfelet, hogy fejezzen be egy mondatot, mielőtt egyáltalán megemlíted a platformokat: „A tagok azért fizetnek, mert ___.” Ennyi. Ha nem tudja kitölteni a hiányzó részt valami konkréttal, akkor nem állsz készen arra, hogy platformot válassz, oldalt vázolj vagy árat idézz. A teljes tagsági oldal – a fizetőfal, a szintek, a funkciók, amelyeket bekapcsolva hagyasz – csak a szállítási mechanizmus ennek a válasznak.

A legtöbb ügyfél, amikor „közösséget” mond, valójában négy kategóriába esik. Amikor ismételhetően felmérünk, arra kényszerítjük a döntést, hogy az egyikbe kerüljön:

Amiért a tagok fizetnek	Amit valójában megépítesz	Amit nyugodtan elhalaszthatsz
Tartalom (tanfolyamok, archívumok, eszközök)	Zárt könyvtár, fizetési folyamat, alap lejátszó	Élő szobák, eseménynaptárak, tanúsítványok
Hozzáférés (egy termék, szolgáltatás vagy eszköz)	Tagi bejelentkezés, jogosultságok, fiókok zárjai	Nyilvános fórum és közösségi hírfolyam
Kapcsolódás (társak, felelősségvállalás, hálózatépítés)	Egy beszélgetési felület, profilok, meghívók	Teljes tanfolyamplatform, tartalom-csepegtetés, tanúsítványok
Státusz (bennfentesek, korai hozzáférés, exkluzív előnyök)	Szintezett hozzáférés, jelvény/címke logika, egyszerű előnyök	Fórumok, felhasználói tartalom, élő események

A táblázat egy felmérési puskázólap, nem menü. Az ügyfél egy kategóriát kap. Ha megpróbál kettőt összevonni, emeld fel a kezed és lassíts, mert a költségeid éppen nőttek. A csapda az, ha mind a négyet megcsinálod egy ügyfélnek, és „aktív közösségi platformnak” hívod. Az nem termék; az egy portál, és a portálok nem készülnek el határidőre.

Ez a táblázat szándékosan kicsi. Abban a pillanatban, amikor egy tagsági oldalt egyszerre négy dolognak engedsz, abbahagytad a terméképítést, és egy kis médiacéget kezdtél el működtetni. Az ügyfél ritkán médiacéget akar; visszatérő bevételt akar. Tartsd a kört olyan kicsinek, hogy a bevételi modell látható legyen a nyitólapról.

Amikor egy ügyfél egy mondatban mond „tanfolyamot” és „fórumot”, kérdezd meg, melyik fizeti a számlákat. Ha a válasz „mindkettő”, akkor valójában egy olyan ügyfelet látsz, aki még nem tudja, mit árul. Néhányan kitalálják a felmérés során, és világosabb ajánlattal térnek vissza; akik nem, azok azt mondják, hogy még nem állnak készen. Ezt hasznos dolog megtudni, mielőtt ajánlatot írnál, nem után.

De ők már százszor kimondták, hogy „közösség”

Itt jön a ellentmondásos rész, és ez nem szerénykedés: a legtöbb tagsági oldalnak egyáltalán nem szabad közösségi funkciókkal elindulnia. A „közösség” nem funkció. Ez egy viselkedés, amely akkor jelenik meg, amikor egy kis csoport ismétlődő értéket kap egymástól, és semmilyen platform nem tudja ezt igény szerint előállítani. A szó az „előfizetésből származó bevétel” helyettesítőjévé vált, ezért mondja minden ügyfél. Hasznosabb leszel számukra, ha visszafordítod.

Futtass le egy közösségi valóságellenőrzést, mielőtt hagyod a kört nőni. Tegyél fel három kérdést:

1. Az első héten pontosan milyen viselkedést vársz egy új tagtól? (Nem „bevonódás” – „posztoljon egy bemutatkozást”, „írjon egy hozzászólást”, „fejezze be az első leckét”.)
2. A csapatodból ki fog időt tölteni ebben a térben az első hónapban, válaszolva, irányítva és rendet rakva?
3. Van-e már egy maroknyi ember, akinek ez a problémája van, és ismerik egymást, vagy azt reméled, hogy idegenekből csapat lesz, mert létezik a weboldal?

Ha mindhárom kérdésre homályos választ kapsz, akkor nem közösséget építesz; egy üres szobát építesz, és építészetnek hívod. A praktikus lépés az, hogy elhalasztod az összes közösségi funkciót, és helyette a tagsági vázat indítod el. Később bármikor hozzáadhatsz egy beszélgetési felületet, és ha olyan csoporthoz adod hozzá, amelynek már van oka megjelenni, akkor esélye van működni. Az egész kérdés hosszabb tárgyalást igényel – a közösségnek a valódi tagok után kell jönnie –, de az egymondatos változat ez: ne építsd meg az amfiteátrumot, mielőtt a közönség létezik.

Mi a legkisebb dolog, ami egyáltalán működhet?

Miután besoroltad az ajánlatot, tervezd meg az indítást vázszerűen. Egy fizetési opció, egy szint, egy zárt tartalom, egy kommunikációs hurok. Vedd a platform funkciólistáját, és kapcsolj ki minden mást. Igen, a platform tud élő videoszobákat, tagi profilokat, eseménykezelést és analitikai irányítópultokat. Ez a probléma.

Egy ügyfél jött hozzánk azzal, amit teljes közösségi víziónak hívott a B2B SaaS termékéhez. Fórumokról, eseménynaptárról, forráskönyvtárról és „tagok fénypontjai” szekcióról beszéltek. A felmérés során befejeztettük velük a mondatot: „A tagok azért fizetnek, mert ___.” A válaszuk az alapító tanácsainak kereshető archívuma plusz havi élő Q&A volt. Szóval ezt indítottuk el. Nincs fórum, nincsenek tagi profilok, nincs eseménynaptár. Nem sokkal később az archívumot használták, a Q&A-nek törzsközönsége lett, és az ügyfél egy privát beszélgetőcsoportot kért, mert a tagok már a terméken kívül is beszélgettek egymással. A csoport azután épült meg, hogy oka volt létezni. Ez a működő sorrend.

Ha a teljes víziót építettük volna fel, késve indultunk volna, több mozgó résszel, és nem lett volna mód megmondani, melyik hozta létre a szokást. Az archívum egy valódi viselkedésre mutathatott; egy élő szoba, amelyet soha nem használtak, csak egy számla lett volna. A lecke unalmas, de megbízható: minél kisebb az indítás, annál valószínűbb, hogy az ügyfél meg tudja mondani, mi működik valójában. Egy karcsú termék teret ad arra is, hogy a következő dolgot jól csináld – adj hozzá egy szintet, nyiss meg egy fórumot – szándékos módosításként, nem sietős extráként a bevezetési hónapba bepréselve. Ha ismételhető módot keresel a szintek és a bevételi struktúra átgondolására, az a tagsági szintek az ismétlődő bevételhez című anyag, de a felmérés előbb jön.

Mi történik, amikor a kérések felhalmozódnak?

Legyünk őszinték arról, hogy a legtöbb tagsági projekt hogyan hal meg: nem alkalmatlanságtól, hanem a „még egy dologtól”. Az ügyfél meglátja egy versenytárs közösségének demóját, és egy hasonló funkciót akar. A helyes válasz nem „igen” és nem „nem” – hanem „tegyük az elhalasztott listára”.

Tedd az elhalasztott funkciók listáját a projekt elsőrangú teljesítményévé. Tedd bele az ajánlatba, tartsd láthatóan, és fűzz hozzá minden, a körön kívüli kérést. Adj minden tételnek egy kiváltó feltételt. Nem „majd egyszer”, hanem „ez akkor érkezik meg, amikor 200 aktív tag egy hónapja jelen van a térben”, vagy „amikor az ügyfél heti két óra munkaidőt vállal a moderálásra”. Nem nehéz vagy; okot adsz a funkciónak a létezésre.

Így állíthatod le ugyanazon tagsági oldal újraépítését minden ügyfél számára: minden új ügyfelet egy már leszállított váz konfigurációjaként kezelve, azon dolgok listájával, amelyeket szándékosan nem építettél meg. Ha egy funkció az elhalasztott listán van, az egy jövőbeli projekt, ami egyben jövőbeli bevétel is. Így keretezd, és az ügyfél általában egyetért.

Hogyan akadályozzuk meg, hogy az ügyfél minket hibáztasson az üres fórumért?

Be kell állítanod az elvárásokat arról, hogy mit tudsz és mit nem tudsz kontrollálni, korán és írásban. Át tudod adni a fizetési folyamatot, a hozzáférés-kezelést, az e-mail automatizálásokat és a dizájnt. Nem tudod átadni azt, hogy az emberek úgy döntsenek, beszélgetnek egymással. Az ügyfél „elköteleződési problémája” nem építési probléma; működési probléma, és az ő ölükben van a helye.

Ez azért fontos, mert az ügyfelek csendben elkezdik kérdezni, hogy miért csendes „a közösség” három héttel az indítás után. Ha a határt a kezdetektől felállítod, hasznos beszélgetést folytathatsz az ösztönzőkről és a magvetésről. Ha nem, akkor egy olyan platformot fogsz hibakeresni, ami nem romlott el. Egy praktikus módja a formalizálásnak: vegyél fel egy külön sor tételt a „közösségi üzemeltetés és magvetés” számára a karbantartási megtartási díjadba, vagy adj az ügyfélnek egy magvetési ellenőrzőlistát, amely a projekt elindításában él. A lényeg az, hogy a munkamegosztás egyértelmű legyen. Az eszköz nem a megtartási stratégia; a tagsági oldal mítoszok általában a bűnösök, amikor az emberek azt várják, hogy egy platform eladja helyettük a terméket.

Amikor mégis ragaszkodnak a közösséghez, mit kapcsoljunk be?

Ha az ügyfél átmegy a valóságellenőrzésen, és valóban közösséget működtet, akkor pontosan egy beszélgetési formátumot kapcsolj be. Nem hármat. Egy fórum szálas, kereshető és aszinkron; egy élő szoba azonnali, múlandó és személyzetigényes. Nem tudod mindkettőt jól moderálni egy kis csapattal, és ha megpróbálod, megtanítod az ügyfelednek, hogy a „közösség” állandó aktivitást jelent, ami nem egy ígérhető mérce.

Praktikus szabály: egy tér, egy formátum, egy megnevezett moderátor. Válaszd azt a formátumot, amely megfelel a valóságellenőrzésben azonosított viselkedésnek. Ha a kívánt viselkedés „kérdezz és kapsz választ”, kezdd egy fórummal. Ha „kedden délben gyere el, hogy megbeszéljétek a kihívásokat”, kezdd egy élő eseménnyel. Ezután állíts be egy könnyű mérőszámot az első kilencven napra: nem a teljes tagság, nem a regisztrációk, hanem azon tagok száma, akik legalább kétszer elvégezték a célviselkedést. Két aktivitási említés elég ahhoz, hogy tudd, él-e a tér, vagy múzeum.

Hogyan árazzuk ezt úgy, hogy termékcsalád legyen, ne mentőakció?

Tedd magát a felfedező beszélgetést számlázható termékké. Hozz létre egy fix díjas tagsági oldal beállítási csomagot, amely tartalmazza a felmérési hívást, a váz felépítését (igen, tényleg), a fizetési konfigurációt és egy kör módosítást. Minden ezen túl – közösségi tervezés, egyedi funkciók, moderálási órák, integrációk – külön munkaként kezelendő. Ez az egész trükk. Amikor minden opcionális funkciót módosításként idézel, az ügyfél hirtelen megtanul priorizálni. Amikor mindent egyetlen növekvő árajánlatba csomagolsz, arra tanítod őket, hogy a nagyobb kör ingyenes.

Egy ismételhető folyamat így néz ki: egy kérdőív, amelyet a hívás előtt küldesz, egy egyoldalas munkakör, fix árral, egy építési ütemterv, amelyet a csapatod már lefuttatott, és egy sablon az elhalasztott funkciók listájához. Képesnek kell lenned megmondani az ügyfélnek az éles indítás dátumát, mielőtt a design moodboard létezik. Jobb beszélgetést is kapsz: az ügyfél látja, mennyibe kerül a minimális megoldás, mennyibe kerülnek a közösségi extrák, és mennyibe kerül a saját ideje. Ha a vázért való fizetés ellen tiltakoznak, ezt még azelőtt megtudod, hogy fájna.

A rész, amelyet senki sem akar hallani

Minden tagsági oldal egy fogadás egy ismétlődő viselkedésre. A platform csak a boríték. A te munkád, aki sok ügyfélnek építesz, az, hogy a borítékot címezd és bélyegezd, miközben biztosítod, hogy senki sem vállalta, hogy kézzel élő előadást ad. Nem tudsz közösséget létrehozni. Létrehozhatod a feltételeket, kiválaszthatod a legkisebb lehetséges változatot, és átadhatod az ügyfélnek azoknak a világos listáját, amelyeket nem építesz meg.

Az utolsó rész a valódi értéked. Az ügyfél azért vett fel, mert nem látja, mit hagyj ki. Szóval hagyd ki neki – magabiztosan, szándékosan, írásban. Amint felmértél, a szállítás szinte unalmassá válik: a tagsági oldal indítások valóban leszállnak, amikor kicsik és a döntések előzetesen megszülettek. Az üres fórumok és a szétterülő egyedi portálok drágák. A váz, határidőre, sokkal többet ér, mint a „hatalmas közösségi platform”, amely soha nem indult el.