Her Müşteri Topluluk İster: İnşa Öncesi Kapsam Belirleme Rehberi

Özet

İlk başlangıç toplantısında, neredeyse her üyelik müşterisi “bir topluluk istiyoruz” der — ve bu ifade, projeyi sessizce, lansmanda kimsenin kullanmayacağı forumlar, etkinlikler, kurslar ve canlı odalarla dolu bir portala dönüştürebilir. Bu makale, ajanslara bu belirsiz talebi küçük, yayınlanabilir bir üyelik sitesine dönüştürmek için tekrarlanabilir bir kapsam belirleme konuşması sunuyor. Cümle testiyle başlıyor (“üyeler şunu aldıkları için ödüyor ___”), müşteriyi tek bir iş modeline zorluyor, gerçek bir kitle oluşana kadar topluluk özelliklerini erteliyor ve her özellik talebini bir değişiklik emri olarak ele alıyor. Makale, tam bir topluluk isteyen ve bunun yerine aranabilir bir arşiv ile aylık canlı soru-cevap başlatan bir müşterinin çalışılmış bir örneğini içeriyor. Ayrıca etkileşim sözü vermeye karşı uyarıyor: kapıyı teslim edebilirsiniz, ancak insanları içinden geçmeye zorlayamazsınız. Sonuç, bir kurtarma görevi yerine bir ürün hattıdır ve müşteriler, inşa etmeyi reddettiğiniz şeyler için size teşekkür eder.

İlk başlangıç toplantısında müşteri “Bir topluluk istiyoruz” der. Başınızı sallarsınız, kelimeyi notlarınıza yazarsınız ve yol haritanızın sessizce ikiye katlandığını hissedersiniz. Çünkü “topluluk” bir forum, özel bir sohbet grubu, bir ödeme duvarı, bir kurs kütüphanesi, bir etkinlik serisi, bir üye rehberi veya bunların hepsi anlamına gelebilir. Bunların hepsi anlamına gelmesine izin verirseniz, bir çeyrek dönemi kimsenin kullanmadığı şeyler inşa ederek geçirirsiniz ve sonra müşteriye onların kullanmadığını izlemek için fatura kesersiniz. Çözüm daha akıllı bir platform değil. Her seferinde aynı şekilde yürütülen daha dürüst bir konuşmadır; böylece sonraki yedi müşteriniz tek seferlik özel projelere dönüşmez.

Bu yazı, bu işte gerçekten yanıtlamaya devam ettiğimiz sorular etrafında şekilleniyor. “Hangi aracı kullanmalıyız” değil — o sonra gelir — ama bir projenin zamanında yayınlanıp yayınlanmayacağını, kârlı kalıp kalmayacağını ve müşterinin ne yaptığınızı bildiğiniz hissine kapılıp kapılmayacağını belirleyen sorular.

“Bir topluluk istiyoruz” — aslında ne satıyoruz?

Platformlardan bahsetmeden önce müşterinin bir cümleyi tamamlamasını sağlayın: “Üyeler bize ___ aldıkları için ödüyor.” Hepsi bu. Boşluğu belirli bir şeyle dolduramıyorlarsa, bir platform seçmeye, bir sayfa çizmeye veya bir fiyat teklifi vermeye hazır değilsiniz demektir. Tüm üyelik sitesi — ödeme duvarı, katmanlar, açık bıraktığınız özellikler — yalnızca bu cevabın teslim mekanizmasıdır.

Müşterilerin çoğu “topluluk” dediğinde gerçekte ne satın alıyor, dört kategoriye ayrılma eğilimindedir. Tekrarlanabilir şekilde kapsam belirlediğimizde, kararı bunlardan birine zorlarız:

Üyelerin ödediği	Gerçekten inşa ettiğiniz kısım	Güvenle erteleyebileceğiniz kısım
İçerik (kurslar, arşivler, araçlar)	Kısıtlı kütüphane, ödeme akışı, temel oynatıcı	Canlı odalar, etkinlik takvimleri, sertifikalar
Erişim (bir ürün, hizmet veya araç)	Üye girişi, yetkilendirmeler, hesap kısıtlamaları	Herkese açık bir forum ve sosyal akış
Bağlantı (akranlar, hesap verebilirlik, ağ kurma)	Tek bir tartışma alanı, profiller, davetler	Tam kurs platformu, içerik damlatma, sertifikalar
Statü (içeriden olanlar, erken erişim, özel ayrıcalıklar)	Katmanlı erişim, rozet/etiket mantığı, basit ayrıcalıklar	Forumlar, kullanıcı tarafından oluşturulan içerik, canlı etkinlikler

