Gerçekten Yayına Giren Üyelik Sitesi Lansmanı

Özet

Bir müşteri üyelik sitesi istediğinde listeledikleri özellikler neredeyse hiçbir zaman ürünün kendisi değildir. Ürün, belirli bir şey karşılığında yapılan yinelenen bir ödemedir — ve diğer her şey, özellik kılığına girmiş bir gecikmedir. Bir ajans için bu, lansman konuşmasını standardize etmek anlamına gelir: değer alışverişini tek cümleyle tanımlayın, bunu destekleyen en küçük özellik setini haritalayın ve platformun zaten yaptığı altyapı için özel geliştirme yapmayı reddedin. Bu makale, müşterilerden ve iç paydaşlardan duyacağınız itirazları ele alıyor ve zaman çizelgesini dürüst tutan karşı argümanlar sunuyor. 'Topluluk' ve 'kurs barındırma'yı lansman gereksinimleri olarak görmeyi bıraktığınızda, bir üyelik sitesini çeyreklerde değil, haftalarda yayınlayabilirsiniz.

Neden her üyelik sitesi projesi dokuz aylık bir destana dönüşüyor?

Çünkü lansmanı, müşterinin tüm vizyonunun hayata geçtiği an olarak görmeye devam ediyoruz. Oysa asla öyle değildir. Vizyon, bir platformun satış sayfasındaki özelliklerin bir elektronik tablosudur; lansman ise birinin para karşılığında erişim aldığı ilk noktadır. Bir ajans için, yılda üç üyelik sitesi yayınlamak ile bir tane yayınlamak arasındaki fark, müşteri kendini kısa satılmış hissetmeden bu ayrımı birden çok kez yüksek sesle dile getirebilme yeteneğidir.

Bu, belirli bir platforma yönelik bir rehber değil. Size karşı kullanılacak argümanların ve zaman çizelgenizi yemeye çalışacak uç durumların saha rehberi.

"Tamamlanmış hissettirene kadar yayınlayamayız."

Müşterinin kendi sözleriyle başlayın: "İlk izlenim için yalnızca bir şansımız var." Bu, onların markası için geçerlidir, özellik listesi için değil. Az sayıda üye, ilk gün bir rozet sisteminin eksik olması nedeniyle iptal eder; onlar, ödediklerinin gelmemesi nedeniyle iptal eder. Aslında çoğu sessizce ayrılır, ama o başka bir makale.

Üyelik platformu pazarı, bu itirazı daha da kötüleştirmek için tasarlanmıştır. Standart ürün menüsü; tartışma alanları, canlı video odaları, üye profilleri, etkinlik yönetimi, analitik, kurs barındırma, ödeme işleme ve katmanlı erişim içerir — hepsi tek bir abonelikte. Her biri meşru bir özelliktir. Hiçbiri lansman gereksinimi değildir. Boş bir proje açıp "neyi dahil edelim?" derseniz, müşteri "hepsini" der. Bu bir kapsam sorunu değil, menü sorunudur.

Öyleyse çerçeveyi tersine çevirin. Lansman, ürünün eksiksiz hissettirdiği an değildir. Lansman, döngünün kapandığı andır: üye öder, üye geldiği şeyi alır, üye sonraki ödemeye değdiğini hisseder. Diğer her şey daha sonraki bir yinelemedir.

Bunu iletmenin faydalı bir yolu üç sütunlu bir tablodur:

Platform menüsünün vaat ettikleri	Lansmanın gerçekte ihtiyaç duyduğu	Neyin bekleyebileceği
Forum/tartışma alanları	Temel içeriği sunmanın güvenilir bir yolu	Birileri gerçekten soru soruyorken
Canlı video odaları	Bir program ve sunacak biri	İnsanların katılacağını kanıtladığınızda
Üye profilleri/rehberi	Çalışan bir giriş ve hesaba geçen bir ödeme	Hedef kitle buna ihtiyaç duyacak kadar büyük olduğunda
Analitik	Yenilemelerin olup olmadığını gösteren tek bir gösterge paneli	Okumaya hazır olmadığınız diğer veriler

