प्रति माह प्रति उपयोगकर्ता भुगतान मॉडल खराब क्यों है

बहुत से लोग हैं (हमने अपनी अंगुली से यह संकेत नहीं दिया है कि 37signals, Atlassian, Zoho, Megaplan, आदि को बंद न करें) जो विभिन्न b2b सेवाएं बनाते हैं और "प्रति माह प्रति उपयोगकर्ता" भुगतान मॉडल (प्रति उपयोगकर्ता प्रति माह) का उपयोग करते हैं। यही है, मुद्दा यह है कि आपको प्रत्येक उपयोगकर्ता के लिए मासिक भुगतान करने की आवश्यकता है। यह मुझे हाल ही में निराश कर रहा है, लेकिन आज सुबह, दही खाते समय, मुझे अचानक सब कुछ समझ में आया ।

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

ग्राहकों की बात। यदि आप ग्राहकों को सिस्टम में जाने देना चाहते हैं, तो एक और भी दिलचस्प तस्वीर प्राप्त की जाती है। जल्दी या बाद में हर कोई यह चाहता है, और सामान्य रूप से कुछ सिस्टम इसके लिए शुरू में ट्यून किए गए हैं। आपको ग्राहकों के लिए भी भुगतान करना होगा।
एक उदाहरण पर विचार करें। मान लीजिए कि 50 लोगों की एक कंपनी है जो एक साथ कई ग्राहकों की औसत सेवा देती है, इसलिए ग्राहक उपयोगकर्ताओं की कुल संख्या ~ 200 है। और यह कंपनी एक प्रणाली का उपयोग करती है जिसकी लागत प्रति माह प्रति उपयोगकर्ता 10 डॉलर है। यह पता चला है कि ग्राहकों के लिए आपको $ 24,000 एक वर्ष का भुगतान करने की आवश्यकता है, जबकि आपके लिए - $ 6,000।
लेकिन जैसा कि आप जानते हैं, किसी भी प्रणाली की कमियां विशेष रूप से आने वाले मापदंडों के सीमित मूल्यों पर स्पष्ट रूप से दिखाई देती हैं, इसलिए कल्पना करें कि एक निश्चित व्यापार मॉडल है जिसमें 5 लोग 1000 ग्राहकों की सेवा करते हैं। क्या कंपनी ऐसे सिस्टम को पेश करेगी? मुझे लगता है कि नहीं। यद्यपि यह आवश्यक है, क्योंकि प्रति कर्मचारी इतने सारे ग्राहकों के साथ, स्वचालन के लिए पर्याप्त होने की संभावना है।

दूसरी ओर, यह प्रतीत होता है कि खाते में सिस्टम की पहुंच को शामिल करने के लिए क्या समस्या है? इस उद्यम को एक अप्रिय बवासीर बनाने में बहुत सी कठिनाइयाँ हैं। सबसे पहले, सिद्धांत रूप में, क्लाइंट को यह समझाना मुश्किल है कि उसे इस प्रणाली के लिए भुगतान क्यों करना चाहिए (चलो बेहतर है कि आप बस मेल से लिखें और कॉल करें?)। दूसरे, इस भुगतान को उचित और पारदर्शी बनाना और भी कठिन है। मैं यहां विस्तार से नहीं रहूंगा, लेकिन मेरा विश्वास करो, यह मुश्किल है। अधिकांश समस्याएं उत्पन्न होती हैं क्योंकि अनुबंध और खाता आमतौर पर एक होते हैं (कभी-कभी दो, अच्छी तरह से, ठीक तीन), और ग्राहक अपने कर्मचारियों को लगातार सिस्टम से जोड़ना या निकालना चाहता है। और अगर 50 ऐसे ग्राहक हैं, तो यह बहुत कष्टप्रद होगा।

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

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

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