Medlemssajtlanseringen som faktiskt blir av

Summary

När en kund frågar efter en medlemssajt är de funktioner de listar nästan aldrig produkten. Produkten är en återkommande betalning i utbyte mot något specifikt — och allt annat är ett uppskov förklätt som en funktion. För en byrå innebär det att standardisera lanseringssamtalet: definiera värdeutbytet i en mening, kartlägga den minsta funktionsuppsättning som stödjer det, och vägra att bygga anpassat för infrastruktur som plattformen redan erbjuder. Den här artikeln går igenom invändningarna du kommer att höra från kunder och interna intressenter, och ger motargument som håller tidsplanen ärlig. Du kan lansera en medlemssajt på veckor, inte kvartal, när du slutar behandla 'community' och 'kurshosting' som lanseringskrav.

Varför blir varje medlemssajtsprojekt ett nio månader långt epos?

För att vi fortsätter behandla lanseringen som ögonblicket då en kunds hela vision går live. Det är den aldrig. Visionen är ett kalkylblad med funktioner från en plattforms säljsida; lanseringen är den första punkten där någon byter pengar mot åtkomst. För en byrå är skillnaden mellan att leverera tre medlemssajter om året och att leverera en, förmågan att få den distinktionen att fastna högt och tydligt, mer än en gång, utan att kunden känner sig lurad.

Det här är inte en guide till en specifik plattform. Det är en fältguide till argumenten som kommer att användas mot dig, och de kantiga fall som kommer att försöka äta upp din tidsplan.

"Vi kan inte lansera förrän det känns komplett."

Börja med kundens egna ord: "Vi får bara en chans att göra ett första intryck." Det gäller för deras varumärke, inte för deras funktionslista. Få medlemmar avslutar på grund av att ett märksystem saknades dag ett; de avslutar för att det de betalade för inte kom. Egentligen lämnar de mestadels tyst, men det är en annan artikel.

Marknaden för medlemsplattformar är byggd för att göra denna invändning värre. Standardmenyn inkluderar diskussionsforum, livevideorum, medlemsprofiler, evenemangshantering, analys, kurshosting, betalningshantering och nivåbaserad åtkomst — allt i ett abonnemang. Var och en är en legitim kapacitet. Ingen av dem är ett lanseringskrav. Om du öppnar ett tomt projekt och säger "vad ska vi inkludera?", kommer kunden att säga "allt". Det är inte ett scope-problem, det är ett menyproblem.

Så vänd på perspektivet. Lanseringen är inte ögonblicket då produkten känns komplett. Lanseringen är ögonblicket då loopen sluts: medlemmen betalar, medlemmen får det de kom för, medlemmen känner att det var värt nästa betalning. Allt annat är en senare iteration.

Ett användbart sätt att kommunicera detta är en tabell med tre kolumner:

Plattformsmenyn lovar	Vad lanseringen faktiskt behöver	Vad kan vänta
Forum/diskussionsytor	Ett pålitligt sätt att leverera kärninnehållet	När någon faktiskt ställer frågor
Livevideorum	Ett schema och någon som är värd	När du har bevisat att folk kommer att dyka upp
Medlemsprofiler/katalog	En inloggning som fungerar och en betalning som går igenom	När publiken är tillräckligt stor för att behöva det
Analys	En instrumentpanel som säger om förnyelser sker	Resten av data du inte är redo att läsa

Detta är samma drag varje gång: ta den funktionslista som plattformens marknadsföring gav dig, och sortera den i "lanseras nu", "lanseras nästa kvartal" och "kanske aldrig". Du kommer att upptäcka att den faktiska lanseringslistan är pinsamt kort. Det är målet.

"Men er process kan inte hantera hur våra medlemmar är."

Varje kund tror att deras medlemmar är undantaget. Branschorganisationen "behöver" något annat än B2B SaaS-företaget "behöver" än kreatören "behöver". Plattformarna själva förstärker detta genom att segmentera sitt budskap för organisationer, SaaS-företag och kreatörer. Segmenteringen är verklig; slutsatsen är det inte.