Bu her seferinde aynı hamledir: platformun pazarlamasının size verdiği özellik listesini alın ve "şimdi yayınlanır", "önümüzdeki çeyrekte yayınlanır" ve "belki asla" olarak sıralayın. Gerçek lansman listesinin utanç verici derecede kısa olduğunu göreceksiniz. Hedef de budur.

"Ama süreciniz üyelerimizin nasıl olduğuyla başa çıkamaz."

Her müşteri, üyelerinin istisna olduğuna inanır. Profesyonel dernek "ihtiyaç duyar", B2B SaaS şirketi "ihtiyaç duyar", içerik üreticisi "ihtiyaç duyar" — hepsi farklıdır. Platformların kendisi de mesajlarını dernekler, SaaS şirketleri ve içerik üreticileri için bölümlendirerek bunu pekiştirir. Bölümlendirme gerçektir; varılan sonuç gerçek değildir.

Müşteriler arasında gerçekte değişen, mekanikler değil, değer alışverişidir. Bir üyelik sitesi, her durumda, bir şeyin etrafındaki ödeme duvarıdır. Platform karşılaştırmaları, bazı platformların profesyonel dernekler için, diğerlerinin içerik üreticileri için daha iyi olduğunu söyleyecektir ve bu çeşitlilik faydalıdır — ancak bu, verdiğiniz ilk karar değil, son karardır.

Tekrarlanabilir ajans süreci, tek bir platform karşılaştırması açmadan önce bir cümle yazmaktır. "Üyeler [X]'i almak için aylık öder." Müşteri bu cümleyi tamamlayamıyorsa, hiçbir platform seçimi onları kurtaramaz. Tamamlayabiliyorsa, tüm lansmanı X'i teslim etmek etrafında kapsamlandırabilir ve X'in dokunmadığı özellikleri görmezden gelebilirsiniz.

Ayrıca burada fiyatlandırma konuşmasını bir kenara bırakırsınız. Aylık abonelikler, yıllık üyelikler, tek seferlik ödemeler, kurs paketleri, premium katmanlar — bunların hepsi para kazanma seçenekleridir ve hepsi X için ücret almanın farklı yollarıdır. Yıllık ücret almak için hiç kimsenin bir topluluk forumuna ihtiyacı yoktur. Müşterinin modelini "abonelik + topluluk + kurslar" olarak tanımlamasına izin verdiğiniz an, bir ürün yerine üç ürünü üstlenmişsiniz demektir. Kayıtlara geçsin, klasik teknik olmayan bir patrona üyelik sitesi sunmak genellikle bu yüzden ters gider: herkes değer alışverişini değil, özellikleri satmaya çalışır.

"Müşterimiz özel olarak yapılmasını istedi."

Özel geliştirmeye harcamak üzere olduğunuz tüm zamanı, müşterinin cevaplayamadığı tek soruya ayırın: "Bu özelliklerden hangisi ürün, hangisi paketleme?" Çoğu özel istek, bir üyelik platformunun zaten bir onay kutusu olarak sunduğu paketleme içindir. Özel çalışma, müşteriyi pazarında gerçekten farklılaştıran ürün kısmı için ayrılmalıdır — sektöre göre sıralayan bir üye rehberi için değil.

Somut bir örnek: bir müşteri bize bir sertifika rehberi, canlı soru-cevap odası, üç aylık sanal zirve ve özel bir eşleştirme aracı içeren bir listeyle geldi. Eşleştirme aracı üründü; rehber, soru-cevap odası ve zirvenin hepsi paketlemeydi. Özel çalışmayı eşleştirme aracına göre kapsamlandırdık, basit bir üye girişi ve ödeme sayfasıyla yayınladık ve gerisini on sekiz ay boyunca "sonra" listesinde bıraktık. Müşteri rehberin gereksiz hale geldiğini gördü ve altı haneli bir geliştirme olmadan çalışan bir ürün elde etti. Bu ders tüm hesap ekibinin aklına kazındı.

