सदस्यता साइट का लॉन्च जो वास्तव में लाइव होता है

सारांश

जब कोई क्लाइंट सदस्यता साइट माँगता है, तो वे जिन फीचर्स की सूची देते हैं वे लगभग कभी उत्पाद नहीं होते। उत्पाद एक आवर्ती भुगतान है जो किसी विशिष्ट चीज़ के बदले में होता है — और बाकी सब कुछ एक देरी है जो फीचर के रूप में छिपी होती है।

एजेंसी के लिए, इसका मतलब है लॉन्च वार्तालाप को मानकीकृत करना: मूल्य विनिमय को एक वाक्य में परिभाषित करें, सबसे छोटे फीचर सेट का नक्शा बनाएँ जो उसका समर्थन करता है, और उस प्लंबिंग के लिए कस्टम बिल्ड चलाने से मना करें जो प्लेटफ़ॉर्म पहले से करता है।

यह लेख उन आपत्तियों पर काम करता है जो आप क्लाइंट्स और आंतरिक हितधारकों से सुनेंगे, और ऐसे प्रति-तर्क देता है जो समयसीमा को ईमानदार रखते हैं।

आप एक सदस्यता साइट को तिमाहियों में नहीं, हफ्तों में लॉन्च कर सकते हैं, जब आप 'समुदाय' और 'कोर्स होस्टिंग' को लॉन्च की आवश्यकता के रूप में मानना बंद कर देते हैं।

हर सदस्यता साइट प्रोजेक्ट नौ महीने के महाकाव्य में क्यों बदल जाता है?

क्योंकि हम लॉन्च को उस क्षण के रूप में मानते रहते हैं जब क्लाइंट की पूरी दृष्टि लाइव होती है। ऐसा कभी नहीं होता। दृष्टि एक प्लेटफ़ॉर्म के सेल्स पेज से फीचर्स की एक स्प्रेडशीट है; लॉन्च वह पहला बिंदु है जहाँ कोई पैसे के बदले एक्सेस लेता है।

एजेंसी के लिए, एक साल में तीन सदस्यता साइट शिप करने और एक शिप करने के बीच का अंतर यह है कि उस अंतर को ज़ोर से स्पष्ट करने की क्षमता हो, एक से अधिक बार, बिना क्लाइंट को यह महसूस कराए कि उनके साथ अन्याय हो रहा है।

यह किसी विशिष्ट प्लेटफ़ॉर्म के लिए गाइड नहीं है। यह उन तर्कों के लिए एक फील्ड गाइड है जो आपके खिलाफ इस्तेमाल किए जाएँगे, और उन एज केसों के लिए जो आपकी समयसीमा को खाने की कोशिश करेंगे।

"जब तक यह पूर्ण न लगे, हम लॉन्च नहीं कर सकते।"

क्लाइंट के अपने शब्दों से शुरू करें: "हमें पहली छाप बनाने का केवल एक मौका मिलता है।" यह उनके ब्रांड के लिए सच है, उनकी फीचर सूची के लिए नहीं।

कुछ सदस्य इसलिए रद्द करते हैं क्योंकि पहले दिन बैज सिस्टम गायब था; वे इसलिए रद्द करते हैं क्योंकि जिस चीज़ के लिए उन्होंने भुगतान किया था वह नहीं मिली। असल में, वे ज़्यादातर चुपचाप चले जाते हैं, लेकिन यह एक और लेख है।

सदस्यता प्लेटफ़ॉर्म बाजार इस आपत्ति को और खराब करने के लिए बनाया गया है। मानक उत्पाद मेनू में चर्चा स्थान, लाइव वीडियो रूम, सदस्य प्रोफाइल, इवेंट प्रबंधन, एनालिटिक्स, कोर्स होस्टिंग, भुगतान प्रसंस्करण और टियरड एक्सेस शामिल हैं — सभी एक सदस्यता में। प्रत्येक एक वैध क्षमता है। उनमें से कोई भी लॉन्च की आवश्यकता नहीं है। यदि आप एक खाली प्रोजेक्ट खोलते हैं और कहते हैं "हमें क्या शामिल करना चाहिए?", तो क्लाइंट कहेगा "सब कुछ"। यह दायरे की समस्या नहीं है, यह मेनू की समस्या है।

