अपनी योजनाएँ तैयार करना

ग्राहकों की अलग-अलग परिस्थितियों से शुरुआत करें

मूल FitSite उदाहरण एकल प्रशिक्षकों, स्थापित जिमों और बहु-स्थान वाले व्यवसायों को अलग करता है। ये उपयोगी परिकल्पनाएँ हैं क्योंकि कार्य अलग हो सकता है: एक प्रशिक्षक को स्पष्ट पेशेवर उपस्थिति चाहिए, व्यस्त जिम को अधिक समृद्ध समय-सारिणी और बुकिंग कार्यप्रवाह की आवश्यकता हो सकती है, और एक चेन को स्थान-विशिष्ट जानकारी चाहिए हो सकती है।

यह न मानें कि कर्मचारियों की संख्या ही सही उत्पाद तय करती है। एकल प्रशिक्षक ऑनलाइन बुकिंग पर बहुत निर्भर हो सकता है, जबकि बड़े जिम के पास पहले से कोई ऐसी प्रणाली हो सकती है जिसे वह बनाए रखना चाहता हो। कार्यप्रवाह, जटिलता, सहायता और पैमाने में सार्थक अंतर पहचानने के लिए साक्षात्कार करें। योजनाओं में रूढ़ियों के बजाय वे अंतर प्रतिबिंबित होने चाहिए।

किसी अन्य SaaS व्यवसाय के लिए विभाजन रेखा एक परियोजना बनाम टीम कार्यप्रवाह, कभी-कभार उपयोग बनाम बार-बार होने वाला काम, या एक स्थान बनाम कई स्थान हो सकती है। समझ में आने वाली परिस्थितियों की एक छोटी संख्या चुनें। उदाहरणों में तीन स्तर सामान्य हैं, लेकिन शुरुआत के लिए एक अच्छा प्रस्ताव या दो स्पष्ट विकल्प पर्याप्त हो सकते हैं।

फ़ीचर सूची से पहले वादा लिखें

हर योजना के लिए ग्राहक के उपयोगी परिणाम को समझाने वाला एक वाक्य लिखें। फिर उसे प्रदान करने के लिए आवश्यक फ़ीचर और सेवा कार्य सूचीबद्ध करें। यदि आप उस परिणाम में किसी फ़ीचर की भूमिका नहीं समझा सकते, तो पुनर्विचार करें कि क्या वह शुरुआती प्रस्ताव में होना चाहिए।

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

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

FitSite मैट्रिक्स को एक कार्यशील उदाहरण के रूप में उपयोग करें

• स्टार्टर — उदाहरणात्मक $49/माह: Studio Essential टेम्पलेट, मुख्य व्यावसायिक जानकारी और संपर्क मार्ग वाली एक स्टूडियो वेबसाइट। स्पष्ट रूप से बताएँ कि बुकिंग लिंक और कस्टम डोमेन शामिल हैं या नहीं।
• ग्रोथ — उदाहरणात्मक $99/माह: खरीदार के लिए उपयुक्त अतिरिक्त टेम्पलेट विकल्पों और परीक्षित बुकिंग या सामग्री कार्यप्रवाह वाली एक वेबसाइट। सहायता और एकीकरण की सीमाएँ शामिल करें।
• प्रो — उदाहरणात्मक $199/माह: प्रासंगिक टेम्पलेट और रखरखाव के दायरे के साथ, सहमत बहु-स्थान व्यवस्था, जैसे अधिकतम पाँच साइटों, के लिए सहायता।

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

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

मैट्रिक्स को उत्पाद सेटिंग्स में बदलें

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

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

अनुमतियों को मार्केटिंग से अलग समझें। ग्राहकों को अपनी सामग्री बनाए रखने के लिए आवश्यक पहुँच दें, और प्लेटफ़ॉर्म प्रशासन को अपने नियंत्रण में रखें। केवल नेटवर्क व्यवस्थापक के दृष्टिकोण से समीक्षा करने के बजाय हर योजना पर एक नए ग्राहक खाते का परीक्षण करें।

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

उन्हें बेचने से पहले अपग्रेड और डाउनग्रेड डिज़ाइन करें

योजनाओं के बीच जाने पर क्या बदलता है, यह ग्राहक को समझ में आना चाहिए। Ultimate Multisite में, इंस्टॉल किए गए संस्करण के लिए योजना-समूह और अपग्रेड/डाउनग्रेड सेटिंग्स की समीक्षा करें, फिर अनुमत परिवर्तनों का परीक्षण करें। स्टार्टर, ग्रोथ, प्रो जैसा दृश्य क्रम तभी उपयोगी है जब अंतर्निहित परिवर्तन व्यवहार उससे मेल खाता हो।

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

जहाँ समर्थित हो, नियंत्रित भुगतान परीक्षण वातावरण में योजना परिवर्तनों का परीक्षण करें। नवीनीकरण तिथियों, प्रदर्शित कीमतों, अधिकारों और ग्राहक ईमेल की समीक्षा करें। ऐसी हर चीज़ दर्ज करें जिसमें मैन्युअल सहायता चाहिए, ताकि आप उसकी कीमत तय कर सकें और उसे ईमानदारी से समझा सकें।

वैकल्पिक अतिरिक्त चीज़ें सीमित रखें

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

हर ऐड-ऑन के लिए इकाई, कीमत, बिलिंग अंतराल, रद्दीकरण व्यवहार और डिलीवरी की जिम्मेदारी तय करें। “प्राथमिकता सहायता” के लिए ठोस दायरा और प्रतिक्रिया अपेक्षा चाहिए; इसका अर्थ समाधान की गारंटी नहीं होना चाहिए। अतिरिक्त स्टोरेज के लिए मापने योग्य अनुमति और यह स्पष्ट परिभाषा चाहिए कि क्या वह साझा है।

ऐड-ऑन को स्पष्ट रूप से वैकल्पिक रखें और पहले से चुने गए शुल्कों से बचें। पाठ 6 में चेकआउट पर प्रस्ताव प्रस्तुत करना शामिल है। अतिव्यापी अधिकारों वाले बड़े बंडल संग्रह की तुलना में एक सरल खरीद निर्णय का परीक्षण और समर्थन करना आसान है।

आगे बढ़ने से पहले

• योजनाओं को उपयोगी ग्राहक परिस्थितियों से मेल खाना चाहिए और उन्हें प्रदान करना व्यावहारिक रहना चाहिए।
• उदाहरण कीमतें तब तक धारणाएँ हैं जब तक लागतें और ग्राहक प्रमाण उनका समर्थन न करें।
• केवल मूल्य तालिका पर निर्भर रहने के बजाय सीमाओं, प्लगइन उपलब्धता, अपग्रेड और डाउनग्रेड का परीक्षण करें।

स्रोत और आगे पढ़ें

मूल वेबसाइट-बिज़नेस पाठ से अनुकूलित। Ultimate Multisite: योजनाएँ, सीमाएँ और प्लगइन नियंत्रण

पिछला पाठ · सभी 14 पाठ देखें