Uyarı: Müşteri, platformun standart özelliklerinin pazarına gerçekten uymadığı bir nişteyse — örneğin, farklı onay iş akışlarına sahip yüzlerce şube düzeyinde üyeye fatura kesmesi gereken bir dernek — o zaman özel geliştirme, bir platformla mücadele etmekten meşru olarak daha ucuz olabilir. Ancak bu bir niştir, varsayılan değildir. Varsayılan, özel geliştirmenin üyelik projelerinde üyelerin asla görmediği şeylere para harcamak için gidilen yer olmasıdır.

"Bir topluluğu yönetemeyiz."

Güzel. O zaman bir tane yayınlamayın.

Okuduğunuz her etkileşim makalesi, topluluğun elde tutmanın anahtarı olduğunu söyler ve öyledir — sonunda. Ancak topluluk, bir elde tutma özelliğidir, lansman özelliği değil. Üç ay boyunca kimsenin yazmadığı bir forum, hiç forum olmamasından daha kötüdür; herkese yerin ölü olduğunu söyler. Boş bir canlı video odası, iyi tasarlanmış bir e-posta kursundan daha kötüdür. Müşterinin haftada en az birkaç saati soruları yanıtlamaya ve tartışmaları başlatmaya ayırabilen birisi yoksa, önce içerik tarafını yayınlayın ve topluluğu, onu canlı hissettirecek bir kritik kütle olduğunda ekleyin.

Bu karşıt görüş olan kısım: bir ajans için "bir topluluğu yönetemeyiz" bir itiraz değildir; bir hediyedir. Bu, müşteriyi bütçelemedikleri bir operasyonel maliyete sokmadan yayın yapabileceğiniz anlamına gelir. Daha sonra, üyelik tabanı insanların birbiriyle konuşmak istediğini sorduğu kadar büyük olduğunda, onu yönetecek bir sahibi olan bir özellikle üyelik topluluğunuzdaki etkileşimi artırın.

Buradaki eylem adımı, istisnasız her müşteriye uygulanan bir kontrol listesidir. Önerilen her özellik için sorun: "Bunun sahibi lansmandan sonra kim?" Cevap, takviminde zamanı olan adı belirli bir kişi değilse, özellik yayınlanmaz. Üye profilleri? Profilleri onaylayacak birine ihtiyaç var. Canlı video? Bir sunucuya ihtiyaç var. Tartışma forumu? Bir moderatöre ihtiyaç var. Platform altyapıyı sağlayabilir; angaryayı sağlayamaz.

"Lansmandan önce her şeyi taşımak zorundayız."

Veri taşıma, düzenli olanların favori gecikmesidir. Müşterinin binlerce e-posta abonesi, on yıllık makaleleri, bir PDF kursu, erişim son kullanma tarihleri olan eski bir üye elektronik tablosu vardır ve hepsinin, siz birinden ücret almadan önce yeni sistemde olması gerektiğinden emindirler.

Gerekmez. Lansmanda üç şeye ihtiyacınız var: ödeyecek insanlar, paralarını almanın bir yolu ve ödedikleri içerik. Diğer her şey site canlıyken taşınabilir. Haftalık geçişler, "yeni üyeler arşivi bu tarihten itibaren alır" ve hafta sonu çalışan bir içe aktarma — bunlardan herhangi biri, veri temizliği zaferini bekleyen bir lansmandan daha iyidir.