तो दृष्टिकोण बदलें। लॉन्च वह क्षण नहीं है जब उत्पाद पूर्ण लगता है। लॉन्च वह क्षण है जब चक्र बंद होता है: सदस्य भुगतान करता है, सदस्य को वह चीज़ मिलती है जिसके लिए वे आए थे, सदस्य को लगता है कि यह अगले भुगतान के लायक था। बाकी सब कुछ बाद की पुनरावृत्ति है।

इसे संप्रेषित करने का एक उपयोगी तरीका तीन-स्तंभ तालिका है:

प्लेटफ़ॉर्म मेनू का वादा	लॉन्च को वास्तव में क्या चाहिए	क्या इंतज़ार कर सकता है
फ़ोरम/चर्चा स्थान	मूल सामग्री वितरित करने का एक विश्वसनीय तरीका	जब कोई वास्तव में प्रश्न पूछ रहा हो
लाइव वीडियो रूम	एक शेड्यूल और होस्ट करने वाला कोई	जब आपने साबित कर दिया कि लोग आएँगे
सदस्य प्रोफाइल/निर्देशिका	एक लॉगिन जो काम करता है और एक भुगतान जो प्राप्त होता है	जब दर्शक इतने बड़े हों कि इसकी आवश्यकता हो
एनालिटिक्स	एक डैशबोर्ड जो बताता है कि नवीनीकरण हो रहे हैं या नहीं	बाकी डेटा जिसे पढ़ने के लिए आप तैयार नहीं हैं

यह हर बार एक ही चाल है: प्लेटफ़ॉर्म की मार्केटिंग ने जो फीचर सूची आपको दी है, उसे लें, और इसे "अभी लॉन्च करें", "अगली तिमाही में लॉन्च करें" और "शायद कभी नहीं" में क्रमबद्ध करें। आप पाएँगे कि वास्तविक लॉन्च सूची शर्मनाक रूप से छोटी है। यही लक्ष्य है।

"लेकिन आपकी प्रक्रिया हमारे सदस्यों के स्वभाव को संभाल नहीं सकती।"

हर क्लाइंट मानता है कि उसके सदस्य अपवाद हैं। पेशेवर संघ को कुछ अलग "चाहिए", B2B SaaS कंपनी को "चाहिए", क्रिएटर को "चाहिए"। प्लेटफ़ॉर्म स्वयं अपने संदेश को संघों, SaaS कंपनियों और क्रिएटर्स के लिए अलग-अलग करके इस सोच को मजबूत करते हैं। विभाजन वास्तविक है; निष्कर्ष नहीं।

क्लाइंट्स के बीच वास्तव में जो बदलता है वह मूल्य विनिमय है, तंत्र नहीं। एक सदस्यता साइट, हर मामले में, किसी चीज़ के चारों ओर एक पेवॉल है। प्लेटफ़ॉर्म राउंडअप आपको बताएँगे कि कुछ प्लेटफ़ॉर्म पेशेवर संघों के लिए बेहतर हैं और अन्य क्रिएटर्स के लिए, और वह विविधता उपयोगी है — लेकिन यह आखिरी निर्णय है जो आप लेते हैं, पहला नहीं।

दोहराने योग्य एजेंसी प्रक्रिया यह है कि आप कोई भी प्लेटफ़ॉर्म तुलना खोलने से पहले एक वाक्य लिखें। "सदस्य [X] पाने के लिए मासिक भुगतान करते हैं।" यदि क्लाइंट उस वाक्य को पूरा नहीं कर सकता, तो कोई प्लेटफ़ॉर्म विकल्प उन्हें नहीं बचाएगा। यदि वे कर सकते हैं, तो आप पूरे लॉन्च को X वितरित करने के इर्द-गिर्द तैयार कर सकते हैं, और उन फीचर्स को अनदेखा कर सकते हैं जिन्हें X छूता नहीं है।

यह वह जगह भी है जहाँ आप मूल्य निर्धारण की बातचीत को अलग रखते हैं। मासिक सदस्यता, वार्षिक सदस्यता, एकमुश्त भुगतान, कोर्स बंडल, प्रीमियम टियर — ये सभी मुद्रीकरण विकल्प हैं, और ये सभी X के लिए शुल्क लेने के अलग-अलग तरीके हैं। वार्षिक शुल्क लेने के लिए किसी को सामुदायिक फ़ोरम की आवश्यकता नहीं है। जैसे ही आप क्लाइंट को अपने मॉडल को "सदस्यता + समुदाय + कोर्स" के रूप में परिभाषित करने देते हैं, आप एक के बजाय तीन उत्पादों के लिए सहमत हो गए हैं। रिकॉर्ड के लिए, यही कारण है कि क्लासिक एक गैर-तकनीकी बॉस को सदस्यता साइट पिच करना आमतौर पर गलत हो जाता है: हर कोई विनिमय के बजाय फीचर्स बेचने की कोशिश करता है।