Tablo bir kapsam belirleme kopya kağıdıdır, bir menü değil. Müşteri tek bir kategori alır. İkisini birleştirmeye çalışırlarsa, elinizi kaldırıp yavaşlamalısınız, çünkü maliyetleriniz arttı. Tuzak, tek bir müşteri için dördünü de yapıp buna “etkileşimli bir topluluk platformu” demek. Bu bir ürün değil; bu bir portal ve portallar zamanında yayınlanmaz.

Bu tablo bilinçli olarak küçük. Bir üyelik sitesinin aynı anda dört şey olmasına izin verdiğiniz anda, bir ürün inşa etmeyi bırakıp küçük bir medya şirketi işletmeye başlarsınız. Müşteri nadiren bir medya şirketi ister; tekrarlayan gelir ister. Kapsamı, gelir modelinin ana sayfadan görülebileceği kadar küçük tutun.

Bir müşteri aynı cümlede “kurs” ve “forum” dediğinde, hangisinin faturaları ödediğini sorun. Cevap “ikisi de” ise, aslında ne sattığını henüz bilmeyen bir müşteri görüyorsunuz demektir. Bazıları kapsam belirleme sırasında bunu anlar ve daha net bir teklifle geri döner; anlamayanlar, hazır olmadıklarını söylüyorlar. Bunu bir teklif yazmadan önce öğrenmek faydalıdır, sonra değil.

Ama zaten yüz kez “topluluk” dediler

İşte karşıt görüş ve bu bir mütevazı övünme değil: çoğu üyelik sitesi topluluk özellikleriyle hiç başlatılmamalı. “Topluluk” bir özellik değildir. Küçük bir grup insanın birbirinden tekrarlayan değer elde ettiğinde ortaya çıkan bir davranıştır ve hiçbir platform bunu talep üzerine üretemez. Kelime, “abonelik geliri” için bir vekil haline geldi, bu yüzden her müşteri onu söylüyor. Bunu geri çevirerek onlara daha faydalı olacaksınız.

Kapsamın büyümesine izin vermeden önce bir topluluk gerçeklik kontrolü yapın. Üç soru sorun:

1. İlk haftada, yeni bir üyenin yapmasını istediğiniz tam davranış nedir? (“Etkileşim” değil — “bir tanıtım gönderisi paylaşmak,” “yorum bırakmak,” “ilk dersi bitirmek.”)
2. Ekibinizden kim ilk ay boyunca bu alanda vakit geçirecek, yanıtlayacak, yönlendirecek ve karmaşayı temizleyecek?
3. Bu soruna sahip olan ve birbirini tanıyan bir avuç insan zaten var mı, yoksa web sitesi var olduğu için yabancıların bir ekip olacağını mı umuyorsunuz?

Üçü de belirsiz yanıtlar alırsa, bir topluluk inşa etmiyorsunuz; boş bir oda inşa edip buna mimari diyorsunuz. Pratik hamle, her topluluk özelliğini ertelemek ve bunun yerine üyelik iskeletini başlatmaktır. Her zaman daha sonra bir tartışma alanı ekleyebilirsiniz ve zaten gelmek için nedenleri olan bir gruba eklendiğinde çalışma şansı vardır. Tüm soru daha uzun bir ele alışı hak ediyor — gerçek üyeleriniz olduktan sonra topluluk gelmeli — ancak tek cümlelik versiyonu: kitle var olmadan amfi tiyatroyu inşa etmeyin.

Çalışabilecek en küçük şey nedir?

Teklifi sınıflandırdıktan sonra, lansmanı bir iskelet olarak tasarlayın. Tek ödeme seçeneği, tek katman, tek kısıtlı içerik, tek iletişim döngüsü. Platformunuzun özellik listesini alın ve diğer her şeyi kapatın. Evet, platform canlı video odaları, üye profilleri, etkinlik yönetimi ve analiz panoları yapabilir. Sorun da bu.

