जब उपयोगकर्ता खरीदार न हो, तो बिक्री कैसे करें

• जब 'उपयोगकर्ता उत्पाद का उपयोग करता है लेकिन भुगतान की स्वीकृति उसी के पास नहीं होती', तब सबसे अहम बात यह समझना है कि असल अधिकार और प्रभाव किसके पास है
• वास्तविक अधिकार रखने वाला निर्णयकर्ता ज़रूरी नहीं कि खरीदार या शुरुआती उपयोगकर्ता के समान व्यक्ति हो
• छोटे संगठनों में समय की बचत महत्वपूर्ण होती है, इसलिए डेवलपर खुद टूल अपनाकर ऊपर के लोगों को राज़ी करके खरीद तक ले जा सकता है
• बड़े संगठनों में 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 सबसे ज़्यादा आगे बढ़ती है'
• व्यवहारिक रूप से यह समझना ज़रूरी है कि कीमत के बदले वास्तव में मूल्य का आदान-प्रदान करने वाला पक्ष कौन है

उत्पाद अपनाने की प्रक्रिया का एक ठोस उदाहरण

1. उपयोगकर्ता/डेवलपर उत्पाद के लिए sign-up करता है
2. free trial को local environment में इस्तेमाल करता है
3. वास्तविक feature value (जैसे: Pull Request के पहले/बाद की तुलना, समस्या highlight) को सीधे अनुभव करता है
4. value को समझना → काम की efficiency और automation की अपेक्षा
5. उपयोगकर्ता leadership को इसकी ज़रूरत के बारे में मनाता है
6. leadership internal testing और बजट समीक्षा के बाद approve या reject करती है
7. leadership अंतिम खरीद को approve करती है
8. उत्पाद खरीद पूरी होती है, और संगठन के भीतर आगे फैलाव होता है

दोनों पक्षों के incentive पर सवाल

• डेवलपर के टूल सुझाने की मूल प्रेरणा समझें (काम की सुविधा, व्यक्तिगत क्षमता को उभारना, कंपनी के लक्ष्य पूरे करना आदि)
• leadership की खरीद प्रेरणा समझें (development efficiency बढ़ाना, कंपनी के लक्ष्य जल्दी हासिल करना आदि)
• यदि ये मुख्य प्रेरणाएँ मौजूद हैं, तो निम्न रणनीतियाँ सुझाई जाती हैं

व्यावहारिक response strategy

1. उपयोगकर्ता leadership को मना सके, इसके लिए सटीक पहले/बाद की तुलना वाली report जैसे persuasion tools उपलब्ध कराएँ
   • इस प्रक्रिया में abstract सलाह नहीं, बल्कि quantitative data पर आधारित परिणाम महत्वपूर्ण हैं
   • "पहले के तरीके की तुलना में कितना समय बचा" जैसी ठोस संख्याएँ मनाने की कुंजी हैं
2. वास्तविक खरीद बातचीत कैसे आगे बढ़ती है, इसे customer (developer) interviews से समझें, ताकि persuasion process की बाधाएँ पहले से दूर की जा सकें

• यानी, खरीद की स्वीकृति देने वाले को सीधे मनाने के बजाय, उपयोगकर्ता internal sales की भूमिका सफलतापूर्वक निभा सके, इसके लिए पूरा पर्यावरणीय support और ठोस सामग्री देनी चाहिए
• इस प्रक्रिया में उपयोगकर्ता की सफलता ही vendor की सफलता से सीधे जुड़ती है (उपयोगकर्ता-vendor-leadership-company सभी के लिए win संरचना)

निष्कर्ष और सारांश

• सबसे अच्छी रणनीति यह है कि उपयोगकर्ता को आंतरिक sales की भूमिका सफलतापूर्वक निभाने में मदद की जाए
• leadership को मनाने के लिए ज़रूरी quantitative evidence और स्पष्ट value material देने पर ध्यान होना चाहिए
• सबसे पहले संगठन के आकार और उसकी बाधाओं के अनुसार निर्णय संरचना का बारीकी से विश्लेषण किया जाना चाहिए
• अंततः, यदि उपयोगकर्ता सफल होता है, तो vendor और कंपनी दोनों साथ में सफल होते हैं — यही इस संरचना की मुख्य बात है