"हमारे क्लाइंट ने इसे कस्टम-निर्मित करने के लिए कहा।"

जो भी समय आप कस्टम विकास पर खर्च करने वाले थे, उसे उस एक प्रश्न में लगाएँ जिसका उत्तर क्लाइंट नहीं दे सकता: "इनमें से कौन सा फीचर उत्पाद है, और कौन सा पैकेजिंग है?" अधिकांश कस्टम अनुरोध ऐसी पैकेजिंग के लिए होते हैं जो सदस्यता प्लेटफ़ॉर्म पहले से ही एक चेकबॉक्स के रूप में प्रदान करता है। कस्टम कार्य उत्पाद के उस हिस्से के लिए आरक्षित होना चाहिए जो वास्तव में क्लाइंट को उनके बाजार में अलग पहचान देता है — किसी सदस्य निर्देशिका के लिए नहीं जो उद्योग द्वारा छाँटती है।

एक ठोस उदाहरण: एक क्लाइंट एक सूची लेकर हमारे पास आया जिसमें एक प्रमाणन निर्देशिका, एक लाइव प्रश्नोत्तर कक्ष, एक त्रैमासिक वर्चुअल समिट, और एक कस्टम मिलान टूल शामिल था। मिलान टूल ही उत्पाद था; निर्देशिका, प्रश्नोत्तर कक्ष और समिट सभी पैकेजिंग थे। हमने कस्टम कार्य को मिलान टूल तक सीमित कर दिया, एक साधारण सदस्य लॉगिन और भुगतान पृष्ठ के साथ लॉन्च किया, और बाकी को अठारह महीनों के लिए "बाद में" सूची में रहने दिया। क्लाइंट ने देखा कि निर्देशिका अप्रासंगिक हो गई और उसे बिना छह अंकों के निर्माण के एक काम करने वाला उत्पाद मिल गया। वह सबक पूरी अकाउंट टीम के साथ चिपक गया।

चेतावनी: यदि क्लाइंट एक ऐसे क्षेत्र में है जहाँ प्लेटफ़ॉर्म की मानक विशेषताएँ वास्तव में उनके बाजार में फिट नहीं बैठतीं — मान लीजिए, एक संघ जिसे विभिन्न अनुमोदन वर्कफ़्लो के साथ सैकड़ों चैप्टर-स्तरीय सदस्यों से बिल करना है — तो एक कस्टम बिल्ड प्लेटफ़ॉर्म से लड़ने की तुलना में वैध रूप से सस्ता हो सकता है। लेकिन यह एक आला है, डिफ़ॉल्ट नहीं। डिफ़ॉल्ट यह है कि कस्टम विकास वह जगह है जहाँ सदस्यता प्रोजेक्ट उन चीज़ों पर पैसा खर्च करने जाते हैं जिन्हें सदस्य कभी नहीं देखते।

"हम एक समुदाय का प्रबंधन नहीं कर सकते।"

अच्छा। तो फिर समुदाय लॉन्च मत करें।

हर जुड़ाव लेख जो आपने कभी पढ़ा है वह कहता है कि समुदाय ग्राहक बनाए रखने की कुंजी है, और अंततः यह है। लेकिन समुदाय एक धारण (retention) सुविधा है, लॉन्च की नहीं। एक फ़ोरम जिसमें तीन महीने तक कोई पोस्ट नहीं करता, वह कोई फ़ोरम न होने से बुरा है; यह सबको बताता है कि जगह मृत है। एक खाली लाइव वीडियो रूम एक अच्छे ईमेल कोर्स से भी बुरा है। यदि क्लाइंट के पास कोई ऐसा व्यक्ति नहीं है जो सप्ताह में कम से कम कुछ घंटे प्रश्नों का उत्तर देने और चर्चा शुरू करने में बिता सके, तो पहले कंटेंट पक्ष लॉन्च करें और समुदाय तब जोड़ें जब इसे जीवंत महसूस कराने के लिए पर्याप्त संख्या हो।

