- जब 'उपयोगकर्ता उत्पाद का उपयोग करता है लेकिन भुगतान की स्वीकृति उसी के पास नहीं होती', तब सबसे अहम बात यह समझना है कि असल अधिकार और प्रभाव किसके पास है
- वास्तविक अधिकार रखने वाला निर्णयकर्ता ज़रूरी नहीं कि खरीदार या शुरुआती उपयोगकर्ता के समान व्यक्ति हो
- छोटे संगठनों में समय की बचत महत्वपूर्ण होती है, इसलिए डेवलपर खुद टूल अपनाकर ऊपर के लोगों को राज़ी करके खरीद तक ले जा सकता है
- बड़े संगठनों में security और process की पाबंदियाँ कड़ी होती हैं, इसलिए खरीद का निर्णय CTO या प्रबंधन के पास होता है, और लंबा sales cycle चाहिए
- खरीद की स्वीकृति देने वाला व्यक्ति ज़रूरी नहीं कि बजट रखने वाला भी हो; जो व्यक्ति उत्पाद का मूल्य सबसे अधिक महसूस करता है और उसे आगे बढ़ा सकता है, वही मुख्य target बनता है
- प्रभावी रणनीति यह है कि उपयोगकर्ता प्रबंधन को समझा सके, इसके लिए ठोस data और persuasion material दिया जाए और उस प्रक्रिया को support किया जाए
- अंतिम सफलता इस बात में है कि उपयोगकर्ता internal sales की भूमिका निभा सके, इसके लिए उसे सहारा देने वाली process design की जाए
शुरुआत – सवाल की पृष्ठभूमि
- जब उत्पाद का वास्तविक उपयोगकर्ता और खरीद का निर्णय लेने वाला ग्राहक अलग-अलग हों, तब approach कैसे होना चाहिए?
- इसका संदर्भ सामान्यतः B2B software sales है, जहाँ डेवलपर पहले उत्पाद को आज़माता है और CTO या Director of Engineering अंतिम निर्णय लेते हैं
अधिकार से जुड़ा मूल प्रश्न
- 'वास्तव में ताकत किसके पास है?' यही सबसे केंद्रीय बिंदु है
- केवल card payment की permission या उत्पाद को आज़माने की प्राथमिकता ही नहीं, बल्कि वास्तविक प्रभाव और motivation खरीद की प्रक्रिया में निर्णायक होते हैं
संगठन संरचना के अनुसार परिदृश्य
छोटे संगठनों में: संरचना सपाट होती है और निर्णय तेज़ी से होते हैं
- अक्सर डेवलपर ही उत्पाद खोजता है और वास्तव में अपनाने की पहल करता है
- CTO की मुख्य प्रेरणा तेज़ी से market में जाना और iterate करना होती है, इसलिए डेवलपर द्वारा सुझाया गया टूल निर्णय पर बड़ा प्रभाव डालता है
- डेवलपर जल्दी और मुफ्त में टूल आज़माता है, और बाद में paid adoption तक पहुँचना Trojan-horse शैली के प्रसार का आम रूप है
बड़े संगठनों में: security और compliance प्रमुख बाधाएँ होती हैं
- यहाँ security जैसी समय के अलावा अन्य बाधाएँ मौजूद होती हैं, और leadership का निर्णय पूरी प्रक्रिया में महत्वपूर्ण भूमिका निभाता है
- उपयोगकर्ता (डेवलपर) को अपनी तरफ़ से install या खरीद की अनुमति नहीं होती, और sales cycle लंबा व जटिल होता है
- value/risk को देखने का मानक UI/UX या DX से ज़्यादा security और final output पर केंद्रित होता है
वास्तविक प्रभाव और मूल्य का दृष्टिकोण
- बजट होल्डर हमेशा वास्तविक अधिकार वाला व्यक्ति नहीं होता
- महत्वपूर्ण यह है कि 'किसके पास leverage है' और 'किसके incentive से process सबसे ज़्यादा आगे बढ़ती है'
- व्यवहारिक रूप से यह समझना ज़रूरी है कि कीमत के बदले वास्तव में मूल्य का आदान-प्रदान करने वाला पक्ष कौन है
उत्पाद अपनाने की प्रक्रिया का एक ठोस उदाहरण
- उपयोगकर्ता/डेवलपर उत्पाद के लिए sign-up करता है
- free trial को local environment में इस्तेमाल करता है
- वास्तविक feature value (जैसे: Pull Request के पहले/बाद की तुलना, समस्या highlight) को सीधे अनुभव करता है
- value को समझना → काम की efficiency और automation की अपेक्षा
- उपयोगकर्ता leadership को इसकी ज़रूरत के बारे में मनाता है
- leadership internal testing और बजट समीक्षा के बाद approve या reject करती है
- leadership अंतिम खरीद को approve करती है
- उत्पाद खरीद पूरी होती है, और संगठन के भीतर आगे फैलाव होता है
दोनों पक्षों के incentive पर सवाल
- डेवलपर के टूल सुझाने की मूल प्रेरणा समझें (काम की सुविधा, व्यक्तिगत क्षमता को उभारना, कंपनी के लक्ष्य पूरे करना आदि)
- leadership की खरीद प्रेरणा समझें (development efficiency बढ़ाना, कंपनी के लक्ष्य जल्दी हासिल करना आदि)
- यदि ये मुख्य प्रेरणाएँ मौजूद हैं, तो निम्न रणनीतियाँ सुझाई जाती हैं
व्यावहारिक response strategy
- उपयोगकर्ता leadership को मना सके, इसके लिए सटीक पहले/बाद की तुलना वाली report जैसे persuasion tools उपलब्ध कराएँ
- इस प्रक्रिया में abstract सलाह नहीं, बल्कि quantitative data पर आधारित परिणाम महत्वपूर्ण हैं
- "पहले के तरीके की तुलना में कितना समय बचा" जैसी ठोस संख्याएँ मनाने की कुंजी हैं
- वास्तविक खरीद बातचीत कैसे आगे बढ़ती है, इसे customer (developer) interviews से समझें, ताकि persuasion process की बाधाएँ पहले से दूर की जा सकें
- यानी, खरीद की स्वीकृति देने वाले को सीधे मनाने के बजाय, उपयोगकर्ता internal sales की भूमिका सफलतापूर्वक निभा सके, इसके लिए पूरा पर्यावरणीय support और ठोस सामग्री देनी चाहिए
- इस प्रक्रिया में उपयोगकर्ता की सफलता ही vendor की सफलता से सीधे जुड़ती है (उपयोगकर्ता-vendor-leadership-company सभी के लिए win संरचना)
निष्कर्ष और सारांश
- सबसे अच्छी रणनीति यह है कि उपयोगकर्ता को आंतरिक sales की भूमिका सफलतापूर्वक निभाने में मदद की जाए
- leadership को मनाने के लिए ज़रूरी quantitative evidence और स्पष्ट value material देने पर ध्यान होना चाहिए
- सबसे पहले संगठन के आकार और उसकी बाधाओं के अनुसार निर्णय संरचना का बारीकी से विश्लेषण किया जाना चाहिए
- अंततः, यदि उपयोगकर्ता सफल होता है, तो vendor और कंपनी दोनों साथ में सफल होते हैं — यही इस संरचना की मुख्य बात है
अभी कोई टिप्पणी नहीं है.