Bu ajans hamlesidir: bir taşıma geçiş tarihi belirleyin ve buna uyun. Minimum geçerli veri setiyle yayınlayın. Müşteri, eski üyelerin eski içeriğe erişimini sürdürmesi gerektiğinde ısrar ederse, bu sizin "bu lansmanda değil" listeniz için bir özelliktir — platform neredeyse kesinlikle erişim düzeylerini destekler, böylece eski sistemi okunur tutabilir ve yeni üyeleri yeni sisteme yönlendirebilirsiniz. Geçiş dönemi için iki sisteme sahip olmanıza izin vardır. Mükemmel verilerin canlı bir ürünü engellemesine izin verilmez.

"Her şeyi yapan bir platforma ihtiyacımız var."

Bu noktada, görüşmedeki biri üyelik özelliklerini, topluluk forumlarını, kurs barındırmayı, ödeme işlemeyi ve özel bir açılış sayfasının "vay" tasarımını birleştiren bir araç isteyecektir. Buna hepsi-bir-arada tuzağı adını verin: bir geliştirmeyi bir aramaya dönüştürür ve arama hiç bitmez çünkü hiçbir tek ürün hepsinde nesnel olarak iyi değildir.

Bunu çözmenin yolu, platformları hepsi-bir-arada evrenler olarak değerlendirmeyi bırakmak ve bu müşterinin lansmanının gerçekte en yavaş, en riskli kısmının ne olduğunu sormaktır. Risk ödemeler ve erişimse, bu konularda sıkıcı derecede güvenilir olan platformu seçin. Risk, üyeliğin kendisini satmaksa, öncelik dönüşüm sağlayan bir açılış sayfası ve mantıklı görünen bir ödeme adımıdır — ve bunu elde etmek için platformun onuncu özelliğine ihtiyacınız yok. Bir üyelik platformu seçmeden önce sorduğunuz kilit sorular lansmanla ilgili olmalı, "bir gün" özellikleriyle değil.

Ve işte atlanması kolay olan kısım: özellik arayışının tasarımı geciktirmenin bir yolu haline gelmesine izin vermeyin. Müşteri "markamızı yansıtan modern, cilalı bir varlık istiyoruz" dediğinde bu gerçek bir ihtiyaçtır. Ancak bir lansman sayfasının platformun her şeyde harika olmasına ihtiyacı yoktur; alışverişi net bir şekilde açıklaması, fiyatı göstermesi ve aradan çekilmesi gerekir. Bir ajans için "lansmandan sonra yeniden tasarlarız" ifadesi lansmana bağlılıktır, kaliteden ödün değil.

Sonuç: İnsanların ödeyeceği en küçük şeyi yayınlayın, Pazartesi ekleyin.

Yinelenen gelir, tam vizyonu inşa etmenin ödülü değildir; tam vizyon, yinelenen gelirle inşa edilir. Bu cümleyi önünüzde tutarsanız, itirazlar kendi kendini çözer. "Tamamlanmış hissettirene kadar yayınlayamayız" -> "tamamlama hareketli bir hedeftir, bu yüzden minimumu yayınlayın ve öğrenmeye başlayın." "Üyelerimiz farklı" -> "harika, o zaman değer alışverişi de farklıdır — hadi cümleyi yazalım." "Özel yapmamız gerek" -> "özel, ürün içindir, altyapı için değil." "Bir topluluğu yönetemeyiz" -> "ücretli çekirdeği yayınlayacağız ve bir sahibi olduğunda topluluğu ekleyeceğiz." "Önce taşımamız gerek" -> "ödeyen insanları taşıyacağız ve gerisini sonraya bırakacağız."

Bu disiplin, sattığınız asıl hizmettir. Müşteri bir üyelik sitesi satın aldıklarını düşünür. Aslında satın aldıkları, gerçek bir yinelenen gelir döngüsünü, ürün gibi görünen ancak yalnızca onu geciktiren özelliklerden ayırma yeteneğinizdir. Bunu sunumda iyi yaparsanız, bir sonraki müşteri için de yaparsınız — ki bir ajanssanız, asıl mesele budur.