यह विरोधाभासी हिस्सा है: एक एजेंसी के लिए, "हम समुदाय का प्रबंधन नहीं कर सकते" एक आपत्ति नहीं है; यह एक उपहार है। इसका मतलब है कि आप क्लाइंट को उस परिचालन लागत के लिए प्रतिबद्ध किए बिना लॉन्च कर सकते हैं जिसके लिए उन्होंने बजट नहीं बनाया है। बाद में, जब सदस्यता आधार इतना बड़ा हो जाए कि लोग पहले से ही एक-दूसरे से बात करने के लिए पूछ रहे हों, तो आप अपने सदस्यता समुदाय में जुड़ाव बढ़ा सकते हैं एक ऐसे फीचर के साथ जिसे चलाने के लिए कोई चैंपियन हो।

यहाँ कार्रवाई कदम एक चेकलिस्ट है जो हर क्लाइंट पर लागू होती है, कोई अपवाद नहीं। हर प्रस्तावित फीचर के लिए पूछें: "लॉन्च के बाद इसका मालिक कौन है?" यदि उत्तर उनके कैलेंडर में समय वाला कोई नामित व्यक्ति नहीं है, तो फीचर शिप नहीं होता। सदस्य प्रोफाइल? प्रोफाइल अनुमोदित करने के लिए किसी की आवश्यकता है। लाइव वीडियो? होस्ट की आवश्यकता है। चर्चा फ़ोरम? मॉडरेटर की आवश्यकता है। प्लेटफ़ॉर्म प्लंबिंग प्रदान कर सकता है; यह काम का बोझ प्रदान नहीं कर सकता।

"हमें लॉन्च से पहले सब कुछ माइग्रेट करना होगा।"

माइग्रेशन संगठित लोगों की पसंदीदा देरी है। क्लाइंट के पास हजारों ईमेल ग्राहक हैं, एक दशक के लेख, एक पीडीएफ कोर्स, सदस्यों की एक पुरानी स्प्रेडशीट जिसमें एक्सेस समाप्ति तिथियाँ हैं, और वे निश्चित हैं कि यह सब नई प्रणाली में होना चाहिए, इससे पहले कि आप किसी से शुल्क ले सकें।

ऐसा नहीं है। लॉन्च के समय आपको तीन चीज़ों की आवश्यकता है: जो लोग भुगतान करने वाले हैं, उनके पैसे लेने का एक तरीका, और जिस सामग्री के लिए वे भुगतान कर रहे हैं। बाकी सब कुछ साइट लाइव होने पर माइग्रेट किया जा सकता है। साप्ताहिक कटओवर, "नए सदस्यों को इस तिथि से आगे का संग्रह मिलता है," और एक इम्पोर्ट जो सप्ताहांत पर चलता है — इनमें से कोई भी उस लॉन्च से बेहतर है जो डेटा सफाई की महिमा की प्रतीक्षा करता है।

यह एजेंसी की चाल है: एक माइग्रेशन कटओवर तिथि निर्धारित करें और उसका सम्मान करें। न्यूनतम व्यवहार्य डेटा सेट के साथ लॉन्च करें। यदि क्लाइंट जोर देता है कि पुराने सदस्यों को पुरानी सामग्री तक पहुंच बनाए रखनी चाहिए, तो यह आपकी "इस लॉन्च में नहीं" सूची के लिए एक फीचर है — प्लेटफ़ॉर्म लगभग निश्चित रूप से एक्सेस स्तरों का समर्थन करता है, इसलिए आप पुरानी प्रणाली को पठनीय रख सकते हैं और नए सदस्यों को नई प्रणाली की ओर इंगित कर सकते हैं। आपको संक्रमण अवधि के लिए दो प्रणालियाँ रखने की अनुमति है। आपको सही डेटा को लाइव उत्पाद को अवरुद्ध करने की अनुमति नहीं है।

"हमें एक ऐसा प्लेटफ़ॉर्म चाहिए जो सब कुछ करता हो।"

इस बिंदु पर, कॉल पर कोई व्यक्ति एक ऐसे टूल की माँग करेगा जो सदस्यता सुविधाओं, सामुदायिक फ़ोरम, कोर्स होस्टिंग, भुगतान प्रसंस्करण, और एक कस्टम लैंडिंग पृष्ठ के "वाह" डिज़ाइन को जोड़ता है। इसे ऑल-इन-वन जाल कहें: यह एक बिल्ड को खोज में बदल देता है, और खोज कभी समाप्त नहीं होती क्योंकि कोई भी एक उत्पाद वस्तुनिष्ठ रूप से सब कुछ में अच्छा नहीं है।

