Enhver kunde vil have et fællesskab: Vejledningen til at afgrænse, før du bygger

Resumé

Ved det første kickoff-møde siger næsten hver medlemssite-kunde: 'vi vil have et fællesskab' – og den sætning kan stille og roligt udvide projektet til en portal med fora, begivenheder, kurser og live-rum, som ingen vil bruge ved lanceringen. Denne artikel giver bureauer en gentagelig scopingsamtale til at forvandle den vage anmodning til et lille, lanceringsklart medlemssite. Den starter med sætningstesten ('medlemmer betaler, fordi de får ___'), tvinger kunden til en forretningsmodel, udskyder fællesskabsfunktioner, indtil der er et rigtigt publikum, og behandler hver funktionsanmodning som en ændringsordre. Artiklen inkluderer et gennemarbejdet eksempel på en kunde, der ønskede et fuldt fællesskab og lancerede et søgbart arkiv plus en månedlig live Q&A i stedet. Den advarer også mod at love engagement: du kan levere døren, men du kan ikke få folk til at gå gennem den. Resultatet er en produktlinje i stedet for en redningsmission, og kunder, der takker dig for det, du nægtede at bygge.

På det første kickoff-møde siger kunden: 'Vi vil have et fællesskab.' Du nikker, skriver ordet i dine noter og mærker, hvordan din køreplan stille og roligt fordobles. For 'fællesskab' kan betyde et forum, en privat chatgruppe, en betalingsmur, et kursusbibliotek, en begivenhedsserie, et medlemskatalog eller alle ovenstående. Lad det betyde alt det ovenstående, og du vil bruge et kvartal på at bygge ting, ingen bruger, og derefter fakturere kunden for at se dem ikke bruge det. Løsningen er ikke en smartere platform. Det er en mere ærlig samtale, kørt på samme måde hver gang, så dine næste syv kunder ikke hver især bliver et engangs-specialprojekt.

Dette indlæg er bygget op omkring de spørgsmål, vi faktisk bliver ved med at besvare i dette arbejde. Ikke 'hvilket værktøj skal vi bruge' – det kommer bagefter – men de spørgsmål, der afgør, om et projekt lanceres til tiden, forbliver profitabelt, og efterlader kunden med følelsen af, at du vidste, hvad du lavede.

'Vi vil have et fællesskab' – hvad sælger vi egentlig?

Få kunden til at fuldføre en sætning, før du overhovedet nævner platforme: 'Medlemmerne betaler os, fordi de får ___.' Det er det hele. Hvis de ikke kan udfylde blanken med noget specifikt, er du ikke klar til at vælge en platform, skitsere en side eller give et tilbud. Hele medlemssitet – betalingsmuren, niveauerne, de funktioner, du lader være slået til – er bare leveringsmekanismen for det svar.

Hvad de fleste kunder egentlig køber, når de siger 'fællesskab', har tendens til at falde i fire kategorier. Når vi scoper gentageligt, tvinger vi beslutningen ned i en af dem:

Hvad medlemmerne betaler for	Den del, du faktisk bygger	Den del, du trygt kan udskyde
Indhold (kurser, arkiver, værktøjer)	Lukket bibliotek, betalingsflow, grundlæggende afspiller	Live-rum, begivenhedskalendere, certifikater
Adgang (et produkt, en service eller et værktøj)	Medlemslogin, adgangsrettigheder, kontogates	Et offentligt forum og social feed
Forbindelse (ligesindede, ansvarlighed, netværk)	Ét diskussionsrum, profiler, invitationer	Fuldt kursusplatform, indholdsdrop, certifikater
Status (insidere, tidlig adgang, eksklusive fordele)	Differentieret adgang, badge/mærke-logik, simple fordele	Fora, bruger-genereret indhold, live-begivenheder

Tabellen er et scopingsnydeark, ikke en menu. Kunden får én kategori. Hvis de prøver at fusionere to, bør du række hånden op og sænke farten, for dine omkostninger er lige steget. Fælden er at lave alle fire for én kunde og kalde det 'en engagerende fællesskabsplatform.' Det er ikke et produkt; det er en portal, og portaler lanceres ikke til tiden.

Denne tabel er bevidst lille. I det øjeblik du lader et medlemssite være fire ting på én gang, er du holdt op med at bygge et produkt og er begyndt at drive et lille medieselskab. Kunden ønsker sjældent et medieselskab; de vil have tilbagevendende omsætning. Hold scopet lille nok til, at forretningsmodellen er synlig fra startsiden.

Når en kunde siger 'kursus' og 'forum' i samme sætning, så spørg, hvilket der betaler regningerne. Hvis svaret er 'begge', ser du faktisk en kunde, der endnu ikke ved, hvad de sælger. Nogle af dem finder ud af det under scoping og kommer tilbage med et klarere tilbud; dem, der ikke gør, fortæller dig, at de ikke er klar. Det er en nyttig ting at lære, før du skriver et forslag, ikke bagefter.