Det som faktiskt förändras mellan kunder är värdeutbytet, inte mekaniken. En medlemssajt är i alla fall en betalvägg runt något. Plattformsjämförelserna kommer att berätta att vissa plattformar är bättre för branschorganisationer och andra för kreatörer, och den variationen är användbar — men det är det sista beslutet du tar, inte det första.

Den repeterbara byråprocessen är att skriva en mening innan du öppnar en enda plattformsjämförelse. "Medlemmar betalar månadsvis för att få [X]." Om kunden inte kan avsluta den meningen, kommer inget plattformsval att rädda dem. Om de kan, kan du skopa hela lanseringen kring att leverera X, och ignorera de funktioner som X inte rör.

Det är också här du lägger prissamtalet åt sidan. Månadsabonnemang, årliga medlemskap, engångsbetalningar, kursbuntar, premiumnivåer — det är alla intäktsalternativ, och de är bara olika sätt att ta betalt för X. Ingen behöver ett communityforum för att ta ut en årsavgift. I samma ögonblick som du låter kunden definiera sin modell som "abonnemang + community + kurser", har du skrivit under på tre produkter istället för en. För protokollet, det är också därför den klassiska sälja in en medlemssajt till en icke-teknisk chef vanligtvis går fel: alla försöker sälja funktionerna, inte utbytet.

"Vår kund bad om att få det specialbyggt."

Ta den tid du tänkt spendera på anpassad utveckling och lägg den på den enda frågan kunden inte kan svara på: "Vilken av dessa funktioner är produkten, och vilken är förpackningen?" De flesta anpassade förfrågningar gäller förpackning som en medlemsplattform redan erbjuder som en kryssruta. Anpassat arbete bör reserveras för den del av produkten som faktiskt differentierar kunden på deras marknad — inte för en medlemskatalog som sorterar efter bransch.

Ett konkret exempel: en kund kom till oss med en lista som inkluderade en certifieringskatalog, ett live Q&A-rum, ett kvartalsvis virtuellt toppmöte och ett anpassat matchningsverktyg. Matchningsverktyget var produkten; katalogen, Q&A-rummet och toppmötet var allt förpackning. Vi avgränsade det anpassade arbetet till matchningsverktyget, lanserade med en enkel medlemsinloggning och en betalningssida, och lät resten ligga på en "senare"-lista i arton månader. Kunden såg katalogen bli irrelevant och fick en fungerande produkt utan ett sexsiffrigt bygge. Den läxan fastnade hos hela kontoteamet.

Förbehållet: om kunden är i en nisch där plattformens standardfunktioner verkligen inte passar deras marknad — till exempel en organisation som behöver fakturera hundratals avdelningsmedlemmar med olika godkännandeflöden — kan ett specialbygge vara legitimt billigare än att kämpa mot en plattform. Men det är en nisch, inte standarden. Standard är att anpassad utveckling är där medlemsprojekt går för att spendera pengar på saker medlemmar aldrig ser.

"Vi kan inte hantera ett community."

Bra. Då lanserar du inget.

Varje engagemangsartikel du någonsin läst säger att community är nyckeln till retention, och det är det — så småningom. Men community är en retentionsfunktion, inte en lanseringsfunktion. Ett forum som ingen skriver i på tre månader är värre än inget forum; det säger till alla att platsen är död. Ett tomt livevideorum är värre än en väldesignad e-postkurs. Om kunden inte har någon som kan lägga minst ett par timmar i veckan på att svara på frågor och sätta igång diskussioner, lansera innehållssidan först och lägg till community när det finns en kritisk massa för att få det att kännas levande.

Det här är den konträra delen: för en byrå är "vi kan inte hantera ett community" inte en invändning; det är en gåva. Det betyder att du får lansera utan att binda kunden till en driftskostnad de inte budgeterat för. Senare, när medlemsbasen är tillräckligt stor för att människor redan frågar efter att prata med varandra, kan du öka engagemanget i ditt medlemscommunity med en funktion som har en ansvarig som driver den.

Åtgärdssteget här är en checklista som gäller för varje kund, utan undantag. För varje föreslagen funktion, fråga: "Vem äger detta efter lanseringen?" Om svaret inte är en namngiven person med tid i kalendern, lanseras inte funktionen. Medlemsprofiler? Behöver någon som godkänner profiler. Livevideo? Behöver en värd. Diskussionsforum? Behöver en moderator. Plattformen kan tillhandahålla infrastrukturen; den kan inte utföra sysslan.