Bir müşteri bize B2B SaaS ürünleri için tam bir topluluk vizyonu olarak adlandırdıkları şeyle geldi. Forumlardan, bir etkinlik takviminden, bir kaynak kütüphanesinden ve bir “üye vitrini” bölümünden bahsediyorlardı. Kapsam belirleme sırasında cümleyi tamamlamalarını sağladık: “Üyeler ___ aldıkları için ödüyor.” Cevapları, kurucunun tavsiyelerinin aranabilir bir arşivi ve aylık canlı soru-cevap oldu. Biz de bunu başlattık. Forum yok, üye profilleri yok, etkinlik takvimi yok. Çok geçmeden arşiv kullanılıyordu, soru-cevap oturumlarının müdavimleri vardı ve müşteri özel bir tartışma grubu istedi çünkü üyeler ürün dışında zaten birbirleriyle konuşuyordu. Grup, var olma nedeni ortaya çıktıktan sonra inşa edildi. İşe yarayan sıralama bu.

Tam vizyonu inşa etmiş olsaydık, geç başlatırdık, daha fazla hareketli parça olurdu ve hangisinin aslında alışkanlığı yarattığını söylemenin bir yolu olmazdı. Arşiv gerçek bir davranışa işaret edebilirdi; hiç kullanılmayan bir canlı oda sadece bir fatura olurdu. Ders sıkıcı ama güvenilir: lansman ne kadar küçükse, müşterinin gerçekte neyin işe yaradığını size söyleme olasılığı o kadar yüksektir. İnce bir ürün ayrıca bir sonraki şeyi iyi yapmanız için alan tanır — bir katman eklemek, bir forum açmak — lansman ayına sıkıştırılmış acele bir ekstra yerine bilinçli bir değişiklik emri olarak. Katmanlar ve gelir yapısı hakkında düşünmek için tekrarlanabilir bir yol arıyorsanız, tekrarlayan gelir için üyelik katmanları yazısına bakın, ancak önce kapsam belirleme gelir.

İstekler birikince ne olur?

Çoğu üyelik projesinin nasıl öldüğü konusunda dürüst olalım: beceriksizlikten değil, “bir şey daha” yüzünden. Müşteri bir rakibin topluluğunun demosunu görür ve aynı özelliği ister. Doğru yanıt “evet” değil, “hayır” da değil — “bunu ertelenen listeye ekleyelim.”

Ertelenen özellikler listesini projenizde birinci sınıf bir teslimat haline getirin. Teklife koyun, görünür tutun ve kapsam dışı her talebi ona ekleyin. Her öğeye bir tetikleyici koşul verin. “Bir gün” değil, “bu, 200 aktif üye bir ay boyunca alanda olduğunda yayınlanır” veya “müşteri haftada iki saat personel zamanını moderasyona ayırdığında.” Zorluk çıkarmıyorsunuz; özelliğe var olma nedeni veriyorsunuz.

Her yeni müşteriyi, bilinçli olarak inşa etmediğiniz şeylerin bir listesiyle birlikte, daha önce teslim ettiğiniz bir iskeletin yapılandırması olarak ele alarak her müşteri için aynı üyelik sitesini yeniden inşa etmeyi bırakırsınız. Bir özellik ertelenen listedeyse, bu gelecekteki bir projedir ve aynı zamanda gelecekteki gelirdir. Bu şekilde çerçevelerseniz, müşteri genellikle kabul eder.

Müşterinin boş forum için bizi suçlamasını nasıl engelleriz?

Neyi kontrol edebileceğiniz ve edemeyeceğiniz konusunda beklentileri erken ve yazılı olarak belirlemeniz gerekir. Ödeme akışını, kısıtlamaları, e-posta otomasyonlarını ve tasarımı teslim edebilirsiniz. İnsanların birbirleriyle konuşmaya karar vermesini teslim edemezsiniz. Müşterinin “etkileşim sorunu” bir inşa sorunu değildir; bir operasyon sorunudur ve bu onların kucağındadır.

Bu önemlidir çünkü müşteriler lansmandan üç hafta sonra sessizce “topluluğun” neden sessiz olduğunu sormaya başlayacaklardır. Sınırı baştan belirlerseniz, teşvikler ve tohumlama hakkında faydalı bir konuşma yapabilirsiniz. Belirlemediyseniz, bozuk olmayan bir platformda hata ayıklıyor olacaksınız. Bunu resmileştirmenin pratik bir yolu: bakım anlaşmanıza “topluluk barındırma ve tohumlama” için ayrı bir kalem ekleyin veya müşteriye proje başlangıcında yer alan bir tohumlama kontrol listesi verin. Amaç, iş bölümünü açık hale getirmektir. Araç, elde tutma stratejisi değildir; insanlar bir platformun kendi satışlarını yapmasını beklediklerinde genellikle üyelik sitesi mitleri suçludur.