Men de har allerede sagt 'fællesskab' hundrede gange

Her er den kontrære pointe, og det er ikke beskeden pral: de fleste medlemssites bør slet ikke lanceres med fællesskabsfunktioner. 'Fællesskab' er ikke en funktion. Det er en adfærd, der opstår, når en lille gruppe mennesker får tilbagevendende værdi fra hinanden, og ingen platform kan producere det on demand. Ordet er blevet en stedfortræder for 'abonnementsomsætning', hvilket er grunden til, at hver kunde siger det. Du vil være mere nyttig for dem ved at oversætte det tilbage.

Kør et fællesskabsvirkelighedstjek, før du lader scopet vokse. Stil tre spørgsmål:

1. I den første uge, hvilken præcis adfærd ønsker du, at et nyt medlem skal udføre? (Ikke 'engagere sig' – 'skrive en introduktion', 'efterlade en kommentar', 'færdiggøre den første lektion.')
2. Hvem på dit team vil bruge tid i dette rum i løbet af den første måned på at svare, styre og rydde op i rodet?
3. Er der allerede en håndfuld mennesker, der har dette problem og kender hinanden, eller håber du, at fremmede bliver et team, fordi hjemmesiden findes?

Hvis alle tre får vage svar, bygger du ikke et fællesskab; du bygger et tomt rum og kalder det arkitektur. Det praktiske træk er at udskyde alle fællesskabsfunktioner og i stedet lancere medlemsskelettet. Du kan altid tilføje et diskussionsrum senere, og når du tilføjer det til en gruppe, der allerede har grunde til at dukke op, har det en chance for at virke. Hele spørgsmålet fortjener en længere behandling – fællesskab bør komme, efter du har rigtige medlemmer – men én-sætnings-versionen er: byg ikke amfiteatret, før publikum findes.

Hvad er det mindste, der overhovedet kan virke?

Når du har klassificeret tilbuddet, så design lanceringen som et skelet. Én betalingsmulighed, ét niveau, ét lukket aktiv, én kommunikationssløjfe. Tag din platforms funktionsliste og slå alt andet fra. Ja, platformen kan håndtere live video-rum, medlemsprofiler, begivenhedsstyring og analyse-dashboards. Det er problemet.

En kunde kom til os med det, de kaldte en fuld fællesskabsvision for deres B2B SaaS-produkt. De havde talt om fora, en begivenhedskalender, et ressourcebibliotek og en sektion med 'fremhævede medlemmer'. Under scoping fik vi dem til at fuldføre sætningen: 'Medlemmer betaler, fordi de får ___.' Deres svar var et søgbart arkiv med grundlæggerens råd plus en månedlig live Q&A. Så det var det, vi lancerede. Intet forum, ingen medlemsprofiler, ingen begivenhedskalender. Ikke længe efter blev arkivet brugt, Q&A'en havde faste deltagere, og kunden bad om en privat diskussionsgruppe, fordi medlemmerne allerede talte med hinanden uden for produktet. Gruppen blev bygget, efter den havde en grund til at eksistere. Det er den rækkefølge, der virker.

Hvis vi havde bygget den fulde vision, ville vi være lanceret sent, med flere bevægelige dele og ingen måde at vide, hvilken der faktisk skabte vanen. Arkivet kunne pege på en virkelig adfærd; et live-rum, der aldrig blev brugt, ville bare have været en regning. Lærdommen er kedelig, men pålidelig: jo mindre lanceringen er, jo mere sandsynligt er det, at kunden kan fortælle dig, hvad der faktisk virker. Et slankt produkt giver dig også plads til at gøre den næste ting godt – tilføje et niveau, åbne et forum – som en bevidst ændringsordre i stedet for en stresset ekstra ting presset ind i lanceringsmåneden. Hvis du leder efter en gentagelig måde at tænke på niveauer og omsætningsstruktur, så er det indlægget om medlemsniveauer for tilbagevendende omsætning, men scoping kommer først.

Hvad sker der, når anmodningerne hober sig op?

Lad os være ærlige om, hvordan de fleste medlemsprojekter dør: ikke fra inkompetence, men fra 'endnu en ting.' Kunden ser en demo af en konkurrents fællesskab og vil have en matchende funktion. Det rigtige svar er hverken 'ja' eller 'nej' – det er 'lad os tilføje det til den udskudte liste.'

Gør listen over udskudte funktioner til et førsteklasses leverance i dit projekt. Læg den i tilbuddet, hold den synlig, og tilføj hver uden-for-scope-anmodning til den. Giv hvert punkt en triggerbetingelse. Ikke 'en dag', men 'dette udgives, når 200 aktive medlemmer har været i rummet i en måned' eller 'når kunden afsætter to timers personaletid om ugen til at moderere det.' Du er ikke besværlig; du giver funktionen en grund til at eksistere.