[GN⁺]

Hacker News की राय

• कुछ डाउनलोड करना था, लेकिन संपर्क जानकारी मांगी गई, और उसके थोड़ी देर बाद से sales reps बार-बार फोन और ईमेल करने लगे; विनम्रता से मना करने पर भी अनदेखा करके लगातार मीटिंग की मांग करते रहे। इससे बेहद चिढ़ होती है। मेरे पास खरीद का अधिकार नहीं है, लेकिन मैं अपनी टीम में असंतोष फैला सकता हूँ, इसलिए आखिरकार प्रोडक्ट की छवि खराब हो जाती है। जब कोई engineer सिफारिश पूछता है, तो मैं स्वाभाविक रूप से यही बातें बताता हूँ। Veeam, AWS, Keyence इसके उदाहरण हैं.

  • IT Manager के रूप में मुझे लगभग हर हफ्ते ऐसा झेलना पड़ता है। मुझसे जवाब नहीं मिलता तो मेरे सहकर्मियों या कंपनी के दूसरे लोगों को random ईमेल भेजकर रास्ता निकालने की कोशिश करते हैं, और ऐसा होने पर हम जल्दी ही उस domain को पूरी तरह block कर देते हैं। और सिर्फ एक quote पाने के लिए demo जबरदस्ती मत दिखाइए। अगर हम पहले ही प्रोडक्ट देख चुके हैं और ज़रूरत हो तो trial भी कर चुके हैं, तो sales presentation या demo से पहले quote बताना ज़्यादा तर्कसंगत है.

  • Auth0 और Okta के साथ भी यही समस्या हुई। मेरे पास वास्तविक खरीद अधिकार और बजट दोनों थे, लेकिन संपर्क इतना ज़्यादा था कि मुझे ही उनसे नफ़रत होने लगी.

  • "असंतोष की ताकत" का विचार बहुत अच्छा है। खासकर तब, जब आप कुछ मुफ्त में दे रहे हों, लेकिन sales या marketing टीम ज़रूरत से ज़्यादा उत्साही हो; इससे उल्टा कंपनी की छवि खराब हो सकती है। ग्राहक जिस तरीके से संपर्क चाहता है, उसी तरह संपर्क करना चाहिए; अगर आप सिर्फ अपने मनमुताबिक करेंगे तो उल्टा असर होगा। लेकिन incentive design के नज़रिए से यह आसान नहीं है.

  • कुछ SaaS marketing टीमों के साथ ऐसा चरम अनुभव हुआ है कि वे हर 5~15 मिनट में ईमेल भेजती थीं। कभी-कभी यह किसी कर्मचारी की व्यक्तिगत हरकत हो सकती है, लेकिन लगता है कि कुछ जगहों पर ऊपर की management या CEO ने खुद email marketing tools को maximum पर सेट कर रखा होता है.

  • इसमें Microsoft products को भी जोड़ना चाहिए। रजिस्टर करने के लिए "professional account" बनाना पड़ता है, और उसके लिए gmail account तक स्वीकार नहीं किया जाता, यानी entry barrier काफ़ी ऊँचा है। 30-दिन का trial लेकर प्रोडक्ट evaluate करना चाहें तो account की समस्या के कारण पहुँच ही नहीं मिलती। जब trial ही इतना मुश्किल है, तो असली adoption process कितना कठिन होगा, इसकी कल्पना भी नहीं करना चाहता। AI-आधारित CRM, ERP, Dataverse वगैरह इस्तेमाल करने का मन ही नहीं होता.

