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