"Vi måste migrera allt innan vi lanserar."

Migrering är den organiserades favoritfördröjning. Kunden har tusentals e-postprenumeranter, ett decennium av artiklar, en PDF-kurs, ett gammalt kalkylblad med medlemmar och utgångsdatum för åtkomst, och de är säkra på att allt måste finnas i det nya systemet innan du kan ta betalt av någon.

Det behöver det inte. Du behöver tre saker vid lansering: personerna som kommer att betala, ett sätt att ta emot deras pengar, och innehållet de betalar för. Allt annat kan migreras medan sajten är live. Veckovisa växlingar, "nya medlemmar får arkivet från detta datum och framåt," och en import som körs över helgen — vilket som helst av dessa slår en lansering som väntar på data-städningens ära.

Det här är byrådraget: sätt ett datum för migreringsväxling och håll det. Lansera med den minsta livskraftiga datauppsättningen. Om kunden insisterar på att äldre medlemmar måste behålla åtkomst till äldre innehåll, är det en funktion för din "inte denna lansering"-lista — plattformen stödjer nästan säkert åtkomstnivåer, så du kan hålla det gamla systemet läsbart och peka nya medlemmar till det nya. Du har tillåtelse att ha två system under en övergångsperiod. Du har inte tillåtelse att låta perfekt data blockera en levande produkt.

"Vi behöver en plattform som gör allt."

Vid det här laget kommer någon på samtalet att be om ett verktyg som kombinerar medlemsfunktioner, communityforum, kurshosting, betalningshantering och "wow"-designen av en anpassad landningssida. Kalla detta allt-i-ett-fällan: det förvandlar ett bygge till en sökning, och sökningen är oändlig eftersom ingen enskild produkt är objektivt bra på allt.

Sättet att lösa detta är att sluta utvärdera plattformar som allt-i-ett-universum och istället fråga vad som faktiskt är den långsammaste, mest riskfyllda delen av denna kunds lansering. Om risken är betalningar och åtkomst, välj den plattform som är tråkigt pålitlig på dessa. Om risken är att sälja själva medlemskapet, då är prioriteringen en landningssida som konverterar och en kassa som känns vettig — och du behöver inte plattformens tionde funktion för att få det. De nyckelfrågor du ställer innan du väljer en medlemsplattform bör handla om lanseringen, inte om framtida funktioner.

Och här är delen som är lätt att hoppa över: låt inte funktionssökningen bli ett sätt att fördröja designen. När kunden säger "vi vill ha en modern, polerad närvaro som speglar vårt varumärke," är det ett verkligt behov. Men en lanseringssida behöver inte en plattform som är bra på allt; den behöver tydligt förklara utbytet, visa priset och komma ur vägen. För en byrå är frasen "vi gör om designen efter lansering" ett åtagande att lansera, inte en kompromiss om kvalitet.

Slutsats: Lansera det minsta som människor kommer att betala för, lägg sedan till på måndag.

Den återkommande intäkten är inte belöningen för att bygga den kompletta visionen; den kompletta visionen byggs med återkommande intäkt. Om du håller den meningen framför dig, löser sig invändningarna av sig själva. "Kan inte lansera förrän det känns komplett" blir "komplett är ett rörligt mål, så lansera minimum och börja lära." "Våra medlemmar är annorlunda" blir "bra, så värdeutbytet är annorlunda — låt oss skriva meningen." "Vi behöver det specialbyggt" blir "specialbygge är för produkten, inte för infrastrukturen." "Vi kan inte hantera community" blir "vi lanserar den betalda kärnan och lägger till community när det har en ägare." "Vi måste migrera först" blir "vi migrerar de som betalar och lämnar resten till senare."

Den disciplinen är den faktiska tjänsten du säljer. Kunden tror att de köper en medlemssajt. Vad de köper är din förmåga att skilja en verklig återkommande intäktsloop från de funktioner som ser ut som en produkt men bara fördröjer en. Gör det bra i pitchskedet, så får du göra det igen för nästa kund — vilket, om du är en byrå, är hela poängen.