• यह घटना Principal-Agent problem से आती है। कंपनी में बजट executives के पास होता है, लेकिन वास्तव में product/tool developers और field staff इस्तेमाल करते हैं। founders को अक्सर सलाह दी जाती है कि users को अपने पक्ष में कर लो ताकि वे leadership को मना सकें। मूल बात यह है कि जब आप सीधे credit card रखने वाले व्यक्ति से बात नहीं कर सकते, तो users को leadership को मनाने में जितना हो सके उतना support देना चाहिए। यानी user/developer को ही व्यवहार में sales की भूमिका निभाने देना। यह approach premium model जैसी चीज़ों पर काम कर सकती है, लेकिन hospital systems और EHR (electronic health records) जैसे उद्योगों में, जहाँ खरीद का फैसला पूरी तरह administrators लेते हैं, users को प्रोडक्ट आज़माने का मौका भी नहीं मिलता—ऐसे में इसे कैसे पार किया जाए, यही सवाल है.

  • ज़मीनी स्तर पर अक्सर इसका उल्टा भी होता है। polished salespeople बजट अधिकार रखने वालों को निशाना बनाते हैं, असली users से संचार रोकते हैं, और पहले contract sign करवा लेते हैं। जब users असंतोष जताते हैं और समस्याएँ बताते हैं, तब तक पैसे पहले ही दिए जा चुके होते हैं.

  • "Leadership को मनाने का सबसे अच्छा अवसर देना, और users को सिर्फ इतना सक्षम बनाना कि वे leadership के सामने ऐसे विकल्प रख सकें, यही उन्हें चमकदार बनाता है" — इस सलाह को लागू करने के लिए हमने भी अलग से एक "CEO Page" बनाया था: https://www.rsync.net/products/ceopage.html

• Enterprise sales के तरीके पर और जोड़ें तो, कई बार decision-maker खुद भी कंपनी के वास्तविक power dynamics को सही से नहीं समझता। साथ ही यह भी देखना पड़ता है कि वह व्यक्ति cost center में है या revenue-generating department में, वह नई technology को आगे बढ़ा रहा है या standardized product देख रहा है, और कौन लोग इस product को risk या power के लिए threat मान सकते हैं। किसे बेचना है, किससे बचना है, कब छोटे स्तर पर जाना है और कब बड़े स्तर पर—इन सबकी strategy में यह जानकारी शामिल होनी चाहिए.

• Slack और Postman अक्सर यह तरीका अपनाते हैं: "आपकी टीम के 96% लोग पहले से हमारा product इस्तेमाल कर रहे हैं। अब खरीदना तर्कसंगत नहीं लगता क्या?"

  • तब जवाब आता है, "जब सब पहले से इस्तेमाल कर रहे हैं, तो खरीदने की ज़रूरत ही क्या है?" यह सवाल buyer और user के बीच की दूरी का स्तर दिखाता है। खासकर SMEs में यह दूरी और ज़्यादा होती है.

  • छात्रों को software मुफ्त में देना भी इसी वजह से है.

  • बड़ी कंपनियों की छोटी teams में भी यह अक्सर होता है। अगर security team मौजूद हो, तो कई Slack workspaces में बँटे उपयोग को समस्या माना जा सकता है, इसलिए "400 लोग 12 workspaces में बँटे रहने के बजाय एक official account में manage करें" जैसा तर्क काम कर जाता है.

  • Commercial open source या मिलते-जुलते models का छिपा हुआ फायदा यह है कि जैसे-जैसे individual user adoption बढ़ता है, वैसे-वैसे company-wide adoption भी बढ़ता है.

• जिस कंपनी को मैंने पहले शुरू किया था, उसने भी इस समस्या का सामना किया था। हमें ऐसे dev teams को sell करना पड़ता था जिनके पास वास्तविक खरीद अधिकार नहीं थे। छोटी कंपनियों में, या कुछ अपवादों में जहाँ अधिकार वाला व्यक्ति मौजूद होता था, contract आसान था, लेकिन ज़्यादातर मामलों में लंबा sales cycle झेलना पड़ता था और cost saving को ऊपरी decision-makers तक साबित करना पड़ता था। आखिरकार यह प्रक्रिया लंबी थी और success rate कम, जो कंपनी की विफलता के बड़े कारणों में से एक बना। अच्छा लगता है कि इस पर अब ज़्यादा खुलकर बात हो रही है। कई small businesses इसे झेलते हैं, लेकिन औपचारिक सलाह आश्चर्यजनक रूप से कम मिलती है.