इसे हल करने का तरीका यह है कि प्लेटफ़ॉर्म को ऑल-इन-वन ब्रह्मांड के रूप में मूल्यांकन करना बंद करें और पूछें कि इस क्लाइंट के लॉन्च का वास्तव में सबसे धीमा, सबसे जोखिम भरा हिस्सा क्या है। यदि जोखिम भुगतान और एक्सेस है, तो उस प्लेटफ़ॉर्म को चुनें जो उन पर उबाऊ रूप से विश्वसनीय है। यदि जोखिम स्वयं सदस्यता बेचना है, तो प्राथमिकता एक लैंडिंग पृष्ठ है जो रूपांतरित करता है और एक चेकआउट जो समझदार लगता है — और उसके लिए आपको प्लेटफ़ॉर्म की दसवीं सुविधा की आवश्यकता नहीं है। सदस्यता प्लेटफ़ॉर्म चुनने से पहले आप जो मुख्य प्रश्न पूछते हैं लॉन्च के बारे में होने चाहिए, किसी दिन के फीचर्स के बारे में नहीं।

और यहाँ वह हिस्सा है जिसे छोड़ना आसान है: फीचर खोज को डिज़ाइन में देरी करने का तरीका न बनने दें। जब क्लाइंट कहता है "हम एक आधुनिक, पॉलिश उपस्थिति चाहते हैं जो हमारे ब्रांड को दर्शाती है," तो यह एक वास्तविक आवश्यकता है। लेकिन एक लॉन्च पृष्ठ को सब कुछ में महान होने के लिए किसी प्लेटफ़ॉर्म की आवश्यकता नहीं है; उसे विनिमय को स्पष्ट रूप से समझाना, कीमत दिखाना, और रास्ते से हट जाना चाहिए। एक एजेंसी के लिए, वाक्यांश "हम लॉन्च के बाद फिर से डिज़ाइन करेंगे" लॉन्च के लिए एक प्रतिबद्धता है, गुणवत्ता से समझौता नहीं।

निष्कर्ष: लोगों के लिए भुगतान करने लायक सबसे छोटी चीज़ लॉन्च करें, फिर सोमवार को जोड़ें।

आवर्ती राजस्व पूर्ण दृष्टि बनाने का इनाम नहीं है; पूर्ण दृष्टि आवर्ती राजस्व के साथ बनाई जाती है। यदि आप उस वाक्य को अपने सामने रखते हैं, तो आपत्तियाँ स्वयं हल हो जाती हैं। "जब तक यह पूर्ण न लगे, लॉन्च नहीं कर सकते" बन जाता है "पूर्णता एक चलता लक्ष्य है, इसलिए न्यूनतम लॉन्च करें और सीखना शुरू करें।" "हमारे सदस्य अलग हैं" बन जाता है "बढ़िया, तो मूल्य विनिमय अलग है — चलिए वाक्य लिखते हैं।" "हमें यह कस्टम चाहिए" बन जाता है "कस्टम उत्पाद के लिए है, प्लंबिंग के लिए नहीं।" "हम समुदाय का प्रबंधन नहीं कर सकते" बन जाता है "हम भुगतान वाला मूल लॉन्च करेंगे और समुदाय तब जोड़ेंगे जब उसका कोई मालिक होगा।" "हमें पहले माइग्रेट करना होगा" बन जाता है "हम उन लोगों को माइग्रेट करेंगे जो भुगतान करते हैं और बाकी को बाद के लिए छोड़ देंगे।"

वह अनुशासन वास्तविक सेवा है जो आप बेच रहे हैं। क्लाइंट सोचते हैं कि वे एक सदस्यता साइट खरीद रहे हैं। वे वास्तव में क्या खरीद रहे हैं, वह एक वास्तविक आवर्ती-राजस्व लूप को उन फीचर्स से अलग करने की आपकी क्षमता है जो एक उत्पाद की तरह दिखते हैं लेकिन केवल उसे विलंबित करते हैं। पिच पर ऐसा अच्छी तरह से करें, और आप इसे अगले क्लाइंट के लिए फिर से कर पाएँगे — जो, यदि आप एक एजेंसी हैं, तो पूरा मुद्दा है।