Sådan stopper du med at genopbygge det samme medlemssite for hver kunde: ved at behandle hver ny kunde som en konfiguration af et skelet, du allerede har leveret, med en liste over ting, du bevidst ikke byggede. Hvis en funktion er på den udskudte liste, er det et fremtidigt projekt, som også er fremtidig omsætning. Formuler det sådan, og kunden vil som regel være enig.

Hvordan forhindrer vi kunden i at bebrejde os for det tomme forum?

Du skal sætte forventninger til, hvad du kan og ikke kan kontrollere, tidligt og skriftligt. Du kan levere betalingsflowet, adgangskontrollen, e-mail-automationerne og designet. Du kan ikke levere mennesker, der beslutter sig for at tale med hinanden. Kundens 'engagementproblem' er ikke et byggeproblem; det er et driftsproblem, og det hører hjemme hos dem.

Dette betyder noget, fordi kunder uundgåeligt vil begynde at spørge, hvorfor 'fællesskabet' er stille tre uger efter lanceringen. Hvis du sætter grænsen fra starten, kan du have en nyttig samtale om incitamenter og seedning. Hvis du ikke gjorde det, vil du fejlsøge en platform, der ikke er i stykker. En praktisk måde at formalisere det på: inkluder en separat linjepost for 'community-hosting og seedning' i din vedligeholdelsesaftale, eller giv kunden en seedning-tjekliste, der ligger i deres projekt-kickoff. Pointen er at gøre arbejdsdelingen eksplicit. Værktøjet er ikke fastholdelsesstrategien; myterne om medlemssites er som regel synderen, når folk forventer, at en platform skal sælge for dem.

Når de insisterer på et fællesskab alligevel, hvad tænder vi så?

Hvis kunden består virkelighedstjekket og reelt driver et fællesskab, så tænd for præcis ét diskussionsformat. Ikke tre. Et forum er trådet, søgbart og asynkront; et live-rum er øjeblikkeligt, flygtigt og personalekrævende. Du kan ikke moderere begge godt med et lille team, og at forsøge at gøre det vil lære din kunde, at 'fællesskab' betyder konstant aktivitet, hvilket er en standard, du ikke bør love.

Praktisk regel: ét rum, ét format, én navngivet moderator. Vælg det format, der matcher den adfærd, du identificerede i virkelighedstjekket. Hvis den ønskede adfærd er 'stil et spørgsmål og få et svar', så start med et forum. Hvis det er 'mød op tirsdag middag for at tale udfordringer igennem', så start med en live-begivenhed. Sæt derefter en letvægtsmetrik for de første halvfems dage: ikke samlede medlemmer, ikke tilmeldinger, men antallet af medlemmer, der udførte måladfærden mindst to gange. To omtaler af aktivitet er nok til at vide, om rummet er levende eller et museum.

Hvordan prissætter vi dette, så det er en produktlinje, ikke en redningsmission?

Gør selve opdagelsessamtalen til et fakturerbart produkt. Opret en fastprispakke til opsætning af medlemssite, der inkluderer scopingsamtalen, skeletbygningen (ja, virkelig), betalingskonfiguration og én runde revisioner. Alt derudover – fællesskabsdesign, tilpassede funktioner, moderationstimer, integrationer – er en separat arbejdsbeskrivelse. Det er hele tricket. Når du tilbyder hver valgfri funktion som en ændringsordre, lærer kunden pludselig at prioritere. Når du samler alt i ét eskalerende estimat, lærer du dem, at mere scope er gratis.

En gentagelig proces ser sådan ud: et spørgeskema, du sender før mødet, en one-page arbejdsbeskrivelse med en fast pris, en byggeplan, dit team har kørt før, og en skabelon til listen over udskudte funktioner. Du bør kunne fortælle kunden go-live-datoen, før design-moodboardet eksisterer. Du får også en bedre samtale: kunden ser, hvad minimumet koster, hvad fællesskabstilvalgene koster, og hvad deres egen tid koster. Hvis de stejler over at betale for et skelet, vil du lære det at kende, før det gør ondt.

Den del, ingen vil høre

Ethvert medlemssite er et væddemål på tilbagevendende adfærd. Platformen er bare konvolutten. Dit job, som den person, der bygger dette for mange kunder, er at få konvolutten adresseret og frankeret, mens du sikrer, at ingen har meldt sig til at levere en liveoptræden i hånden. Du kan ikke få et fællesskab til at ske. Du kan skabe betingelserne, vælge den mindst mulige version og give kunden en klar liste over, hvad du ikke bygger.

Den sidste del er din reelle værdi. Kunden hyrede dig, fordi de ikke kan se, hvad de skal udelade. Så udelad det for dem – selvsikkert, bevidst, skriftligt. Når du først har scoped, bliver leveringen næsten kedelig: lanceringer af medlemssites bliver faktisk til noget, når de er små, og beslutningerne blev truffet på forhånd. Tomme fora og store, tilpassede portaler er dyre. Skelettet, til tiden, er langt mere værd end den 'kraftfulde fællesskabsplatform', der aldrig helt blev lanceret.