Yine de bir toplulukta ısrar ederlerse, neyi açıyoruz?

Müşteri gerçeklik kontrolünü geçerse ve gerçekten bir topluluk işletiyorsa, tam olarak bir tartışma formatını açın. Üç değil. Bir forum iş parçacıklı, aranabilir ve eşzamansızdır; bir canlı oda anında, geçicidir ve personel gerektirir. Küçük bir ekiple ikisini de iyi yönetemezsiniz ve bunu yapmaya çalışmak müşterinize “topluluğun” sürekli aktivite anlamına geldiğini öğretir; bu da söz vermemeniz gereken bir standarttır.

Pratik kural: tek alan, tek format, tek adlandırılmış moderatör. Gerçeklik kontrolünde belirlediğiniz davranışa uyan formatı seçin. İstenen davranış “bir soru sor ve cevap al” ise, bir forumla başlayın. “Salı öğlen zorlukları konuşmak için gel” ise, canlı bir etkinlikle başlayın. Ardından ilk doksan gün için hafif bir metrik belirleyin: toplam üye değil, kayıtlar değil, hedef davranışı en az iki kez yapan üye sayısı. İki aktivite bahsi, alanın canlı mı yoksa bir müze mi olduğunu bilmek için yeterlidir.

Bunu bir kurtarma görevi değil de bir ürün hattı olacak şekilde nasıl fiyatlandırırız?

Keşif konuşmasının kendisini faturalandırılabilir bir ürün haline getirin. Kapsam belirleme görüşmesi, iskelet inşası (evet, gerçekten), ödeme yapılandırması ve bir tur revizyonu içeren sabit ücretli bir üyelik sitesi kurulum paketi oluşturun. Bunun ötesindeki her şey — topluluk tasarımı, özel özellikler, moderasyon saatleri, entegrasyonlar — ayrı bir iş tanımıdır. Tüm püf noktası bu. Her isteğe bağlı özelliği bir değişiklik emri olarak teklif ettiğinizde, müşteri aniden önceliklendirmeyi öğrenir. Her şeyi tek bir artan tahminde birleştirdiğinizde, onlara daha fazla kapsamın ücretsiz olduğunu öğretirsiniz.

Tekrarlanabilir bir süreç şuna benzer: görüşmeden önce gönderdiğiniz bir anket, sabit fiyatlı tek sayfalık bir iş tanımı, ekibinizin daha önce uyguladığı bir inşa programı ve ertelenen özellikler listesi için bir şablon. Tasarım moodboard'u oluşmadan müşteriye yayın tarihini söyleyebilmelisiniz. Ayrıca daha iyi bir konuşma elde edersiniz: müşteri asgari maliyetin ne olduğunu, topluluk ekstralarının maliyetini ve kendi zamanlarının maliyetini görür. Bir iskelet için ödeme yapmaktan kaçınırlarsa, bunu acıtmadan önce öğreneceksiniz.

Kimsenin duymak istemediği kısım

Her üyelik sitesi, tekrarlayan bir davranış üzerine bir bahistir. Platform sadece zarftır. Bunu birçok müşteri için inşa eden kişi olarak işiniz, kimsenin elle canlı bir performans sergilemek için kaydolmadığından emin olurken zarfa adres yazıp pul yapıştırmaktır. Bir topluluğu gerçekleştiremezsiniz. Koşulları yaratabilir, mümkün olan en küçük sürümü seçebilir ve müşteriye neyi inşa etmediğinizin net bir listesini verebilirsiniz.

Bu son kısım sizin gerçek değerinizdir. Müşteri sizi neyi dışarıda bırakacağını göremediği için işe aldı. Bu yüzden onlar için dışarıda bırakın — kendinden emin, bilinçli ve yazılı olarak. Kapsamı belirledikten sonra, teslimat neredeyse sıkıcı hale gelir: üyelik sitesi lansmanları gerçekten yayınlanır küçük olduklarında ve kararlar önceden verildiğinde. Boş forumlar ve geniş özel portallar pahalıdır. Zamanında teslim edilen iskelet, hiç tam olarak yayınlanmamış “güçlü topluluk platformundan” çok daha değerlidir.