• जब users सीधे product इस्तेमाल कर सकते हों और उसी organization का हिस्सा हों, तब यह model अच्छी तरह काम करता है। लेकिन अगर user का decision-maker से सीधा संबंध न हो, या खरीद की वैधता साबित करना कठिन हो—जैसे car keyless entry pop जैसी चीज़—तो कैसे आगे बढ़ें? driver के लिए लाभ बड़ा है, लेकिन Ford के CTO को शायद मीटिंग का प्रस्ताव ही गैरज़रूरी लगे। ऐसी स्थिति में product बनाने के बाद market तक पहुँचना कैसे चाहिए, इस पर सलाह माँगी गई.

  • ऐसे मामलों में bottom-up strategy आकर्षक होती है। Ford HQ की जगह used car dealers, auto repair shops, और accessory sellers को target करके शुरुआत करना असरदार हो सकता है। remote start device का उदाहरण लें: users को इसकी ज़रूरत थी, लेकिन car manufacturers की रुचि कम थी, इसलिए शुरुआती market audio shops के cross-sell से बना, और बाद में manufacturers ने भी इसे option के रूप में अपनाया। मैंने anti-theft device के साथ भी ऐसा ही अनुभव किया है—छोटे स्तर से शुरू करके customer base बनाना और फिर धीरे-धीरे बड़ी कंपनियों तक पहुँचना प्रभावी रहता है.

  • यह दिखाना भी एक तरीका है कि competitors पहले से इस pop को अपना रहे हैं, ताकि FOMO (छूट जाने का डर) पैदा हो.

• Enterprise में सिर्फ CTO को sell करना काफी नहीं होता। अगर कोई कंपनी AWS या Azure की तरह वास्तव में core role निभाती हो, तो CTO और मुख्य engineers को मनाकर पूरे organization में बदलाव लाया जा सकता है। लेकिन ज़्यादातर software में फैसला line manager, director, या department head लेते हैं। यहाँ तक कि अलग-अलग departments अलग software अपनाते हैं, इसलिए target segmentation ज़रूरी है.

• B2B2C marketplaces खास तौर पर दिलचस्प होते हैं। "B2B" users से charge नहीं लेना, बल्कि हर transaction पर fee लेना—ऐसे model में users को distributed salesforce की तरह इस्तेमाल किया जाता है। हर user को अपने instance के जरिए B2C customers लाने में मदद करनी होती है। founders को इससे बहुत कुछ बनाना पड़ता है और कई बार यह अव्यवस्थित लगता है, लेकिन शुरुआती entry barrier कम होने का फायदा यह है कि जब भी कोई account end customer तक value ठीक से पहुँचाता है, revenue स्वाभाविक रूप से काफ़ी बढ़ सकता है.

• हमारी कंपनी भी इस बात से जुड़ाव महसूस करती है। हम entity resolution से जुड़ा business intelligence API बना रहे हैं, और इसमें engineering, product, और data science teams सब शामिल होती हैं, इसलिए buyer और user का अलगाव और जटिल हो जाता है। engineers कंपनी के जटिल data matching की कठिनाई को सहज रूप से समझते हैं, लेकिन executives को बस इतना दिखता है कि project देर से चल रहा है। इसलिए आजकल "आपकी team data matching पर महीनों खर्च कर रही है" जैसी भाषा ज़्यादा प्रभावी लगती है। एक कंपनी ने 10 साल तक इसे in-house बनाने की कोशिश की, फिर भी यह आज तक ठीक से काम नहीं करता। हाँ, यह भी महसूस होता है कि company और situation के हिसाब से approach बदलती है.

  • जानना चाहूँगा कि आप यह technical value users तक कैसे पहुँचा रहे हैं। क्या आप पहले engineers को cold email भेजकर बातचीत शुरू करते हैं और फिर उसे expand करते हैं?

• TikTok की तरह हर transaction के बीच से सिर्फ percentage लेने वाला model भी एक विकल्प हो सकता है.