बिक्री कैटलॉग: AI Workers बेचने की पद्धतियाँ

यह दस्तावेज़ कहाँ फिट होता है

यह दस्तावेज़ The AI-Native Company श्रृंखला के अंदर आता है। The Agent Factory Thesis AI-native कंपनी की architecture को define करती है। AI Worker कैटलॉग यह define करता है कि उस architecture के अंदर क्या बनाया जाता है। बिक्री कैटलॉग यह define करता है कि वे Workers भेजने के लिए तैयार होने के बाद कोई AI-native कंपनी सौदे वास्तव में कैसे बंद करती है।

यह दस्तावेज़ एक सवाल का जवाब देता है: हम सौदा कैसे बंद करें? आप इसे अलग से पढ़ सकते हैं। Worker Catalog के कुछ cross-references छोड़े जा सकते हैं; इससे तर्क समझने में कोई नुकसान नहीं होगा।

इस दस्तावेज़ को कैसे पढ़ें

यह दस्तावेज़ एक औज़ार है, कहानी नहीं। अलग-अलग पाठक इसे अलग-अलग तरह से इस्तेमाल करेंगे।

अगर आप enterprise बिक्री या revenue operations में नए हैं। अंत में परिशिष्ट A: शब्दावली से शुरू करें। इसे एक बार सरसरी तौर पर पढ़ें ताकि शब्दावली परिचित लगे। फिर कार्यकारी सारांश धीरे-धीरे पढ़ें। जब पद्धतियों तक पहुँचें, तो हर पद्धति की शुरुआत में दिए गए सीधी भाषा में paragraph पर ही ध्यान दें। पहली बार पढ़ते समय गहरी कार्य-प्रणाली, उदाहरण और जोखिम वाले खंड छोड़ दें। जब विस्तार चाहिए, तब उन पर लौटें।

अगर आप संस्थापक, बिक्री प्रमुख या revenue leader हैं और अपनी पद्धति design कर रहे हैं। विक्रेता diagnostic और रणनीतिक fit matrix का इस्तेमाल करके देखें कि आपके stage और खरीदार पर कौन सी पद्धतियाँ लागू हो सकती हैं। उन दो या तीन पद्धतियों को पूरा पढ़ें। बाकी को तब तक छोड़ दें जब तक उनकी ज़रूरत न हो।

अगर आप investor या अनुभवी operator हैं। यह दस्तावेज़ आपके लिए बनाया गया है। ऊपर से नीचे तक पढ़ें। पद्धतियाँ खरीदार-नेतृत्व वाली पद्धतियों से शुरू होती हैं, जहाँ ज़्यादातर शुरुआती AI कंपनियाँ शुरू करती हैं, फिर विक्रेता-नेतृत्व वाली और परिणाम-नेतृत्व वाली पद्धतियों से होते हुए साझेदार-नेतृत्व वाली पद्धतियों तक जाती हैं, जहाँ गंभीर revenue scale होता है।

Jargon पर एक ध्यान दें। यह दस्तावेज़ B2B बिक्री, RevOps और AI deployment की business और technical शब्दावली इस्तेमाल करता है। कोई specialized term पहली बार आने पर आम तौर पर पास में या parentheses में सीधी भाषा में समझाया गया है। परिशिष्ट A: शब्दावली किसी भी अटकाने वाले term के लिए संक्षिप्त संदर्भ देता है। दस्तावेज़ समझने के लिए हर term जानना ज़रूरी नहीं है।

शुरुआती पाठक के लिए 10 मिनट वाला संस्करण

अगर आपके पास केवल 10 मिनट हैं, तो यह खंड पढ़ें। यह आपको वह सब देता है जो AI-native कंपनियाँ कैसे बेचती हैं समझने के लिए ज़रूरी है; बाकी दस्तावेज़ की गहराई और detail के बिना।

बिक्री पद्धति क्या है?

बिक्री पद्धति वह खास तरीका है जिससे कोई कंपनी अपना उत्पाद बेचती है। इसमें शामिल है कि बातचीत कौन शुरू करता है, खरीदार या विक्रेता; सौदा बंद होने में कितना समय लगता है; उत्पाद की pricing कैसे होती है; और वास्तव में बिक्री कौन करता है। अलग-अलग उत्पादों को अलग-अलग पद्धतियाँ चाहिए। $20 प्रति महीने वाला productivity app, $1M enterprise contract से बहुत अलग तरीके से बिकता है।

अलग-अलग उत्पादों को अलग-अलग पद्धतियाँ क्यों चाहिए?

चार चीज़ें तय करती हैं कि कौन सी पद्धति फिट बैठती है: खरीदार को मूल्य कितनी जल्दी महसूस होता है, मिनटों में या महीनों में; खरीदार कितना भुगतान कर रहा है, $100 से कम या $1M से ज़्यादा; उत्पाद को evaluate करना कितना complex है; और खरीदार एक व्यक्ति है या पूरा संगठन। Vending-machine product, यानी sign up करें, card swipe करें, मिनटों में मूल्य पाएँ, custom enterprise deployment की तरह नहीं बेचा जा सकता, जिसमें 6 महीने stakeholder navigation, signed contract और staged rollout लगते हैं। पद्धति को उत्पाद और खरीदार, दोनों से मेल खाना चाहिए।

सीधी भाषा में पद्धतियों के चार परिवार

यह दस्तावेज़ 12 पद्धतियों को चार परिवारों में रखता है:

खरीदार-नेतृत्व वाली पद्धतियाँ (1-4)। खरीदार आपको ढूँढता है, आपको evaluate करता है और आपको भुगतान करता है; salesperson सीधे शामिल नहीं होता। उदाहरण: AI app के free trials, app store में listings, open-source projects जिनके ऊपर paid versions हैं।
विक्रेता-नेतृत्व वाली पद्धतियाँ (5-8)। आपका दल संपर्क शुरू करता है, बिक्री प्रक्रिया चलाता है और सौदा बंद करता है। उदाहरण: संस्थापक का शुरुआती ग्राहकों को व्यक्तिगत रूप से बेचना, बड़े scale पर AI-powered cold outbound, बड़े संगठनों में रास्ता बनाते enterprise account executives।
परिणाम-नेतृत्व वाली पद्धतियाँ (9-10)। खरीदार केवल तब भुगतान करता है जब AI वास्तविक परिणाम देता है: resolved support ticket, processed insurance claim। Pricing पहुँच पर नहीं, दिए गए मूल्य पर चलती है।
साझेदार-नेतृत्व वाली पद्धतियाँ (11-12)। तीसरे पक्ष, जैसे consulting firms और cloud providers, अपने ग्राहकों के साथ बड़े engagements के हिस्से के रूप में आपका उत्पाद बेचते हैं।

पद्धति चुनने का सबसे आसान तरीका

दो सवालों से शुरू करें: मेरे उत्पाद की कीमत प्रति ग्राहक प्रति वर्ष कितनी है? और पहले संपर्क से signed contract तक सौदा बंद होने में कितना समय लगता है?

छोटी कीमत और छोटा cycle = खरीदार-नेतृत्व वाली पद्धति, जैसे स्व-सेवा PLG या Marketplace-Led। छोटी या मध्यम कीमत और मध्यम cycle = विक्रेता-नेतृत्व वाली founder या outbound पद्धति। बड़ी कीमत और लंबा cycle = enterprise field, FDE या value-based engagement। लगातार मापे जा सकने वाले परिणाम = pay-per-outcome (पद्धति 9)।

जब संदेह हो, तो नीचे दिए गए रणनीतिक fit matrix और decision flowchart का इस्तेमाल करके candidates को छोटा करें।

12 पद्धतियाँ, हर एक एक वाक्य में

स्व-सेवा PLG। खरीदार sign up करते हैं, card swipe करते हैं और salesperson से बात किए बिना आपका उत्पाद इस्तेमाल करते हैं।
Marketplace-Led। आप किसी host platform के app store (Salesforce, Shopify, ChatGPT) के अंदर बेचते हैं और platform ग्राहक लाता है।
Open-Source-Led। आप अपना core product free देते हैं और उसके ऊपर managed/enterprise version के लिए charge करते हैं।
Community-Led। Launch से पहले आप audience (YouTube, Discord, Substack) बनाते हैं और वही audience आपके पहले ग्राहक बनती है।
Founder-Led Sales। बिक्री दल hire करने से पहले संस्थापक पहले 5-50 सौदे व्यक्तिगत रूप से बंद करता है।
AI-Augmented Outbound। छोटा SDR दल AI agents की मदद से prospects पर research करता है और बड़े scale पर उनसे संपर्क करता है।
Enterprise Field Sales। Account executives quotas लेते हैं और कई महीनों के cycles में six-figure deals बंद करते हैं।
Forward-Deployed Engineering (FDE)। आप engineers को ग्राहक संगठनों के अंदर embed करते हैं ताकि custom solutions बनाए जाएँ, फिर उन्हें productize किया जाए।
Pay-Per-Outcome। ग्राहक resolved ticket, processed claim या किसी और मापे जा सकने वाले परिणाम के हिसाब से भुगतान करते हैं।
Value-Based Engagement। Strategic deals measured business value के percentage के रूप में price किए जाते हैं।
Channel & SI Partnership। Consultancies (Accenture, Deloitte) अपने implementations के हिस्से के रूप में आपका उत्पाद बेचती हैं।
Hyperscaler Co-Sell। Cloud providers (AWS, Azure, Google) आपका उत्पाद बेचने में मदद करते हैं क्योंकि underlying compute revenue उन्हें मिलता है।

हर पद्धति की शुरुआती कठिनाई

हर पद्धति के विस्तृत खंड में difficulty rating है। संक्षिप्त संदर्भ के लिए:

आसान (concept सहज है, सामान्य शुरुआती बिंदु): स्व-सेवा PLG (1), Marketplace-Led (2), Community-Led (4), Founder-Led Sales (5)
मध्यम (कुछ operational समझ चाहिए): Open-Source-Led (3), AI-Augmented Outbound (6), Enterprise Field Sales (7), Channel & SI Partnership (11), Hyperscaler Co-Sell (12)
उन्नत (गहरी domain expertise या substantial capital चाहिए): Forward-Deployed Engineering (8), Pay-Per-Outcome (9), Value-Based Engagement (10)

10 मिनट में पूरा दस्तावेज़ यही है। बाकी हिस्सा हर टुकड़े को विस्तार से समझाता है और आपको अपनी कंपनी में इन पद्धतियों को चुनने, sequence करने और चलाने के औज़ार देता है।

कार्यकारी सारांश

बिक्री कैटलॉग 2026 और उसके बाद AI-native products से सौदे बंद करने की recipe book है। AI Worker बेचने के कई तरीके हैं, और सही तरीका आपके stage, खरीदार, उत्पाद की complexity और आपके distribution की गहराई पर निर्भर करता है। यह दस्तावेज़ 12 पद्धतियों को नाम देता है, उन्हें चार परिवारों में रखता है और बताता है कि आपकी स्थिति में कौन सी फिट बैठती है।

चार परिवार: हर तरह की पद्धति सबसे पहले किस चीज़ पर compete करती है।

खरीदार-नेतृत्व वाली पद्धतियाँ (पद्धतियाँ 1-4) तब काम करती हैं जब खरीदार खुद खोजता है, खुद evaluate करता है और खुद खरीदता है। विक्रेता का काम है खोजे जा सकना, friction हटाना और विश्वसनीय दिखना। विक्रेता sales cycle नहीं चलाता; खरीदार चलाता है।

विक्रेता-नेतृत्व वाली पद्धतियाँ (पद्धतियाँ 5-8) तब काम करती हैं जब विक्रेता सौदे की शुरुआत और orchestration करता है। विक्रेता का काम है precise targeting, value articulation और procurement navigation। विक्रेता sales cycle चलाता है।

परिणाम-नेतृत्व वाली पद्धतियाँ (पद्धतियाँ 9-10) तब काम करती हैं जब सौदा access के बजाय results के around structured होता है। विक्रेता का काम है measurement, attribution और consistent delivery। खरीदार केवल बने हुए मूल्य के लिए भुगतान करता है।

साझेदार-नेतृत्व वाली पद्धतियाँ (पद्धतियाँ 11-12) तब काम करती हैं जब तीसरे पक्ष खरीद को आगे बढ़ाते हैं। विक्रेता का काम है alliance management: partners को इतना सफल बनाना कि वे आपके लिए बेचते रहें।

बिक्री की पाँच संपत्तियाँ: हर पद्धति किसे capture करने की कोशिश कर रही है।

Pipeline sales process में आने वाले qualified opportunities की भरोसेमंद और repeatable supply है। हर सफल पद्धति इसे बनाती है; ज़्यादातर विफल पद्धतियाँ नहीं बनातीं।

गति यह है कि कोई opportunity कितनी जल्दी closed revenue में बदलती है। तेज़ cycles का मतलब है उसी दल से प्रति quarter ज़्यादा सौदे।

सौदा अर्थशास्त्र revenue per deal को gross margin से multiply करके बनता है। $1M deals को 80% margin पर produce करने वाली पद्धति, $10K deals को 30% margin पर produce करने वाली पद्धति से अलग revenue league में है।

Retention net revenue retention है: क्या ग्राहक अपना खर्च बढ़ाता है, स्थिर रखता है या घटाता है? SaaS में 130% से ऊपर NRR category leader को define करता है। AI में गणित बदल रहा है क्योंकि outcome-based revenue usage के साथ naturally बढ़ता है।

भरोसा खरीदार का आपके दल, उत्पाद और operational discipline पर कमाया हुआ confidence है। भरोसा बनने में साल लगते हैं और टूटने में मिनट।

सबसे मज़बूत पद्धतियाँ इन संपत्तियों में से 3 या ज़्यादा को एक साथ capture करती हैं। Agent era में revenue strategy का काम यह चुनना है कि पहले कौन सी संपत्ति capture करनी है, फिर बाकी को sequence करना है।

बिक्री की पाँच संपत्तियाँ

Scope पर एक ध्यान दें। यह catalog मुख्य रूप से B2B markets पर केंद्रित है: AI Workers और AI-native software जो सीधे individual consumers को नहीं, बल्कि अन्य businesses को बेचा जाता है। Consumer-facing AI sales (mobile app store, advertising-led, subscription-led) अलग नियमों पर चलती है और यहाँ मुख्य विषय नहीं है, हालाँकि कई पद्धतियाँ, जैसे स्व-सेवा PLG, Marketplace-Led और Community-Led, दोनों contexts में साफ़ लागू होती हैं।

परिपक्वता spectrum। इस catalog में हर पद्धति को Proven, Emerging या Speculative tag दिया गया है, इस आधार पर कि आज कितनी AI-native कंपनियाँ उसे सफलतापूर्वक चला रही हैं।

Proven पद्धतियाँ अभी कई at-scale कंपनियों द्वारा चल रही हैं, जिनमें confirmed revenue और documented playbook है।
Emerging पद्धतियाँ 2026 में funding प्राप्त कंपनियों द्वारा चलाई जा रही हैं, लेकिन अधिकांश outcomes अभी pending हैं और canonical winner अभी सामने नहीं आया है।
Speculative पद्धतियाँ ऐसे buyer behaviors या contracting structures पर निर्भर करती हैं जो अभी scale पर मौजूद नहीं हैं, लेकिन जल्द बन सकते हैं।

परिपक्वता quality जैसी चीज़ नहीं है। Proven पद्धतियाँ safer हैं; Emerging पद्धतियाँ बड़ा upside देती हैं; Speculative पद्धतियाँ सबसे बड़ा upside उन कुछ दलों को देती हैं जो बाकी market आने से पहले सही position ले लेते हैं।

यह पृष्ठ किसलिए है

यह दस्तावेज़ तीन काम करता है।

पहला, चुनने वाले औज़ार के रूप में। कोई संस्थापक या revenue leader जो sales motion design कर रहा है, Strategic Fit Matrix, Seller Diagnostic और Motion Summary Table का इस्तेमाल करके ऐसी पद्धतियाँ ढूँढ सकता है जो उसके stage, buyer और product complexity से मेल खाती हों। विस्तृत खंड फिर shortlist की पद्धतियों की mechanics, risks और first moves समझाते हैं।

दूसरा, संदर्भ के रूप में। मौजूदा motion चला रहा revenue दल विस्तृत खंडों का इस्तेमाल अपनी operation को documented mechanics के against audit करने के लिए कर सकता है: अपने actual conversion rates, cycle times और deal economics को बताए गए patterns से compare करके।

तीसरा, planning tool के रूप में। कोई संस्थापक जो scale के साथ कंपनी द्वारा चलाए जाने वाले motions का sequence design कर रहा है, क्योंकि ज़्यादातर सफल AI-native कंपनियाँ isolation में एक नहीं, बल्कि sequence में दो या तीन motions चलाती हैं, Common Hybrid Motions खंड को planning template की तरह इस्तेमाल कर सकता है।

पद्धति कैसे चुनें

कौन सी sales motion फिट होगी, इसका सबसे साफ़ predictor deal size और cycle length का intersection है। नीचे की matrix 12 पद्धतियों को इन दो axes पर map करती है। हर पद्धति का एक sweet-spot cell है और वह adjacent cells में भी, कम optimally, काम करती है।

Cycle ↓ \ Deal $ →	स्व-सेवा (<$10K)	मध्य-बाज़ार ($10-100K)	Enterprise ($100K-1M)	Strategic (>$1M)
दिन	PLG (1), Marketplace (2)	—	—	—
हफ्ते	Open-Source (3), Community (4)	Founder-Led (5), AI-Outbound (6)	—	—
महीने	—	Channel (11)	Enterprise Field (7), Channel (11), Hyperscaler (12)	—
Quarter या ज़्यादा	—	—	Pay-Per-Outcome (9), Hyperscaler (12)	FDE (8), Value-Based (10)

रणनीतिक fit matrix

सबसे महत्वपूर्ण cell वह है जिसकी planning कोई पहले से नहीं करता: self-serve से शुरू हुए products के लिए multi-month enterprise cycles। यहीं PLG से बढ़ी कंपनियाँ बड़े enterprise procurement की दीवार से टकराती हैं, और जिन revenue दलों ने केवल self-serve motion चलाया है वे अचानक enterprise field motion चलाने में संघर्ष करती हैं। "buyer-led" से "vendor-led" में transition AI-native कंपनियों में सबसे आम motion failure है, और सबसे ज़्यादा सिखाया जा सकने वाला भी।

विक्रेता diagnostic: 8 सवाल

पद्धति चुनने से पहले नीचे के 8 dimensions पर खुद को ईमानदारी से score करें। हर row जिन motions की ओर इशारा करती है, वे उस condition से सबसे ज़्यादा aligned हैं। जो दल इनमें से 3 या 4 पर High score करता है, वह आम तौर पर जल्दी ही 2 या 3 candidate motions तक पहुँच जाता है।

संस्थापक की बेचने की क्षमता। क्या संस्थापक अभी भी व्यक्तिगत रूप से सौदे बंद कर रहा है? हाँ → Founder-Led, FDE. नहीं, sales दल मौजूद है → Enterprise Field, AI-Outbound, Channel.
उत्पाद complexity। क्या उत्पाद को evaluate करने से पहले buyer education चाहिए? Low → PLG, Marketplace, Open-Source. Moderate → Founder-Led, AI-Outbound. High → Enterprise Field, FDE, Value-Based.
Time-to-value। पहले interaction के बाद खरीदार कितनी जल्दी meaningful value महसूस करता है? Minutes → PLG, Marketplace. Days-weeks → Open-Source, AI-Outbound, Pilot. Months → Enterprise Field, FDE, Value-Based.
Outcome measurability। क्या आपके उत्पाद से खरीदार की सफलता साफ़ मापी जा सकती है? High → Pay-Per-Outcome, Value-Based. Low → PLG, Enterprise Field, Channel (access के रूप में priced).
खरीदार की technical sophistication। Primary buyer कितना technical है? Developer / engineer → Open-Source, PLG, Marketplace. Business / operator → Founder-Led, AI-Outbound, Enterprise Field. Executive / procurement-led → Enterprise Field, FDE, Value-Based, Hyperscaler.
Procurement friction। खरीदार का typical procurement cycle कितना लंबा है? Days-weeks → PLG, Marketplace, Open-Source. Months → Founder-Led, AI-Outbound, Enterprise Field (pilot phase के साथ). Quarters → Enterprise Field, FDE, Channel, Value-Based.
Channel और partner ecosystem। क्या third parties पहले से आपके target buyer को adjacent तरीकों से serve करते हैं? हाँ, deep → Channel, Hyperscaler, SI partnership. हाँ, light → Marketplace, Community. नहीं → Founder-Led, AI-Outbound, Enterprise Field.
Capital और patience। Significant revenue की ज़रूरत पड़ने से पहले आपका दल कितने समय तक operate कर सकता है? 6 महीने से कम → PLG, Marketplace, Open-Source. 6-18 महीने → Founder-Led, AI-Outbound. 18+ महीने → Enterprise Field, FDE, Value-Based.

Diagnostic आपको यह नहीं बताता कि कौन सी पद्धति सही है। यह बताता है कि आपकी शुरुआती position को देखते हुए कौन सी पद्धतियाँ available हैं। ऊपर की matrix और नीचे के विस्तृत खंड बताते हैं कि available motions में से कौन सी उस buyer के लिए सबसे sharp है जिसे आप बेच रहे हैं।

पद्धतियों की summary table

सभी 12 पद्धतियों के लिए एक-पृष्ठ संदर्भ। इसे catalog को एक नज़र में scan करने के लिए इस्तेमाल करें, अंतिम निर्णय के लिए नहीं, क्योंकि असली फर्क नीचे आने वाले विस्तृत खंडों में है।

#	पद्धति	परिपक्वता	सबसे अच्छी किसके लिए	Typical cycle	Typical deal size	मुख्य जोखिम
1	Self-Serve PLG	Proven	Immediate value वाले developer-tool / productivity products	Hours to days	<$10K initial; expands	Conversion-to-paid रुकना
2	Marketplace-Led	Proven	Host platform में fit होने वाले apps	Days	$10-50K	Platform compete या kick-out
3	Open-Source-Led	Proven	Developer infrastructure और frameworks	Weeks to months (open-to-paid)	$50K-500K commercial	Open-to-commercial conversion विफल होना
4	Community-Led	Proven	Strong identity / target persona वाले products	Weeks to months	$10-100K	Scale पर community dilution
5	Founder-Led Sales	Proven	Pre-product-market-fit; पहले 5-50 deals	Weeks	$25-250K	Founder bottleneck; hand off में विफलता
6	AI-Augmented Outbound	Emerging	Mid-market vendor-led GTM	Weeks to months	$25-250K	AI-generated outreach से buyer fatigue
7	Enterprise Field Sales	Proven	बड़े संगठनों को six-figure deals	3-9 months	$100K-1M	लंबा sales cycle; भारी CAC
8	Forward-Deployed Engineering	Proven	Strategic enterprise deals जहाँ custom काम चाहिए	6-12 months for first deal	$500K-5M	Service-business gravity
9	Pay-Per-Outcome	Emerging	Workflows जहाँ outcomes साफ़ attribute हो सकते हैं	2-6 months	Variable; usage-based	शुरुआती वर्षों में negative margin
10	Value-Based Engagement	Speculative	Strategic transformation deals	6-18 months	$1M-10M+	Attribution disputes
11	Channel & SI Partnership	Proven	Products जिन्हें implementation expertise चाहिए	3-9 months (through partner)	$100K-1M	Partner economics misalignment
12	Hyperscaler Co-Sell	Proven	Large compute footprint वाले cloud-native products	2-6 months	$100K-1M+	Hyperscaler de-prioritization

मुझे कौन सी पद्धति अपनानी चाहिए?

नीचे का flowchart सबसे महत्वपूर्ण decisions को sequence करता है। सवालों का जवाब ऊपर से नीचे तक दें और पहले YES पर रुकें: वही आपकी branch है। Leaf nodes पूरी पढ़ने के लिए 1 से 4 candidate motions देते हैं।

Decision flowchart

Flowchart opinionated है। यह वास्तविक दुनिया की nuance को clean YES/NO splits में compress करता है ताकि आपके विकल्प 12 से घटकर 2 या 3 रह जाएँ। Candidate set छोटा हो जाने के बाद choice refine करने के लिए ऊपर वाला Seller Diagnostic और Strategic Fit Matrix इस्तेमाल करें। ज़्यादातर कंपनियाँ अंत में एक के बजाय 2 या 3 motions simultaneously चलाएँगी; सबसे common combinations के लिए दस्तावेज़ के अंत के पास Common Hybrid Motions देखें।

Buyer maturity और timing

इस catalog की हर पद्धति के लिए buyer की अपनी AI journey में एक window होती है। जिसने कभी production में AI deploy नहीं किया, वह उस buyer से अलग खरीदता है जो production AI को scale पर चलाता है। AI-native buyer के लिए शानदार काम करने वाली पद्धतियाँ AI-curious buyer को alien लगती हैं, और इसका उल्टा भी सच है।

Buyer maturity curve को 3 stages define करते हैं।

Stage 1: AI-Curious। खरीदार AI में interested है लेकिन उसने इसे production में deploy नहीं किया है। Procurement AI को exotic मानता है; legal को AI-specific language scratch से draft करनी पड़ती है; security के पास AI vendor template नहीं होता। खरीदार pilots, references और ऐसे sponsor चाहता है जो internally vouch कर सके। Sales cycles slow होते हैं क्योंकि हर objection पहली बार उठ रहा होता है। Best motions: Founder-Led, FDE, Enterprise Field with a paid pilot phase.

Stage 2: AI-Piloting। खरीदार ने experiments चलाए हैं। एक internal AI champion होता है, अक्सर VP of Engineering, Chief Data Officer या AI-curious COO, जिसने कम से कम एक model production में भेजा है। Procurement के पास basic AI vendor template होता है। Sales cycles तेज़ होते हैं (3-6 months), क्योंकि खरीदार जानता है कि क्या पूछना है। Best motions: Enterprise Field, AI-Augmented Outbound, Channel.

Stage 3: AI-Native। खरीदार AI को core infrastructure मानता है। AI-native दल, AI procurement playbook और outcome-based pricing विकल्पों की expectation होती है। Clear-fit products के लिए sales cycles तेज़ हो सकते हैं (weeks), लेकिन procurement scrutiny intense होती है: security review rigorous होता है, competitive benchmarking thorough होता है और खरीदार सिर्फ price नहीं, outcomes पर negotiate करेगा। Best motions: Pay-Per-Outcome, Value-Based, Hyperscaler Co-Sell, PLG (departmental adoption के लिए).

Geography curve को तेज़ या धीमा करती है। Silicon Valley, Seattle, Boston, New York, London, Toronto, Berlin, Bangalore और Singapore 2026 में ज़्यादातर Stage 2 या Stage 3 markets हैं: उन ecosystems के buyers AI experiments चला चुके हैं, internal AI procurement templates लिख चुके हैं और outcome-based pricing विकल्प माँगना शुरू कर रहे हैं। दुनिया का ज़्यादातर बाकी हिस्सा 2 से 3 साल पीछे है: continental Europe, Latin America, Middle East, Africa और Southeast Asia के बड़े हिस्सों में enterprise buyers अभी Stage 1 में मज़बूती से हैं, Stage 2 की ओर बढ़ रहे हैं।

Globally बेचने वाले founders के लिए implication यह है कि वही उत्पाद अलग markets में अलग पद्धतियाँ माँगता है। Self-serve PLG product San Francisco और São Paulo में एक ही तरह बेचा जा सकता है: खरीदार ही user है और user की sophistication geography पर निर्भर नहीं करती। लेकिन San Francisco के AI-native buyers के लिए calibrated enterprise field motion Karachi, Lagos या Jakarta में विफल होगा: इसलिए नहीं कि local buyer कम sophisticated है, बल्कि इसलिए कि उनकी AI procurement कम mature है। विक्रेता को पद्धति धीमी करनी होगी: ज़्यादा education, ज़्यादा references, लंबे pilots, procurement में ज़्यादा हाथ पकड़कर चलना।

उल्टा mismatch भी उतना ही महँगा है। Stage 1 buyers के लिए calibrated motion, heavy hand-holding, long pilots, founder-on-every-call, Stage 3 markets में बेवजह महँगा है और weakness signal करता है। Stage 3 buyer outcome-based pricing और 4-week procurement cycle चाहता है। उसे Stage 1 motion बेचना यह communicate करता है कि विक्रेता unsophisticated, slow और शायद integration effort के लायक नहीं है। Globally बेचने वाले founder को यह जानना होगा कि buyer आज किस stage में है, न कि reference customers किस stage में हैं। Stage 3 buyers के लिए calibrated motion Stage 1 buyers के साथ विफल होगा, और इसका उल्टा भी।

Buyer maturity curve

परिपक्वता legend

Proven। पद्धति को आज कई AI-native कंपनियाँ scale पर चला रही हैं, confirmed revenue और documented playbook के साथ। Mechanics अच्छी तरह समझी जा चुकी हैं।
Emerging। पद्धति 2026 में funded AI-native कंपनियों द्वारा चलाई जा रही है, लेकिन अधिकांश outcomes अभी pending हैं और canonical winner अभी नहीं निकला है।
Speculative। पद्धति buyer behaviors या contracting structures पर निर्भर करती है जो अभी scale पर मौजूद नहीं हैं, लेकिन बनने की संभावना है।

A. खरीदार-नेतृत्व वाली पद्धतियाँ

खरीदार खुद खोजता है, खुद evaluate करता है और खुद खरीदता है। विक्रेता का काम है खोजे जा सकना, friction हटाना और credible होना। विक्रेता sales cycle नहीं चलाता; खरीदार चलाता है। ये पद्धतियाँ गति और CAC efficiency में उत्कृष्ट हैं, लेकिन आम तौर पर vendor-led motions की तुलना में छोटे initial deal sizes देती हैं।

पद्धति 1: Self-Serve PLG (Product-Led Growth)

परिपक्वता: Proven. शुरुआती कठिनाई: आसान.

सीधी भाषा में। Software के लिए vending machine की कल्पना करें। खरीदार आता है, credit card swipe करता है और उत्पाद सामने आ जाता है। कोई salesperson नहीं, contract negotiation नहीं, $20/month subscription के लिए procurement review नहीं। Self-Serve PLG ठीक यही है: उत्पाद खुद बिक्री करता है। खरीदार sign up करता है, मिनटों में मूल्य अनुभव करता है और जब usage paid tier को justify करता है, तो खुद upgrade करता है।¹

यह केवल तब काम करता है जब उत्पाद किसी एक user को organizational coordination के बिना immediate, obvious value देता है। Cursor (AI code editor) साफ़ उदाहरण है: engineer sign up करता है, AI assistance के साथ code लिखता है, पहली session में value देखता है और free-tier limits hit होने पर upgrade करता है। Linear (project management), Notion AI (writing assistance) और ElevenLabs (voice generation) इस motion के variants चलाते हैं।

Immediate single-user value वाले products के लिए founding motion के रूप में best. कंपनी scale होने पर अक्सर Enterprise Field के साथ pair होता है; PLG → Enterprise hybrid 2026 की सबसे common motion sequences में से एक है.

मुख्य विचार। Curiosity और value के बीच friction हटाएँ। Sign-up flow का हर step जो value produce नहीं करता, हटाया जाना चाहिए। उत्पाद खुद sales pitch, demo और close है।

कब अपनाएँ। जब target buyer ही user हो, अलग procurement role न हो; जब value immediate हो, minutes में, weeks में नहीं; और जब price point corporate-card thresholds से नीचे हो, आम तौर पर <$200/seat/month, हालाँकि AI products clear ROI दिखाते हैं तो यह बढ़ रहा है।

कैसे काम करती है। PLG इसलिए काम करता है क्योंकि यह traditional B2B sales funnel को उलट देता है। Sales-qualified leads को salesperson की ओर push करने और फिर product की ओर push करने के बजाय, product qualified buyers पैदा करता है जो खुद paid conversion तक आते हैं। CAC dominated होता है product investment से: onboarding, activation, in-product upgrade prompts; headcount से नहीं। Margins high हैं क्योंकि pay करने के लिए बिक्री दल नहीं है। Constraint conversion-to-paid है: ज़्यादातर PLG products free users में से 2-5% को paid में convert करते हैं।

काल्पनिक उदाहरण। FocusFlow की कल्पना करें, $20-per-month AI app जो किसी को भी अपना email organize करने में मदद करता है। User lunch पर sign up करता है, inbox connect करता है और 5 मिनट में productively इस्तेमाल कर रहा होता है। पहले सप्ताह में वह 100 AI summaries per day की free-tier ceiling hit करता है और paid में upgrade करता है; कोई salesperson शामिल नहीं। FocusFlow का revenue इसलिए बढ़ता है क्योंकि product खुद free users को paying customers में convert करता है, इसलिए नहीं कि किसी ने उन्हें call किया।

उदाहरण। Confirmed examples: Cursor का free-tier code editor से paid subscriptions और फिर enterprise contracts तक पहुँचना। Linear, Notion AI, Perplexity Pro. Voice generation के लिए ElevenLabs.

मुख्य जोखिम। Conversion-to-paid रुक जाता है। Product adoption पाता है, लेकिन users upgrade नहीं करते। बचाव: upgrade trigger को सीधे product में design करें। Free tier की usage ceiling इतनी tight होनी चाहिए कि genuine power users इसे पहले सप्ताह में hit करें, एक साल में नहीं।

दूसरा जोखिम। Self-serve plateau। Motion departmental adoption के लिए काम करता है, लेकिन कंपनी का enterprise expansion, security review, multi-seat negotiation, custom contracts, ऐसा sales motion माँगता है जो दल ने बनाया नहीं है। बचाव: enterprise-scale prospects आने के बाद नहीं, product-led growth के उन्हें पैदा करने से पहले पहला enterprise seller hire करें। "buyer-led" से "vendor-led" transition deliberate motion design माँगता है।

पहला कदम। ऐसा free tier बनाएँ जो sign-up के 5 मिनट के भीतर genuine value का moment पैदा करे। उस moment के बिना कोई और PLG mechanic मायने नहीं रखता।

पद्धति 2: Marketplace-Led

परिपक्वता: Proven. शुरुआती कठिनाई: आसान.

सीधी भाषा में। व्यस्त बाज़ार में stall rent करने की कल्पना करें। Crowd लाने की ज़रूरत नहीं; बाज़ार पहले से लाता है। आपका काम बाज़ार का सबसे अच्छा stall बनना है। Marketplace-Led बिक्री का मतलब है अपने AI product को स्थापित platform के app store में list करना: Salesforce AppExchange, Shopify App Store, Microsoft AppSource, ChatGPT Apps directory, Atlassian Marketplace। Marketplace discovery, billing और initial trust signal संभालता है। आप product संभालते हैं।

AI products के लिए यह motion uniquely powerful है क्योंकि buyer अक्सर उसी platform के अंदर होता है जब उसे AI feature की ज़रूरत महसूस होती है। जिसे AI lead-scoring tool चाहिए, वह Salesforce admin Google पर search करने से पहले AppExchange search करेगा।

Founding distribution motion के रूप में या established products के लिए complementary channel के रूप में best. Scale पर शायद ही कभी यह कंपनी की only motion रहती है.

मुख्य विचार। Platform के distribution, billing और trust apparatus को inherit करें। Direct customer acquisition costs के बजाय revenue share या listing fees से इसका भुगतान करें।

कब अपनाएँ। जब आपका AI product किसी platform के existing user base के अंदर cleanly fit होता हो, platform के customers आपके target customer से map होते हों, और platform का revenue share direct customer acquisition पर आपके खर्च से कम हो।

कैसे काम करती है। Marketplace founder की 3 समस्याएँ एक साथ solve करता है: discovery, buyer platform में shopping करते हुए आपको ढूँढता है; billing, platform credit cards, invoicing और tax संभालता है; trust, platform का vetting process खुद trust signal है। Trade-off है platform का revenue share, आम तौर पर 15-30%, और platform policy risk: वे terms बदल सकते हैं या competing first-party feature बना सकते हैं।

काल्पनिक उदाहरण। NoteSnap की कल्पना करें, Salesforce के लिए AI summarization app। NoteSnap Salesforce AppExchange में list होता है। Productivity tools ढूँढ रहा Salesforce admin NoteSnap पाता है, install करता है, free trial में value देखता है और paid में convert होता है; सब Salesforce की billing system से। NoteSnap ने outbound campaign नहीं चलाया; platform ने customer acquisition किया।

उदाहरण। Confirmed examples: सफल Salesforce AppExchange और Shopify App Store कंपनियों की लंबी tail। 2026 में Claude Apps और ChatGPT Apps के through ship होते productivity agents। Meta और TikTok ad platforms में embedded AI-native ad-creative tools.

मुख्य जोखिम। Platform risk asymmetric और existential है। Policy change, take-rate increase या first-party feature launch marketplace-led business को रातोंरात मिटा सकता है। बचाव: platform के बाहर direct relationship layer रखें: अपनी email list, community या data export pathway, ताकि platform termination fatal नहीं बल्कि recoverable हो। Plan इस assumption से करें कि platform अंततः आपसे compete करेगा।

पहला कदम। एक platform चुनें और दूसरे पर list करने से पहले उसमें first-class citizen बनें: top-rated, deeply integrated, frequently updated।

पद्धति 3: Open-Source-Led

परिपक्वता: Proven. शुरुआती कठिनाई: मध्यम.

सीधी भाषा में। Recipe free दें; catering के लिए charge करें। Open-Source-Led बिक्री का मतलब है अपने product का core open-source code के रूप में publish करना, जिसे कोई भी developer पढ़, modify और run कर सके। जैसे-जैसे ज़्यादा developers इसे इस्तेमाल करते हैं, आपकी reputation बढ़ती है, contributors project से जुड़ते हैं और code बेहतर होता है; वह भी marketing दल पर खर्च किए बिना। फिर आप ऊपर ऐसी paid version बेचते हैं जिसमें कंपनियों को सच में चाहिए वाली चीज़ें हों: managed hosting, security features, audit logs, support contracts, regulated-environment certifications।

यह motion AI infrastructure के लिए खास तौर पर powerful है: agent frameworks, evaluation tools और developer libraries जहाँ developer mindshare primary moat है।

Infrastructure-shaped products के लिए founding motion के रूप में best. Commercial offering mature होने पर अक्सर Channel या Hyperscaler Co-Sell के साथ pair होता है.

मुख्य विचार। Open-source project को globally distributed marketing function की तरह इस्तेमाल करें। Community project को evangelize करती है; users का एक fraction paying customers बनता है जब उन्हें operational, security या scale needs मिलती हैं जिन्हें open project handle नहीं करता।

कब अपनाएँ। जब target buyer technical हो, developers, ML engineers, infrastructure दल; जब कोई credible reason हो कि कंपनी open version खुद चलाने के बजाय managed version के लिए pay करेगी, जैसे hosting, compliance, support; और जब दल community बनाने के लिए multi-year arc में open-source development sustain कर सके।

कैसे काम करती है। Open-source-led इसलिए काम करती है क्योंकि developer adoption enterprise adoption से आगे चलता है: engineers अपने machines पर open project के साथ experiment करते हैं, फिर अपनी कंपनी को related need होने पर internally advocate करते हैं। Pre-sales relationship salesperson hire होने से पहले बन जाती है। Constraint open-to-commercial conversion है: कई open-source projects इसलिए विफल नहीं होते कि technology खराब है, बल्कि इसलिए कि founders ने free product के ऊपर clear paid product बनाया ही नहीं।

काल्पनिक उदाहरण। AgentCore की कल्पना करें, open-source framework जो developers को AI agents बनाने देता है। हज़ारों developers AgentCore free download करते हैं, project में contribute करते हैं और उससे apps बनाते हैं। AgentCore की commercial offering, AgentCore Cloud, enterprises से managed hosting, single sign-on, audit logs और compliance certifications के लिए charge करती है। Free project adoption चलाता है; paid version enterprise features की ज़रूरत वाले customers capture करता है।

उदाहरण। Confirmed examples: LangChain, Continue, n8n, Cline और agent frameworks की लंबी tail जो widely-adopted open cores के ऊपर commercial managed versions ship कर रही है। यह pattern current agent ecosystem के सबसे prominent patterns में है।

मुख्य जोखिम। Open-to-commercial conversion विफल होता है। Open project बहुत popular है, लेकिन commercial revenue weak है। बचाव: पहले से तय करें कि आप क्या कभी free नहीं देंगे: आम तौर पर managed hosting, single-sign-on, audit logs, advanced security और enterprise support। इस line को publicly commit करें। Line बदलती है तो volunteers और contributors का भरोसा टूटता है।

दूसरा जोखिम। Hyperscaler appropriation। AWS, Azure या GCP आपके open project को अपने managed service में wrap करके आपसे बेहतर distribute करता है। बचाव: hyperscaler partner programs के साथ early सीधे काम करें, या ऐसा license (BSL, SSPL) इस्तेमाल करें जो explicit license के बिना cloud-provider commercial इस्तेमाल limit करे।

पहला कदम। Commercial offering की बात करने से पहले open project को genuinely useful state तक ship करें। Communities bait-and-switch को दूर से पहचान लेती हैं।

पद्धति 4: Community-Led

परिपक्वता: Proven. शुरुआती कठिनाई: आसान.

सीधी भाषा में। कुछ बेचने से पहले famous होने की कल्पना करें। Community-Led का मतलब है paid product ship करने से बहुत पहले audience बनाना: Discord server, YouTube channel, Substack, tutorial library, और ऐसा public X account जहाँ निर्माण openly share होता हो। जब आप ship करते हैं, audience पहले से मौजूद होती है। वे आपके product का इंतज़ार कर रहे होते हैं। वे खरीदेंगे, evangelize करेंगे और early-version flaws माफ़ करेंगे क्योंकि उन्हें आपकी सफलता में personal investment महसूस होता है।

यह motion technical audiences के लिए Open-Source-Led से और कुछ AI tools के लिए Marketplace-Led से overlap करता है, लेकिन इसका distinctive feature है founder या दल की public identity का entry point होना।

Strong creative identity वाले products के लिए founding motion के रूप में best. Founder की personal reach से आगे scale करना कठिन है, जब तक community को deliberate तरीके से structured brand asset में convert न किया जाए.

मुख्य विचार। पहले audience बनाएँ, product बाद में। Distribution को quarterly expense के बजाय long-term moat मानें।

कब अपनाएँ। जब founder या दल target buyer के ecosystem में credible content produce कर सकता हो, जैसे dev tools के लिए developer-influencer, creator tools के लिए creator-influencer, vertical SaaS के लिए operator-influencer; जब embed करने के लिए established marketplace या platform न हो; और जब दल serious revenue से पहले 12+ महीने audience बनाने में धैर्य से invest कर सके।

कैसे काम करती है। Community-led इसलिए काम करती है क्योंकि audience खुद pre-qualify करती है। जो लोग developer-influencer को 2 साल follow करते हैं और फिर उसका product खरीदते हैं, वे paid acquisition से आए cold lead की तुलना में 10-20× ज़्यादा convert होने की संभावना रखते हैं। Trust, सबसे महँगी sales asset, product launch से पहले बन जाती है।

काल्पनिक उदाहरण। VideoMaker की कल्पना करें, AI video editing tool। इसकी founder ने product launch से पहले 2 साल YouTube और TikTok पर tutorials post किए और 50,000 followers की audience बनाई। Launch day तक audience इंतज़ार कर रही थी। पहले 1000 paid customers सीधे उसके existing followers से आए; launch-week revenue ने उतना exceed किया जितना ज़्यादातर pre-launch products पहले साल में कमाते हैं।

उदाहरण। Confirmed examples: Tiago Forte की Building a Second Brain franchise (productivity), Lenny Rachitsky की product-management substack-to-software trajectory और AI-creator personalities जो अपनी audiences को tools launch करते हैं। Pattern कंपनियों से ज़्यादा individuals से shaped है।

मुख्य जोखिम। Scale होने पर community dilution। Early audience intimacy और direct founder access को value देती है; कंपनी scale होने पर वह intimacy impossible हो जाती है। बचाव: हमेशा personal founder presence पर निर्भर रहने के बजाय community को brand asset में बदलें: named programs, public events, tier rewards।

पहला कदम। बेचने के लिए product होने से पहले content produce करना शुरू करें। बिना commercial pitch के 12 महीने consistent content minimum entry price है।

B. विक्रेता-नेतृत्व वाली पद्धतियाँ

विक्रेता deal शुरू करता है और orchestrate करता है। विक्रेता का काम precise targeting, value articulation और procurement navigation है। ये पद्धतियाँ deal size और predictability में उत्कृष्ट हैं, लेकिन खरीदार-नेतृत्व वाली पद्धतियों की तुलना में बड़े दल और ज़्यादा patience माँगती हैं।

पद्धति 5: Founder-Led Sales

परिपक्वता: Proven. शुरुआती कठिनाई: आसान.

सीधी भाषा में। शुरुआती restaurant में वही chef जो खाना पकाता है, guests को seat भी देता है, orders भी लेता है और bill भी बनाता है। Founder-Led Sales ठीक ऐसा ही है: बिक्री दल hire करने से पहले founder पहले 5-50 deals व्यक्तिगत रूप से बंद करता है। Buyer वास्तव में किसे value देता है, कौन से objections सच में आते हैं और असली sales playbook कैसा दिखता है, यह सीखने का कोई दूसरा तरीका नहीं है। जो founder यह step skip करके बहुत जल्दी VP of Sales hire करता है, वह unvalidated sales motion और ऐसा दल बनाता है जो उसे improvise नहीं कर सकता।²

किसी भी complex B2B AI product के लिए founding sales motion के रूप में best. 6-18 months के भीतर AI-Augmented Outbound, Enterprise Field या किसी और vendor-led motion में transition plan करें; founder bandwidth binding constraint है.

मुख्य विचार। Founder ही दल का वह व्यक्ति है जिसके पास product context और strategic discretion, दोनों हैं, जिससे non-standard deals बंद हो सकते हैं। पहले phase में founder का इस्तेमाल करें, फिर founder ने जो सीखा उसे repeatable playbook में बदलें, sellers hire करने से पहले।

कब अपनाएँ। B2B AI-native कंपनियों के लिए pre-Series A या sales motion की earlier evolution में, हमेशा। यहाँ तक कि मुख्य रूप से PLG motion चलाने वाली कंपनियाँ भी early enterprise deals के लिए founder-led sales से लाभ उठाती हैं।

कैसे काम करती है। Founder-Led इसलिए काम करता है क्योंकि हर early deal partly custom होता है: buyer नई कंपनी पर risk ले रहा है और founder ही authoritative तरीके से कह सकता है "हाँ, हम यह कर सकते हैं" और उसे सच बना सकता है। Constraint founder bandwidth है: founder आम तौर पर product बनाने, capital raise करने और recruiting के साथ-साथ प्रति quarter 3-5 deals बंद कर सकता है। उससे आगे motion founder पर bottleneck हो जाता है।

काल्पनिक उदाहरण। LegalDraft की कल्पना करें, AI legal-research tool। Founder, जो पहले corporate attorney थी, अपनी पुरानी law firm के 30 friends को व्यक्तिगत रूप से call करती है। वह product demo करती है, हर call पर pricing negotiate करती है और पहले 15 customers खुद sign करती है, salespeople hire करने से पहले। इन 15 conversations में वह यह भी discover करती है कि जिस feature को वह killer use case मान रही थी वह मुश्किल से valuable है, और जिस boring feature को वह लगभग काटने वाली थी वही customers सच में pay करते हैं।

उदाहरण। Confirmed pattern: 2025-2026 में ज़्यादातर सफल B2B AI-native startups ने, चाहे वे बाद में जिस भी motion पर scale हुए हों, अपने पहले 5-50 customers के लिए founder-led sales चलाया। Harvey, Sierra, Glean और Hebbia इस pattern में fit होते हैं।

मुख्य जोखिम। Founder bottleneck। Founder इतने sales meetings में होता है कि product बनाना या कंपनी चलाना प्रभावित होता है। बचाव: motion को explicitly sunset करें। पहले 30-50 deals के बाद founder को sales playbook लिखना चाहिए, अगले 50 deals चलाने नहीं।

दूसरा जोखिम। Hand off में विफलता। पहला sales hire founder का काम replicate नहीं कर पाता क्योंकि founder की बिक्री unwritten product commitments, pricing improvisation और personal relationships पर बनी थी। बचाव: हर commitment, हर pricing exception और हर deal structure को होते समय document करें। Handoff document founder-led sales के दौरान बनता है, बाद में नहीं।

पहला कदम। Founder को अगला deal व्यक्तिगत रूप से बंद करना चाहिए। उसके बाद जो भी बनेगा, वह उस एक deal से सीखी गई बातों पर बनेगा।

पद्धति 6: AI-Augmented Outbound

परिपक्वता: Emerging. शुरुआती कठिनाई: मध्यम.

सीधी भाषा में। 50 लोगों के sales development दल को 5 लोगों के दल में squeeze करने की कल्पना करें। AI-Augmented Outbound, AI agents का इस्तेमाल करके research, drafting और follow-up का वह काम करता है जिसके लिए पहले sales development representatives की बड़ी armies चाहिए थीं; छोटा human दल live conversations और demos संभालता है जो AI अभी अच्छी तरह नहीं कर पाता। Traditional SDR दिन में 30 personalized emails भेजता था। AI-augmented SDR 3000 भेजता है।³

यह वही sales motion है जिसे AI ने खुद संभव बनाया है। 2 साल पहले underlying technology insufficient थी। आज well-tuned AI-augmented outbound best human SDR दलों की personalization quality match या exceed कर सकता है: headcount के fraction पर, और human SDR उन conversations में loop में रहता है जो matter करती हैं।

Mid-market vendor-led GTM के लिए primary motion के रूप में best. किसी भी vendor-led motion के ऊपर augmentation layer के रूप में भी काम करता है। Mechanics underlying AI tooling के साथ तेज़ी से evolve हो रहे हैं.

मुख्य विचार। Upper-funnel research, drafting और follow-up के लिए AI agents इस्तेमाल करें। Bottom-funnel, यानी live conversations, demo coordination और deal navigation, के लिए छोटा human दल रखें जहाँ AI अभी human judgment replace नहीं कर सकता।

कब अपनाएँ। जब target buyer email या LinkedIn से reachable हो, जो mid-market tech buyers के लिए typical है और executive-level enterprise buyers के लिए कम reliable; जब product 30-minute call में demonstrate किया जा सकता हो; और जब दल के पास RevOps maturity हो ताकि AI के prompts और behavior instrument और tune किए जा सकें।

कैसे काम करती है। AI-augmented outbound इसलिए काम करता है क्योंकि traditional outbound में limiting factor हमेशा scale पर personalization quality था। Humans दिन में 30 personalized emails लिख सकते थे; AI 3000 लिख सकता है। Constraint outreach volume से shift होकर deliverability, response quality और increased response rate संभालने की human SDR capacity पर आ जाता है। जो शुरुआती दल यह motion अच्छी तरह चला रहे हैं वे pure human outbound की तुलना में meaningful pipeline efficiency improvements report करते हैं; typical claims 2-4× range में आते हैं, हालाँकि independent benchmarks scarce हैं और comparison इस पर heavily निर्भर करता है कि "pipeline" से क्या मापा जा रहा है।

काल्पनिक उदाहरण। SalesScope की कल्पना करें, B2B AI tool। इसका 5-person SDR दल AI agent का इस्तेमाल करके प्रति सप्ताह 10,000 prospects पर research करता है, हर एक के लिए personalized outreach draft करता है और automatically follow up करता है। Human SDRs केवल resulting live conversations संभालते हैं। दल monthly उतनी meetings book करता है जितनी manual outreach वाला comparable 50-person SDR दल करेगा, और headcount cost का दसवाँ हिस्सा खर्च करता है।

उदाहरण। Emerging analogues: Apollo, Clay, Salesloft AI, Outreach AI और 2025-2026 में ship हो रही AI-native sales engagement platforms की wave। कई AI-native vendors यह motion अपने primary outbound engine के रूप में चलाते हैं।

मुख्य जोखिम। AI-generated outreach से buyer fatigue। जैसे-जैसे AI-augmented outbound फैलता है, buyers इसे पहचानना और ignore करना सीखते हैं। बचाव: AI को research और drafting के लिए इस्तेमाल करें, लेकिन actual sending और follow-up में human SDRs को conversation में रखें। "AI-generated, AI-detected, ignored" path वास्तविक और बढ़ता हुआ है।

दूसरा जोखिम। Compliance और deliverability। Scale पर AI-augmented outbound ESP (email service provider) penalties trigger कर सकता है या jurisdictional rules violate कर सकता है। बचाव: deliverability infrastructure में invest करें और regional regulations rigorously follow करें।

पहला कदम। अपने current SDR दल का actual time allocation audit करें। अगर वे अपना 40% से ज़्यादा समय research और drafting में लगाते हैं, तो AI-augmented outbound का clear leverage opportunity है। अगर उनका ज़्यादातर समय live calls और meeting coordination में जाता है, leverage छोटा है।

पद्धति 7: Enterprise Field Sales

परिपक्वता: Proven. शुरुआती कठिनाई: मध्यम.

सीधी भाषा में। Dealership में cars बेचने जैसा, बस dealership ग्राहक के office में है और car की कीमत $1M है। Enterprise Field Sales traditional B2B sales motion है: account executives $1-5M annual quotas लेकर 3-9 month cycles में multi-stakeholder deals चलाते हैं, जहाँ executive champions, technical evaluators, security reviewers, legal और procurement सभी को navigate करना पड़ता है।⁴

यह motion old-school enterprise software (Oracle, SAP, Salesforce) से सबसे ज़्यादा associated है। यह वह only motion भी है जो reliably multi-hundred-thousand-dollar AI deals को scale पर produce करता है।

Six-figure deals target करने वाले products के लिए primary motion के रूप में best. अक्सर वह destination motion है जिसमें PLG, Founder-Led और AI-Augmented Outbound कंपनियाँ scale होते हुए graduate करती हैं.

मुख्य विचार। Buyer की procurement complexity को sales दल की specialization से match करें। जहाँ buyer के पास spend approve करने वाला CFO, architecture approve करने वाला CIO, vendor approve करने वाला security दल और contract approve करने वाला legal दल है, वहाँ seller को equivalent specialists चाहिए।

कब अपनाएँ। जब deal sizes annual $100K से ऊपर हों, buyer formal procurement वाला बड़ा संगठन हो, product को evaluate करने के लिए 30-minute conversation से ज़्यादा चाहिए और दल के पास long sales cycle support करने के लिए 18+ months capital हो।

कैसे काम करती है। Enterprise field sales इसलिए काम करती है क्योंकि बड़े संगठन ऐसी processes से खरीदते हैं जो bad-vendor risk minimize करने के लिए design होती हैं। Seller का काम उस process को navigate करना है: internally champions बनाना, security documentation देना, contracts negotiate करना; उन महीनों में जब संगठन purchase को formally approve करता है। लगभग हर enterprise AI deal paid pilot के रूप में structured होता है, जिसके बाद production contract आता है; pilot अलग motion नहीं, बल्कि इस motion का standard entry phase है (Pilot economics in Cross-cutting concepts देखें)।

Constraint sales दल का CAC है। Fully-loaded enterprise account executive, salary, commission, benefits, sales-engineering allocation, tooling सहित, आम तौर पर annually mid-six-figures में cost करता है और full quota तक ramp होने में 6-9 months लेता है। जब तक ramp complete नहीं होता, हर AE revenue offset किए बिना cost है। जो कंपनियाँ playbook validate होने से पहले बहुत सारे AEs बहुत तेज़ hire करती हैं, वे deals close होने की तुलना में capital ज़्यादा तेज़ burn करती हैं।

काल्पनिक उदाहरण। HRSmart की कल्पना करें, Fortune 500 HR दलों के लिए AI tool। एक deal close होने में 6 months लगते हैं। Account executive पहले VP of HR से मिलता है, फिर CIO से, फिर security review (3 weeks), फिर legal (6 weeks), फिर procurement (4 weeks)। Deal $400,000 ACV पर close होता है। AE fully loaded $400,000 per year cost करता है और full quota तक ramp होने में 9 months लेता है। गणित केवल इसलिए काम करता है क्योंकि हर AE इस scale पर साल में 3 से 5 deals close करता है।

उदाहरण। Confirmed examples: Glean, Harvey, Sierra, Writer और Cresta में ज़्यादातर six-figure-and-above AI-native deals enterprise field motions से चलते हैं। इन कंपनियों ने specialized roles (AEs, SEs, customer success, sales engineering) के साथ formal sales organization बनाए हैं।

मुख्य जोखिम। Long sales cycles capital burn करते हैं। Fully-loaded mid-six-figure AE cost पर 6-9 month cycle का मतलब है कि हर AE deal close होने से पहले meaningful capital consume करता है। बचाव: 1000s mid-market कंपनियों पर outbound फैलाने के बजाय high-value target accounts की छोटी संख्या पर concentrate करें (account-based selling)।

दूसरा जोखिम। Heavy CAC ratios। Enterprise field motions 18+ months के CAC payback periods produce कर सकते हैं, जो venture-backed कंपनियों के लिए unsustainable हैं जिन्हें efficiency demonstrate करनी होती है। बचाव: enterprise field को PLG या pilot motion के साथ combine करें जो lower-cost initial entry produce करे, फिर account के अंदर expand करें।

पहला कदम। एक enterprise seller hire करें और दूसरे को hire करने से पहले 6 months तक उसे playbook चलाने दें। दूसरे hire की success पहले hire ने जो सीखा उस पर बनती है, parallel learning पर नहीं।

पद्धति 8: Forward-Deployed Engineering (FDE)

परिपक्वता: Proven. शुरुआती कठिनाई: उन्नत.

सीधी भाषा में। Menus नहीं, embedded chefs। अपने engineers को customer की kitchen में रहने भेजें और custom meals पकाएँ। समय के साथ recipes ऐसा menu बन जाती हैं जिसे आप दूसरे customers को बेच सकते हैं। Forward-Deployed Engineering का मतलब है अपने engineers (और अब AI Workers) का छोटा दल एक customer organization के अंदर महीनों के लिए embed करना, ताकि उनके लिए बिल्कुल custom solution बने। हर engagement दल को यह specific बात सिखाता है कि customer की industry वास्तव में कैसे काम करती है। तीसरे या चौथे deployment तक आपके पास self-serve vertical product launch करने के लिए enough productized patterns होते हैं।

Palantir ने defense और intelligence में model invent किया। Anthropic का Applied AI दल और OpenAI का Forward Deployed function आज lab level पर इसे चला रहे हैं। Sierra और कई enterprise AI vendors इसके variants चला रहे हैं।

Enterprise-scale strategic deals के लिए founding motion या specific industry में vertical depth चाहिए वाली product कंपनियों के लिए mid-stage path के रूप में best. अक्सर Vertical AI-Native Greenfield में transition करता है.

मुख्य विचार। Engagement खुद product discovery है। Engagement के दौरान कमाए गए patterns वह moat बनते हैं जिससे कंपनी scale करती है।

कब अपनाएँ। जब target customer strategic enterprise हो, जैसे government, large bank, large hospital system, बड़ी industrial कंपनी; जब buyer की problem इतनी complex हो कि generic product solve न कर सके; और जब दल के पास हर early engagement पर 6-12 months लगाने के लिए capital और patience हो।

कैसे काम करती है। FDE इसलिए काम करता है क्योंकि यह vertical products की cold-start problem solve करता है। पहला customer कंपनी को industry सीखने के लिए pay करता है; subsequent customers ऐसा product खरीदते हैं जो पहले engagement से hardened हो चुका है। हर engagement के काम का एक fraction reusable patterns में convert करता है; समय के साथ reusable to custom काम ratio flip होता है और कंपनी services-margin economics से software-margin economics में graduate करती है।

काल्पनिक उदाहरण। MedAgent की कल्पना करें, hospital systems के लिए AI tool। MedAgent का पहला customer एक बड़ा hospital network है। MedAgent के 3 engineers 6 months के लिए hospital offices में move करते हैं और MedAgent को hospital के specific clinical workflows के लिए customize करते हैं। Hospital engagement के लिए $2M pay करता है। काम के दौरान engineers जो patterns discover करते हैं, जैसे common documentation flows, integration points, clinical-language conventions, वे productized version में reusable features बनते हैं जिन्हें MedAgent बाद में कम margins लेकिन higher volume पर दूसरे hospitals को बेचता है।

उदाहरण। Confirmed examples: Palantir के defense और commercial deployments। Anthropic का Applied AI दल। Major enterprise accounts के लिए OpenAI का Forward Deployed function। Smaller AI-native consultancies जो paid pilots चलाती हैं और समय के साथ productize करती हैं।

मुख्य जोखिम। Service-business gravity। दल day one से custom काम बेचकर वास्तविक revenue कमाता है, जो seductive और addictive है। Custom काम हमेशा करते रहना और वास्तविक product तक कठिन leap न लेना tempting है। बचाव: हर engagement से कम से कम एक reusable pattern माँगें जो अगले engagement में ship हो। Custom to productized काम ratio को top operating metric की तरह track करें।

दूसरा जोखिम। Senior engineering bandwidth। FDE कंपनी के सबसे senior engineering talent को महीनों के लिए consume करता है। बचाव: concurrent FDE engagements की संख्या उतनी ही रखें जितनी कंपनी sustain कर सके। Parallel में 2 FDE deployments reasonable हैं; 5 का मतलब आम तौर पर सब पर quality suffer कर रही है।

पहला कदम। एक strategic customer को full-margin pricing पर embedded engagement के लिए sign करें। कंपनी का product roadmap आंशिक रूप से उस customer के actual workflow से shape होना चाहिए।

C. परिणाम-नेतृत्व वाली पद्धतियाँ

सौदा access के बजाय results के around structured होता है। विक्रेता का काम measurement, attribution और consistent delivery है। ये पद्धतियाँ AI era से uniquely enabled हैं, क्योंकि AI Worker outputs को ऐसे तरीकों से मापा जा सकता है जिनसे software-seat outputs आम तौर पर नहीं मापे जा सकते।

पद्धति 9: Pay-Per-Outcome (Service-as-Software)

परिपक्वता: Emerging. शुरुआती कठिनाई: उन्नत.

सीधी भाषा में। भुगतान तब करें जब दरवाज़ा ठीक हो जाए, सिर्फ carpenter के आने पर नहीं। Pay-Per-Outcome का मतलब है खरीदार केवल तब भुगतान करता है जब AI Worker वास्तव में result deliver करे: resolved support ticket, closed sales meeting, processed insurance claim, drafted legal document। Vendor delivery risk लेता है।

यह वही pricing model है जिसे AI era ने scale पर संभव बनाया है, क्योंकि AI Worker outputs measurable हैं, जैसे software-seat outputs आम तौर पर नहीं थे। Sierra (customer support), Decagon (customer service), EvenUp (legal claims) और AI-native vendors की wave 2026 में outcome-based pricing चला रही हैं।

जब outcomes साफ़ मापे जा सकें तो founding motion के रूप में best, या seat-based से शुरू हुई कंपनियों के लिए mid-stage pricing flip के रूप में। Service-as-Software pattern से tightly coupled.

मुख्य विचार। Vendor revenue को customer value से align करें। Vendor केवल तब कमाता है जब customer value पाता है, और customer जितना ज़्यादा value पाता है, vendor उतना ज़्यादा कमाता है।

कब अपनाएँ। जब AI Worker का output साफ़ attribute और measure किया जा सके, जैसे resolved ticket resolved ticket है; drafted contract drafted contract है। जब unit economics priced outcome level पर काम करे, यानी compute cost + AI quality cost revenue per outcome से कम हो। और जब buyer outcome contracts structure करने के लिए sophisticated हो, आम तौर पर AI-native या AI-piloting buyers।

कैसे काम करती है। Outcome pricing इसलिए काम करती है क्योंकि यह seller को customer के software budget के बजाय labor budget के लिए compete करने देती है। Mid-market कंपनी customer support software की तुलना में customer support headcount पर 10× ज़्यादा खर्च करती है। Outcome pricing के through headcount budget का fraction capture करने वाला AI vendor, software budget का fraction capture करने वाले vendor से अलग revenue category में operate करता है।

Pricing math human labor cost से anchored है, SaaS comparable से नहीं। अगर customer support representative all-in roughly $5 per resolved ticket cost करता है, salary + benefits + management overhead + workspace, तो outcome price ceiling लगभग $1-3 per resolved ticket है: human cost से इतना नीचे कि customer वास्तविक savings capture करे, vendor के compute cost से इतना ऊपर कि gross margin positive हो। Vendor का compute cost per outcome, currently typical agent tasks के लिए $0.20-0.80 और model efficiency improve होने पर तेज़ी से गिरता हुआ, floor set करता है; customer का human cost ceiling set करता है; price बीच में कहीं रहता है। Vendor का strategic सवाल यह है कि gap को कितना aggressively compress करना है: wider gap का मतलब higher margin per outcome लेकिन slower customer adoption; narrower gap adoption तेज़ करता है लेकिन उन वर्षों में margin compress करता है जब compute prices अभी गिर रहे हैं।

Technical foundation outcome attribution है। Vendor को audit-grade telemetry produce करनी होगी: हर priced outcome के लिए verifiable record कि AI ने क्या किया, क्या process किया और result कैसे confirm हुआ। इसके बिना customer disputes का objective basis नहीं होता और revenue collection quarterly negotiation बन जाती है। जो कंपनियाँ यह motion अच्छी तरह चलाती हैं वे outcome-attribution infrastructure को accounting overhead नहीं, product का हिस्सा मानती हैं; और उसे finance analysts से नहीं, engineers से staff करती हैं। यह discipline motion को durable बनाता है; इसकी कमी motion को विफल करती है।

काल्पनिक उदाहरण। TicketBot की कल्पना करें, AI customer-support agent। TicketBot customers से per seat charge नहीं करता। इसके बजाय customer हर support ticket के लिए $0.50 देता है जिसे TicketBot खुद resolve करता है, human तक escalate किए बिना। 50,000 tickets per month वाले customer को $25,000 monthly bill मिलता है, लेकिन केवल तब जब TicketBot tickets सच में resolve करे। अगर TicketBot incoming tickets का केवल 30% resolve करता है, bill उसका एक तिहाई होगा। Customer के CFO को यह पसंद है; customer के procurement दल को contract structure करना सीखना होगा।

उदाहरण। Confirmed examples: AI customer service के लिए Sierra की per-resolution pricing। Decagon के outcome-based contracts। Personal-injury legal काम के लिए EvenUp की per-claim pricing। यह pattern 2026 में सबसे actively expanding pricing structures में है।

मुख्य जोखिम। शुरुआती वर्षों में negative gross margin। अगर AI quality अभी पर्याप्त high नहीं है, तो vendor विफल काम के compute और human-fallback costs pay करता है लेकिन revenue नहीं पाता। बचाव: ऐसा price-per-outcome set करें जिसमें early-quality issues के लिए margin buffer हो, फिर quality improve होने पर tighter pricing की ओर जाएँ। कई vendors पहले 12-18 months तक near-zero gross margin पर operate करते हैं जब तक quality stabilize न हो।

दूसरा जोखिम। Attribution disputes। Buyer claim करता है कि AI ने outcome produce नहीं किया, या buyer के अपने staff ने किया। बचाव: day one से outcome-attribution telemetry में invest करें। Vendor को irrefutable, audit-quality evidence चाहिए कि AI Worker ने कौन से outcomes produce किए।

पहला कदम। एक outcome चुनें, सबसे साफ़ और सबसे measurable, और उसे price करें। पहले outcome की economics proven होने तक multiple outcomes को simultaneously price करने की इच्छा रोकें।

पद्धति 10: Value-Based Engagement

परिपक्वता: Speculative. शुरुआती कठिनाई: उन्नत.

सीधी भाषा में। ऐसी consulting firm hire करने की कल्पना करें जिसे केवल उनकी बनाई savings का percentage मिलता है: McKinsey या BCG style engagement, लेकिन deliverable slide deck नहीं बल्कि live AI Worker है, और pricing सीधे customer के measured P&L improvement से tied है। Value-Based Engagement का मतलब है बड़े strategic deals को created business value के percentage के रूप में structure करना, जिनकी rates deal complexity और buyer sophistication के हिसाब से बहुत vary करती हैं। यह उन AI deployments के लिए common है जो hundreds of millions of dollars वाली P&L lines को touch करते हैं।

Motion speculative है क्योंकि यह buyer की value-based contracting को formally commit करने की willingness पर निर्भर करता है, जिसके लिए ज़्यादातर enterprise procurement organizations अभी structured नहीं हैं। 2026 में यह ज़्यादातर AI-native vendors और forward-leaning enterprise customers के बीच bespoke deals के रूप में मौजूद है।

केवल strategic-deal scale (>$1M ACV) पर realistic और केवल AI-native buyers के साथ। Early-stage कंपनियों के लिए viable motion नहीं; आम तौर पर सबसे बड़े deals के लिए Enterprise Field या FDE के ऊपर layered.

मुख्य विचार। Deal को customer के measurable economic outcome के function के रूप में price करें। Vendor customer के gain के proportion में upside लेता है और कुछ structures में threshold से कम gain होने पर downside भी लेता है।

कब अपनाएँ। जब customer के executive sponsor के पास value-based contracting commit करने की authority हो, आम तौर पर केवल C-suite level पर; जब created value साफ़ तौर पर AI Worker को attribute की जा सके, दूसरे initiatives से confounded न हो; और जब deal size contracting complexity justify करने के लिए पर्याप्त बड़ा हो।

कैसे काम करती है। Value-Based Engagement तब काम करता है जब दोनों parties value का मतलब और उसे measure करने का तरीका agree कर सकें। Structure vendor incentives को customer outcomes से किसी भी दूसरे pricing model की तुलना में ज़्यादा tightly align करता है: vendor का revenue customer के measurable gain के proportion में बढ़ता है, जिससे conventional vendor-buyer adversarial dynamic हटता है जहाँ vendor access के लिए charge करना चाहता है और buyer results के लिए pay करना चाहता है।

Contract structure seat- या outcome-based pricing से materially ज़्यादा complex है। Typical agreement के 4 components होते हैं। Baseline measurement period (आम तौर पर deployment से 30-90 days पहले) establish करता है कि AI Worker के बिना customer metrics कैसे दिखते थे। Value-share formula define करता है कि gain का कौन सा fraction vendor capture करता है, आम तौर पर percentage जो deal complexity और buyer sophistication के हिसाब से vary करता है। Ceiling and floor upside को cap करते हैं, ताकि vendor customer executives द्वारा internally defend की जा सकने वाली सीमा से ज़्यादा न कमाए, और downside को भी cap करते हैं, ताकि vendor customer को product deploy करने के लिए pay न कर रहा हो। और audit rights vendor को customer की reporting verify करने की ability देते हैं, उन metrics पर जो billing drive करते हैं। Audit rights के बिना customer का procurement organization contract के पहले true-up cycle पर पहुँचते ही measured value under-report करेगा।

Constraint contracting maturity है। ज़्यादातर enterprise procurement organizations अभी value-based deals को scale पर structure करने के लिए equipped नहीं हैं; legal, finance और operations, सभी को ऐसे representatives चाहिए जो model समझते हों और non-standard contract terms commit करने की authority रखते हों। इसलिए ये deals आम तौर पर C-suite level पर executive sponsor माँगते हैं: केवल वही authority procurement organization के default "हम deals इस तरह structure नहीं करते" को override कर सकती है। Sponsor के बिना proposal organization के middle में indefinite stall करता है, चाहे technical merit कितनी भी हो। Motion 10 चलाने वाले sellers अपनी शुरुआती energy का ज़्यादातर हिस्सा executive sponsor identify और recruit करने में लगाते हैं; बाकी motion sponsor के mandate पर execution है।

काल्पनिक उदाहरण। CashFlow की कल्पना करें, hedge funds के लिए AI tool। $50B fund CashFlow deploy करता है और 12-month measurement period में trading efficiency में $40M annual improvement को deployment से attribute करता है। CashFlow contract baseline से ऊपर measurable improvement के 15% पर structured है: fund contract की duration के लिए annually $6M pay करता है। Deal negotiate करने में 9 months लगे, fund के CIO और CFO की personal approval चाहिए थी और procurement से केवल इसलिए निकला क्योंकि executive sponsor ने push किया।

उदाहरण। Emerging analogues: Strategic enterprise customers के साथ कुछ Anthropic Applied AI engagements। Mission outcomes के around structured कुछ Palantir deployments। Financial services, healthcare और consulting firms में forward-leaning AI deployments। Pattern इतना नया है कि canonical exemplar अभी नहीं है।

मुख्य जोखिम। Attribution disputes। Customer claim करता है कि AI ने value produce नहीं किया, या customer के अपने initiatives ने किया। बचाव: engagement शुरू होने से पहले baseline measurement period establish करें। Hypothetical counterfactual के बजाय post-deployment metrics को pre-deployment baseline से compare करें।

दूसरा जोखिम। Long contracting cycles। Value-based contracts negotiate होने में 6-12 months ले सकते हैं, जिस दौरान दल relationship में invest कर रहा होता है लेकिन revenue नहीं आता। बचाव: value-based engagement को paid pilot phase के साथ combine करें जो production contract negotiate होते समय revenue produce करे।

पहला कदम। Proposal में invest करने से पहले वह executive sponsor खोजें जिसके पास value-based contracting commit करने की authority हो। Sponsor के बिना motion mid-organization procurement में stall करता है।

D. साझेदार-नेतृत्व वाली पद्धतियाँ

Third parties purchase drive करते हैं। विक्रेता का काम alliance management है: partners को इतना successful बनाना कि वे आपके लिए बेचते रहें। ये motions शुरू होने में slow हैं, लेकिन partner ecosystem बन जाने के बाद durable, repeatable revenue produce करते हैं।

पद्धति 11: Channel & SI Partnership

परिपक्वता: Proven. शुरुआती कठिनाई: मध्यम.

सीधी भाषा में। Apple Best Buy के through बेचता है। Beverages grocery stores के through बिकते हैं। बहुत सारे potential customers और कम sales reps वाले कई vendors को last mile selling और deploying के लिए किसी और की ज़रूरत होती है। Channel and Systems Integrator (SI) Partnership का मतलब है अपने AI Workers को third parties के through बेचना: value-added resellers, consultancies (Accenture, Deloitte, Slalom, BCG, McKinsey), regional systems integrators; जो उन्हें अपने clients के साथ broader engagements के हिस्से के रूप में deploy करते हैं।

यह motion उन products के लिए essential है जिन्हें significant implementation expertise चाहिए। बड़े bank में deploy होने में weeks लेने वाला AI Worker तब बेचना बहुत आसान होता है जब Accenture deployment कर रहा हो: bank already उस पर trust करता है, Accenture bank के workflows जानता है और उसके पास AI services cover करने वाला contract template पहले से होता है।

Implementation expertise माँगने वाले products के लिए primary motion के रूप में, या Enterprise Field Sales के साथ complementary channel के रूप में best.

मुख्य विचार। Partners से implementation, customization और ongoing operations का काम संभलवाएँ जो AI vendor खुद नहीं करना चाहता। Partners को margins या referral fees के through pay करें, ऐसे structured कि उनकी long-term success incentivize हो।

कब अपनाएँ। जब target customer ऐसा बड़ा enterprise हो जिसके पास पहले से SI relationships हों, product को significant implementation काम चाहिए, और कंपनी में 12-18 months तक partner relationships बनाने का patience हो, channel के meaningful revenue produce करने से पहले।

कैसे काम करती है। Channel-led इसलिए काम करता है क्योंकि SIs के पास enterprise buyers के साथ established trust होता है जो AI vendors के पास अभी नहीं है। SI की recommendation खुद sales argument है। Constraint partner economics है: SIs को engagement पर 30-50% margin चाहिए, जिससे AI vendor की pricing flexibility compress होती है। जो कंपनियाँ यह motion अच्छी तरह चलाती हैं वे SI को passive distributor की तरह treat करने के बजाय co-sell करती हैं: joint sales calls, joint case studies, joint executive briefings।

काल्पनिक उदाहरण। DocAI की कल्पना करें, AI document-processing tool। DocAI बड़े banks को सीधे नहीं बेचता; यह Accenture के through बेचता है। Accenture के consultants DocAI को अपने banking clients के लिए larger digital transformation engagements के हिस्से के रूप में implement करते हैं जिनके budgets पहले से $50M होते हैं। DocAI को recurring software license revenue मिलता है, आम तौर पर $500K-$2M per bank; Accenture को implementation fees मिलती हैं, $5M-$20M per engagement। DocAI को bank procurement directly navigate नहीं करना पड़ता; Accenture के existing relationships वह काम करते हैं।

उदाहरण। Confirmed examples: Fortune 500 accounts में बेचने वाले ज़्यादातर enterprise AI vendors अपने direct sales motion के साथ channel motion चलाते हैं। Copilot के लिए Microsoft का partner ecosystem। Einstein/Agentforce के लिए Salesforce का SI ecosystem। AI deploy करने वाले ज़्यादातर regional banks SI-led engagements इस्तेमाल करते हैं।

मुख्य जोखिम। Partner economics misalignment। Partner alternative vendors push करके ज़्यादा money बनाता है। बचाव: partner enablement में invest करें, training, sales materials, technical support, ताकि partner को alternatives की तुलना में आपका product बेचना operationally आसान लगे। Partner sales relationship business है; जो कंपनी partner success में सबसे ज़्यादा invest करती है वही जीतती है।

दूसरा जोखिम। Direct sales के साथ partner conflict। Direct sales दल और channel partner same deals के लिए compete करने लगते हैं, margins erode होते हैं। बचाव: day one से clear deal-registration rules establish करें। जो partners deal source करते हैं, वही own करते हैं; direct sales वे deals handle करता है जहाँ partners नहीं पहुँच सकते।

पहला कदम। अपने target vertical में सबसे active 3 SIs identify करें। ज़्यादा जोड़ने से पहले उनमें से 2 के साथ deep relationships में invest करें।

पद्धति 12: Hyperscaler Co-Sell

परिपक्वता: Proven. शुरुआती कठिनाई: मध्यम.

सीधी भाषा में। Cloud provider के menu पर featured होना। Hyperscaler Co-Sell का मतलब है अपने AI product को AWS Marketplace, Microsoft Azure Marketplace या Google Cloud Marketplace पर list करना, और hyperscaler के sales organization के साथ partner करके deals को उनके existing customer relationships में drive करना। Hyperscaler के account executives आपका product बेचने में मदद करते हैं क्योंकि आपके deployment से underlying compute revenue उन्हें मिलता है।

AI products के लिए यह motion uniquely powerful है क्योंकि underlying compute load बड़ा होता है: हर AI deployment meaningful cloud spend produce करता है, जिसे hyperscaler का sales दल grow करने के लिए incentivized होता है।

Significant cloud footprint वाले compute-heavy AI products के लिए primary motion के रूप में, या Enterprise Field Sales के ऊपर additional channel के रूप में best.

मुख्य विचार। अपनी sales motion को hyperscaler की sales motion के साथ align करें। Hyperscaler AE underlying compute पर commission कमाता है; इसलिए AE के पास आपको अपने accounts में लाने का incentive होता है।

कब अपनाएँ। जब product cloud-deployed हो, आम तौर पर AWS, Azure या GCP; product hyperscaler के लिए meaningful compute revenue produce करता हो; दल के पास hyperscaler relationships maintain करने की partnership-management capacity हो; और target buyer पहले से meaningful cloud customer हो।

कैसे काम करती है। Hyperscaler Co-Sell इसलिए काम करता है क्योंकि hyperscaler AEs उन relationships के ऊपर बैठे होते हैं जिन्हें AI vendors आसानी से replicate नहीं कर सकते: उनके पास customer के साथ वर्षों का trust है, वे customer की procurement preferences जानते हैं और technical decision-making के लिए private channels रखते हैं। जब hyperscaler AE अपने किसी account में AI vendor introduce करता है, AI vendor credibility shortcut inherit करता है। Constraint hyperscaler-program participation है: AI vendor को co-sell के eligible होने के लिए hyperscaler के partner program में invest करना होता है, certifications, joint case studies, marketplace listings।

काल्पनिक उदाहरण। VoiceTalk की कल्पना करें, significant cloud compute requirements वाला AI voice tool। VoiceTalk AWS Marketplace पर list होता है और top-tier AWS partner बनता है। Fortune 1000 telecom को बेच रहा AWS account executive expanded cloud spend की discussion में VoiceTalk mention करता है। Customer VoiceTalk को अपने existing AWS contract में जोड़ता है, fresh procurement से जाने के बजाय already-allocated AWS budget इस्तेमाल करके। AWS underlying compute revenue कमाता है, जो बड़ा है क्योंकि voice AI compute-heavy है; VoiceTalk को direct deal की तुलना में sales cycle के fraction पर customer मिल जाता है।

उदाहरण। Confirmed examples: Significant cloud workloads वाले ज़्यादातर enterprise AI-native vendors hyperscaler co-sell motions चलाते हैं। AWS Marketplace, Azure Marketplace और GCP Marketplace में 2026 में AI-vendor catalogs बढ़ रहे हैं। Amazon Bedrock पर Anthropic का Claude खुद इस dynamic का extreme version है, जहाँ hyperscaler AI capability सीधे बेच रहा है।

मुख्य जोखिम। Hyperscaler de-prioritization। Hyperscaler की strategic priorities shift होती हैं और आपका product featured नहीं रहता। बचाव: hyperscaler motion के साथ meaningful direct sales motion बनाए रखें, ताकि de-prioritization existential event नहीं बल्कि setback रहे।

दूसरा जोखिम। Multi-hyperscaler complexity। AWS, Azure और GCP पर simultaneously बेचना partner-management काम को triple कर देता है। बचाव: उस hyperscaler को prioritize करें जिसका customer base आपके target market से सबसे ज़्यादा overlap करता है। बाकी तब जोड़ें जब दल के पास bandwidth हो।

पहला कदम। एक hyperscaler चुनें और दूसरों पर list करने से पहले वहाँ top-tier partner बनें।

सभी पद्धतियों में आने वाले concepts

कई concepts motions में बार-बार आते हैं और उन्हें हर बार repeat करने के बजाय एक बार define करना बेहतर है।

Procurement navigation। Buyer की formal purchasing process से deal को आगे बढ़ाने की प्रक्रिया: security review, legal review, vendor approval, contract negotiation, integration approval, procurement signoff। Procurement navigation दिन ले सकता है (PLG) या 18 months (strategic enterprise)। Vendor-led sales cycles में variance का single largest source यही है। जिस seller ने procurement navigation को sales motion में बनाया नहीं, उसे बार-बार deals "legal में stalled" या "security review में stuck" दिखेंगे: ये code phrases हैं कि seller ने buyer की process नहीं समझी।

AI-native vendors के लिए लगभग हर enterprise deal में 3 procurement objections आते हैं और seller की पहली executive conversation से पहले standard sales kit में उनके जवाब होने चाहिए:

Data privacy और model training। Enterprise procurement में AI deals रुकने का सबसे common reason buyer का यह डर है कि उनका proprietary data vendor के models train करने में इस्तेमाल होगा, या इससे भी बुरा, identifiable form में underlying foundation-model provider से share होगा। Sellers को master service agreement में clear, written commitment चाहिए, marketing पृष्ठ पर नहीं: customer data model training के लिए इस्तेमाल नहीं होगा, identifiable form में foundation-model providers से share नहीं होगा और contract termination पर delete किया जाएगा। जो vendors इस objection को pre-sales documentation में handle करते हैं, वे उन vendors से 30-60 days faster close करते हैं जो legal counsel को इसे scratch से surface और negotiate करने देते हैं।

Hallucination liability। जब AI गलत हो, तो responsible कौन है? Regulated industries, healthcare, legal, financial services, में sellers को AI accuracy, warranty limitations और material decisions के लिए humans-in-the-loop रखने की customer obligation पर pre-drafted contractual language चाहिए। इस language के बिना legal review 90 days या उससे ज़्यादा लेता है जबकि buyer का counsel इसे scratch से लिखता है; और buyer का counsel लगभग हमेशा इसे seller की तुलना में ज़्यादा conservative लिखता है।

Compute residency और model deployment। Regulated industries या non-US jurisdictions के buyers के लिए AI कहाँ run करता है, यह data कहाँ रहता है जितना ही महत्वपूर्ण है। EU में AWS Bedrock, EU में Azure OpenAI, on-premises deployments और dedicated-tenant model hosting की demand बढ़ रही है। इन requirements के लिए deployment story न रखने वाले sellers legal review शुरू होने से पहले ही technical due diligence में deals lose करते हैं।

Trust Ladder। Worker Catalog में defined: AI Worker की progression co-pilot से, जहाँ AI suggest करता है और human हर action approve करता है; supervised autonomous तक, जहाँ AI defined task type पर act करता है और human aggregate output review करता है; और full autopilot तक, जहाँ AI per-task supervision के बिना act करता है। हर rung अलग pricing model imply करता है। Co-pilot tool की तरह priced है। Supervised autonomous seat-equivalent की तरह priced है। Full autopilot outcome की तरह priced है। Trust Ladder ignore करने वाली sales motions buyer की actual deployment posture के लिए wrong pricing tier पर पहुँचती हैं।

Pilot economics। 2026 में लगभग हर six-figure AI deal paid pilot से शुरू होता है: time-bounded, scope-limited initial deployment, आम तौर पर 30-90 days, जो buyer को production contract commit करने से पहले अपने environment में product validate करने देता है। Pilot अलग sales motion नहीं है; यह एक structure है जो Enterprise Field, FDE, AI-Augmented Outbound और बढ़ते हुए Pay-Per-Outcome motions के अंदर रहता है। Pilots paid होते हैं, ताकि वे free consulting न बनें, लेकिन production contract से छोटे होते हैं: आम तौर पर pilot के लिए $25-100K, फिर pilot successful होने पर production deployment के लिए $100K-1M।

Economics standalone basis पर शायद ही justify होते हैं: pilots इतने tightly scoped होते हैं कि दल अक्सर उन पर money lose करता है। Economics केवल इसलिए काम करते हैं क्योंकि pilot meaningfully higher pricing पर production contract में convert होता है। जो कंपनियाँ production-conversion mechanics के बिना pilots चलाती हैं, clear conversion clauses, deadline-based pricing tiers, expanded-scope upgrades, वे high pilot-revenue और low production-revenue पर पहुँचती हैं, जो temporary नहीं structural problem है। Strong pilot operators को weak ones से 2 practical disciplines अलग करते हैं: original agreement में pilot success metrics rigorously scope करें, out-of-scope काम separate engagement है, pilot extension नहीं; और contract को ऐसा structure करें कि pilot के end पर buyer 30 days के भीतर production में convert करे या preferred pricing lose करे। Clause indefinite pilot extensions रोकता है, जो सबसे common pilot failure mode है, और buyer के procurement organization को defined timeline पर decision लेने के लिए force करता है।

RevOps stack। वह instrumentation जो किसी भी vendor-led motion को काम कराता है: CRM (Salesforce, HubSpot), sales engagement (Outreach, Salesloft), product analytics (Mixpanel, Amplitude), revenue intelligence (Gong, Chorus), forecasting (Clari, Boostup), customer success (Gainsight, Catalyst)। 2026 में stack की हर layer के AI-native versions उभर रहे हैं, और उन्हें integrate करने की discipline खुद meaningful competitive advantage है। RevOps में कम invest करने वाली कंपनियाँ अपनी सभी motions अँधेरे में चलाती हैं, हर deal से individually सीखती हैं बजाय deals के across patterns से सीखने के।

Outcome attribution। यह prove करने के लिए required technical infrastructure कि कौन से outcomes AI Worker ने produce किए और कौन से humans, दूसरे systems या happenstance ने। Outcome attribution outcome-based pricing और value-based engagement की foundational requirement है। Outcome attribution के बिना outcome pricing ship करने वाली कंपनियाँ customers के साथ chronic disputes में फँसती हैं।

Outcome-led deals में compensation। Outcome-based pricing (पद्धति 9) और value-based engagement (पद्धति 10) ऐसी structural problem बनाते हैं जिसे traditional SaaS commission plans handle नहीं कर सकते। Seat-based deal में AE $100K ACV contract close करता है और sign होने वाले दिन bookable contract value पर commission कमाता है। Outcome-based deal में day one पर कोई $100K bookable amount नहीं है: customer $0.50 per resolved ticket, $5 per processed claim, $50 per booked meeting pay करेगा। Revenue contract term में आता है, contingent on AI Worker performing.

2026 में 3 approaches उभर रहे हैं और ये motions चलाने वाली ज़्यादातर कंपनियाँ इनके across experiment करती हैं:

Projected-usage commission। AE signing पर projected annual revenue figure पर commission कमाता है, आम तौर पर customer के stated volume से derived, जैसे "100,000 tickets per year × $0.50 = $50K projected ACV"। Risk: AEs projected volumes inflate करते हैं और customers का एक हिस्सा estimate की तुलना में dramatically कम actual revenue deliver करता है। यह model चलाने वाली कंपनियाँ आम तौर पर actuals projection से significantly कम होने पर commission claw back करती हैं, जिससे deal close होने के महीनों बाद angry conversations होती हैं।

Realized-revenue commission। AE actual collected revenue पर commission कमाता है, quarterly paid with 60-90 day lag। यह AE incentives को delivery से align करता है लेकिन recruiting problem बनाता है: outcome-based deals पर काम करने वाले AEs closing के महीनों बाद paid होते हैं। Sellers जिनके पास कहीं और seat-based विकल्प हैं, realized-revenue plan higher rates से compensate न करे तो seat-based path चुनेंगे।

Hybrid। Outcome-led motions चलाने वाली ज़्यादातर कंपनियाँ blend इस्तेमाल करती हैं: commission का fraction conservative volume projection पर signing के समय paid, बाकी actual revenue land होने पर paid। Roughly 30% upfront और 70% trailing common शुरुआती बिंदु है, हालाँकि ratio कंपनी और seller seniority के हिसाब से vary करता है।

Compensation का सवाल motion ship होने से पहले शायद ही solve होता है। Motion 9 या Motion 10 चलाने वाली ज़्यादातर कंपनियों ने पहले 6 से 12 months यह सीखने में बिताए कि कौन सा commission structure सही seller behavior पैदा करता है, और सीखते हुए उसे adjust किया। सही approach है conservative तरीके से शुरू करना, realized-revenue पर heavy, यह accept करना कि recruiting harder है, और actual-versus-projected variance predictable होने पर अधिक upfront commission की ओर migrate करना।

AI हर पद्धति में क्या बदलता है

इस catalog की पद्धतियों के ancestors pre-AI sales literature में हैं। Founder-Led Sales, Enterprise Field, Channel, PLG: इनमें से कोई नई नहीं। नया यह है कि AI हर motion के अंदर क्या करता है। AI era sales motions को replace नहीं करता, बल्कि हर motion की unit economics, role definitions और tool stack बदलता है।

5 shifts को नाम देना ज़रूरी है। साथ मिलकर वे explain करते हैं कि 2026 में वही nominal motions 2020 की तुलना में dramatically different economics क्यों produce करते हैं।

विक्रेता अब AI-augmented है। RevOps stack की हर layer का अब AI-augmented version है: research और prospecting (Clay, Apollo, ZoomInfo with AI enrichment), outbound drafting (Outreach, Salesloft, instantly.ai), conversation intelligence (Gong, Chorus, Avoma; सब heavily AI-instrumented), forecasting (Clari, BoostUp, with AI-driven deal scoring) और contract review (Ironclad, Spotdraft, with AI redlining)। 2020 जैसी motion को 2026 tool stack के साथ चलाने वाला sales दल per rep 2-4× activity volume produce करता है। Implication: 15 साल तक SaaS sales define करने वाला SDR-heavy outbound function, AI से augmented छोटे दल में compress हो रहा है। AI-Augmented Outbound (पद्धति 6) इसका सबसे visible expression है, लेकिन यही dynamic हर vendor-led motion को reshape कर रहा है।

Compute अब COGS है। Traditional SaaS gross margins 75-85% थे क्योंकि dominant variable cost infrastructure नहीं, customer support था। AI-native products की variable costs substantially higher हैं क्योंकि हर query, हर generation, हर tool call frontier-model compute invoke करता है जिसके लिए vendor pay करता है। शुरुआती वर्षों में AI-native gross margins आम तौर पर 50-70% होते हैं, scale के साथ 65-80% तक चढ़ते हैं। इससे बदलता है कि कौन सी motions economically viable हैं। Pay-Per-Outcome (पद्धति 9) structurally इससे exposed है: अगर compute cost per resolved ticket $0.40 और price per resolved ticket $0.50 है, unit economics काम करते हैं; अगर compute cost $0.60 तक चढ़ता है, कंपनी customers को product इस्तेमाल करने के लिए pay कर रही है। Access के रूप में price करने वाली motions, PLG, seat pricing के साथ Enterprise Field, compute volatility से insulated हैं; outcome के रूप में price करने वाली motions नहीं।

Outcome attribution अब अपनी discipline है। SaaS में seller access deliver करता था और buyer value measure करता था। AI में seller सीधे value deliver कर रहा है; और वह value seller को measure करनी होगी, buyer को नहीं, क्योंकि buyer आसानी से AI-produced outcomes और human-produced outcomes अलग नहीं कर सकता। यह नया sales-engineering function है: AI Worker को instrument करना ताकि audit-grade evidence produce हो कि उसने कौन से outcomes produce किए, किनमें assist किया और कौन से human ने handle किए। Outcome pricing (पद्धति 9) या value-based engagements (पद्धति 10) outcome attribution के बिना ship करने वाली कंपनियाँ customers के साथ chronic disputes में जाती हैं। इससे जो नया role बनता है, कभी-कभी AI Outcome Engineer या AI Sales Engineer कहलाता है, traditional sales engineering और traditional customer success के बीच बैठता है।

खरीदार भी AI-augmented है। Procurement organizations vendor proposals evaluate करने, security questionnaires summarize करने और pre-screen technical reviews चलाने के लिए AI agents deploy करना शुरू कर रहे हैं। जो sales दल AI-augmented procurement anticipate नहीं करता, वह उस दल से हारता है जो करता है: proposals ऐसे लिखकर जिन्हें AI agents cleanly summarize कर सकें, technical documentation ऐसे structure करके जिससे AI agents specs extract कर सकें, pricing ऐसे formats में देकर जिन्हें AI agents compare कर सकें। वह era खत्म हो रहा है जिसमें salesperson भरोसा कर सकता था कि buyer के पास सब पढ़ने का समय नहीं होगा। Buyer का AI सब पढ़ता है।

Motions खुद converge होने लगी हैं। PLG enterprise pipeline produce करता है। Enterprise Field accounts खोलता है जो फिर self-serve usage से expand होते हैं। AI-Augmented Outbound पहले deals के लिए Founder-Led closing feed करता है, फिर Field Sales में transition करता है। इस catalog में motion taxonomy discrete categories के रूप में present है क्योंकि revenue दल इसी तरह plan और staff करते हैं। लेकिन operation में ज़्यादातर सफल AI-native कंपनियाँ 3 या 4 motions simultaneously blend करती हैं, और AI-augmentation उनके बीच connective tissue की तरह काम करता है। यही Common Hybrid Motions dynamic है जिसे अगला खंड map करता है।

ये 5 shifts मिलकर B2B sales economics में SaaS transition के बाद सबसे consequential change produce करते हैं। 2026 motion को 2020 economics के साथ चलाने वाली कंपनी category mistake कर रही है। 2026 motion को 2026 economics के साथ चलाने वाली कंपनी अपने peers से अलग game में compete कर रही है।

Common hybrid motions

ऊपर की 12 motions discrete archetypes के रूप में present हैं, लेकिन ज़्यादातर सफल AI-native कंपनियाँ isolation में single motion नहीं चलातीं। वे sequence चलाती हैं: एक motion से foothold पाती हैं, फिर कंपनी mature होने और deal sizes scale होने पर दूसरी में evolve करती हैं। Transitions deliberate strategic choices हैं।

6 hybrid sequences इतनी बार आती हैं कि उन्हें नाम देना चाहिए।

PLG → Enterprise Field। Founder self-serve product ship करता है जो individual-developer या छोटे दलों की adoption produce करता है। जैसे usage बड़े संगठनों में बढ़ता है, security review, multi-seat negotiation और centralized procurement bottleneck बन जाते हैं। दल enterprise account executives hire करता है ताकि bottom-up usage को top-down contracts में convert किया जा सके, आम तौर पर self-serve plan की per-seat economics से 5-20×। Cursor, Linear और Notion ने इस transition के variants चलाए हैं।

Founder-Led → AI-Augmented Outbound। Founder playbook validate करने के लिए पहले 30-50 deals hand-close करता है। Playbook document हो जाने पर दल outreach scale करने के लिए AI-augmented outbound बनाता है, SDR headcount को linearly scale किए बिना। Transition कठिन है क्योंकि यह founder को sales से step back करने और दल को RevOps infrastructure में invest करने की माँग करता है, लेकिन 2026 में mid-market AI-native कंपनियों के लिए यह सबसे common scaling path है।

Enterprise Field → Pay-Per-Outcome। दल seat-based enterprise contracts बेचकर शुरू करता है जिनमें paid pilot phase शामिल होता है। जैसे AI Worker की quality stabilize होती है और outcome-attribution infrastructure mature होता है, दल seat-based one के साथ outcome-based tier offer करना शुरू करता है। Existing customers पहले outcome pricing में convert होते हैं, क्योंकि trust पहले से है; नए customers को day one से outcome pricing pitch किया जाता है। Sierra, Decagon और कई customer-service AI vendors visibly यह evolution चला रहे हैं।

FDE → Productized Enterprise Field। दल same industry के 2 या 3 large enterprise customers के अंदर embed होकर शुरू करता है। हर engagement दल को कुछ specific सिखाता है। तीसरे या चौथे deployment तक दल के पास enough productized patterns होते हैं ताकि self-serve enterprise field motion launch हो सके जिसे same industry की दूसरी firms embedded दल के बिना adopt कर सकें। FDE phase learning के लिए pay करता है; field motion उसे compound करता है। Transition कठिन है क्योंकि services-business gravity वास्तविक है, लेकिन FDE के दौरान कमाए गए patterns वही हैं जिन्हें generic field motion acquire करने में साल लगाता है।

Open-Source-Led → Channel & SI Partnership। दल AI infrastructure project open-source करता है और developer mindshare कमाता है। जैसे enterprise customers open project को scale पर deploy करना शुरू करते हैं, SI partners (Accenture, Deloitte) अपने clients के लिए इसे implement करते मिलते हैं। दल partner program formalize करता है, enterprise features जोड़ता है, security, audit, support, और उन SIs के through commercial licenses बेचना शुरू करता है जो पहले से open project deploy कर रहे हैं। LangChain और कई agent-framework कंपनियाँ visibly यह play चला रही हैं।

Marketplace-Led → Direct Enterprise। दल host platform के marketplace के अंदर शुरू करता है (Salesforce AppExchange, Shopify App Store, Microsoft AppSource), जहाँ discovery, billing और trust platform से inherit होते हैं। छोटे customers low marketplace-fee economics पर convert होते हैं। जैसे deal sizes six- या seven-figure range में बढ़ते हैं, platform का revenue-share punitive हो जाता है और सबसे बड़े customers वैसे भी direct contracts prefer करते हैं। दल small enterprise sales motion बनाता है जो top-tier accounts के लिए marketplace bypass करता है, जबकि marketplace छोटे customers के लिए discovery और self-serve channel बना रहता है। Marketplace long tail के लिए customer acquisition fund करता रहता है; direct sales head capture करता है।

General principle: इस catalog की ज़्यादातर motions revenue strategy के first half के रूप में, whole strategy की तुलना में बेहतर काम करती हैं। जो founders second half पहले से नाम देते हैं, PLG कंपनी जिस enterprise field motion में graduate करेगी, pilot motion जिस outcome-pricing tier को introduce करने का अधिकार कमाएगा, founder-led motion जिस channel में convert होगा, वे उन founders से बेहतर perform करते हैं जो entry motion को entire plan मानते हैं।

Common motion failures

इस catalog की motions काम करने वाली recipes के रूप में present हैं। हर एक के विफल होने का characteristic way भी है: motion wrong होने से नहीं, बल्कि दल द्वारा उसे incorrectly चलाने से। 9 failure patterns इतनी बार आते हैं कि उन्हें नाम देना चाहिए। जो revenue leader इन्हें अपने operation में पहचानता है वह fix कर सकता है; जो नहीं पहचानता, वह उसी तरह हारता रहेगा।

Enterprise motion के बिना PLG। दल self-serve adoption successfully scale करता है, individual usage बड़े संगठनों में बढ़ता है और कंपनी wall hit करती है जब वे संगठन purchasing centralize करना चाहते हैं। दल के पास enterprise sales function नहीं है और वह उसे जल्दी enough बना नहीं सकता; weaker products लेकिन वास्तविक Enterprise Field motions वाले competitors consolidated contracts capture कर लेते हैं। Fix है पहला enterprise seller PLG द्वारा enterprise-scale prospects produce करने से पहले hire करना, बाद में नहीं।

PLG-versus-Enterprise roadmap clash। यह ऊपर वाले failure का cultural sibling है। दल enterprise motion successfully बनाता है, पहले enterprise sellers hire करता है, और महीनों के भीतर sellers product roadmap को enterprise features की ओर खींच रहे होते हैं: SSO, audit logs, custom integrations, security certifications, role-based access controls। वहीं original PLG product दल individual-user UX, fast iteration और consumer-grade simplicity पर focus बचाने के लिए लड़ता है जिसने first place में bottom-up adoption पैदा किया था। दोनों sides के legitimate cases हैं। Roadmap fights bitter होते हैं; product दल की velocity गिरती है; engineering org अपने best designers उन कंपनियों को खोता है जिनके mandates cleaner हैं। Fix है upfront acknowledge करना कि कंपनी अब shared codebase पर 2 products बना रही है: self-serve PLG product और enterprise-grade variant; और हर एक को separate engineering और design capacity देना। Single roadmap और single दल maintain करने की कोशिश करने वाली कंपनियाँ आम तौर पर PLG growth engine खोती हैं, क्योंकि दल enterprise feature काम में consume हो जाता है, या enterprise business खोती हैं, क्योंकि product को enterprise buyers द्वारा required security और admin features कभी नहीं मिलते।

Founder-led जो कभी hand off नहीं करता। Founder पहले 50 deals close करता है और informal pricing, integration commitments और customer relationships बनाता है जो केवल founder के दिमाग़ में exist करते हैं। पहला sales hire विफल होता है क्योंकि inherit करने के लिए documented playbook नहीं है। Founder indefinitely sales meetings में लौटता रहता है और कंपनी का growth ceiling founder का calendar बन जाता है। Fix है founder-led phase के दौरान जैसे-जैसे होता है हर commitment, हर pricing exception और हर deal structure document करना, ताकि eventual handoff document वास्तविक समय में बने।

बहुत जल्दी VP hire के साथ enterprise field। दल founder द्वारा playbook personally validate करने से पहले VP of Sales hire करता है। VP existing motion scale करने की expectation से आता है और इसके बजाय उसे invent करना पड़ता है, आम तौर पर अपनी पिछली कंपनी की motion import करके, जो आम तौर पर fit नहीं होती। VP 12 months में विफल होता है, 12 से 18 months capital burn कर चुका होता है। Fix है founder-led को comfortable लगने से ज़्यादा देर तक रखना: VP को playbook exist होने के बाद hire करें, जब वह अभी discover हो रही हो तब नहीं।

RevOps के बिना AI-Augmented Outbound। दल AI tooling से outbound volume 10× scale करता है लेकिन analytics layer में invest नहीं करता जो AI के prompts tune करे, deliverability track करे या response quality measure करे। Result high-volume, low-quality pipeline है जो SDR दल को overwhelm करता है और email service providers के साथ कंपनी की domain reputation damage करता है। Fix है outbound volume scale करने से पहले RevOps stack (Outreach/Salesloft analytics, Gong/Chorus conversation intelligence, deliverability monitoring) में invest करना, बाद में नहीं।

Attribution infrastructure के बिना Pay-Per-Outcome। दल outcome-based pricing ship करता है, pay per resolved ticket, per booked meeting, per processed claim, लेकिन audit-grade telemetry नहीं रखता जो prove कर सके कि कौन से outcomes AI Worker ने produce किए। Customers outcomes dispute करते हैं; seller disputes win नहीं कर सकता; revenue collection quarterly fight बन जाता है। Fix है day one से outcome attribution instrument करना, भले ही pricing का first version seat-based हो। Infrastructure product है, afterthought नहीं।

FDE जो permanent consultancy बन जाता है। दल 1 या 2 strategic accounts पर embedded engineering से शुरू करता है। Custom काम अच्छा pay करता है; दल बढ़ता है; और accounts वही engagement माँगते हैं। 5 years बाद दल profitable है लेकिन हर नया customer अभी भी significant custom काम मांगता है, और जो वे करते हैं उसका productized version कभी ship नहीं होता। Fix है demand करना कि हर engagement कम से कम एक reusable pattern produce करे जो अगले engagement में ship हो, और custom to productized काम ratio को top-level operating metric की तरह track करना।

Partner enablement investment के बिना channel। दल partner program announce करता है, 3 SIs के साथ MOUs sign करता है और channel से revenue की प्रतीक्षा करता है। 6 months बाद कोई deal close नहीं हुआ क्योंकि SIs नहीं जानते कि product को position, demo या implement कैसे करें। Fix है partner enablement, formal training, certification, sales-engineering support, joint case studies, में लगभग direct sales enablement जितनी intensity से invest करना। Partners products नहीं बेचते; partners वह बेचते हैं जो उनके लिए operationally सबसे आसान हो।

Baseline measurement के बिना Value-Based Engagement। दल value-based contract sign करता है, measured productivity gain या cost reduction के percentage के रूप में pricing, लेकिन पहले customer का pre-deployment baseline measure नहीं करता। जब contract measurement period तक पहुँचता है, दोनों parties dispute करती हैं कि baseline क्या था और value-share calculation measurement के बजाय negotiation बन जाता है। Fix है deployment शुरू होने से पहले baseline measurement establish करना, ideally contract structure में paid baseline-measurement period बनाकर।

ये failures खराब दलों के symptoms नहीं हैं। ये ऐसी motions के predictable failure modes हैं जिनकी mechanics अभी widely understood नहीं हैं। उन्हें नाम देना उनके against operate करने का पहला step है।

Catalog का इस्तेमाल कैसे करें

इस दस्तावेज़ को planning tool की तरह पढ़ रहे किसी भी founder या revenue leader के लिए 3 closing instructions।

पहला, अपनी पद्धति का नाम दें। ऊपर की जो भी पद्धति सबसे बेहतर describe करती है कि आप आज deals कैसे close करते हैं, उसे लिखें। अगर आपकी वास्तविक पद्धति hybrid है, Founder-Led with AI-Augmented Outbound layered on top, Enterprise Field with a Channel partnership for one segment, individuals के लिए PLG plus organizations के लिए Enterprise Field, तो दोनों halves का नाम दें और स्पष्ट करें कि कौन सा revenue का bulk produce कर रहा है और कौन सा opportunities का bulk। जो दल अपनी पद्धति को एक sentence में नाम नहीं दे सकते, उनके पास आम तौर पर पद्धति होती ही नहीं।

दूसरा, अपनी motion transitions को पहले से नाम दें। ज़्यादातर सफल AI-native कंपनियाँ scale होते हुए 2 या 3 motions से evolve करती हैं। PLG कंपनियाँ Enterprise Field में graduate करती हैं। Founder-Led, AI-Augmented Outbound में transition करता है। Enterprise Field deals, Trust Ladder चढ़ जाने पर Pay-Per-Outcome तक expand होते हैं। हर transition ऐसा moment है जहाँ दल को पिछले दिन की तुलना में materially different कुछ करना पड़ता है। जो दल transition को पहले से plan करते हैं वे survive करते हैं। जो दल transition पर surprise होते हैं, वे आम तौर पर नहीं करते।

तीसरा, motion-buyer mismatch पर नज़र रखें। AI-native कंपनियों में सबसे common motion failure है सही product को सही buyer को गलत motion से बेचना: AI-curious mid-market buyers पर enterprise field चलाना, cycle बहुत slow है; strategic enterprise buyers पर PLG चलाना, deal size बहुत छोटा है; AI-curious buyers पर outcome pricing चलाना, procurement equipped नहीं है। Motion को buyer से match करें, founder की preference से नहीं।

Thesis agent era की architecture defend करती है। Worker Catalog define करता है कि उसके अंदर क्या बनाया जाता है। Sales, Marketing और Finance Catalogs define करते हैं कि AI-native कंपनी सौदे वास्तव में कैसे बंद करती है, demand कैसे बनाती है और वह economics कैसे चलाती है जो इस सब को sustainable बनाती है। साथ मिलकर ये दस्तावेज़ AI-Native Company का operating manual हैं।

Model commodity है। Harness product है। Strategy कंपनी है। Motion revenue है।

परिशिष्ट A: शब्दावली

यह glossary दस्तावेज़ में इस्तेमाल हर technical, business और revenue-operations term को define करती है। यह alphabetically organized है। हर definition plain language और कम से कम एक concrete example इस्तेमाल करती है।

ABM (Account-Based Marketing)। B2B sales-and-marketing motion जिसमें दल target accounts की finite list चुनता है और हर account के around marketing, sales और customer success orchestrate करता है। $100K ACV से ऊपर deals के लिए common। (Enterprise-field application के लिए पद्धति 7 देखें।)

ACV (Annual Contract Value)। Yearly basis पर customer contract की dollar value। $300K total worth वाले 3-year contract का ACV $100K है।

AI-Augmented Outbound। Vendor-led sales motion जो AI agents का इस्तेमाल scale पर outbound outreach research, draft और follow up करने के लिए करता है। (पद्धति 6 देखें।)

AI-Curious / AI-Piloting / AI-Native। AI procurement में buyer maturity के 3 stages। AI-Curious buyers ने अभी production में AI deploy नहीं किया; AI-Piloting buyers experiments चला चुके हैं; AI-Native buyers AI को core infrastructure मानते हैं। (Buyer Maturity Curve देखें।)

API (Application Programming Interface)। Software के 2 pieces को एक-दूसरे से बात कराने का formal तरीका। AI Workers आम तौर पर APIs के through दूसरे systems से connected होते हैं।

Attribution। यह prove करने की technical process कि specific outcome, resolved ticket या closed deal, किसी specific AI Worker ने produce किया, human या किसी और system ने नहीं। Outcome-based pricing के लिए foundational।

B2B (Business-to-Business)। Products और services जो individual consumers के बजाय दूसरे businesses को बेचे जाते हैं। Salesforce B2B है। Netflix B2C है।

Buyer Maturity Curve। AI-native solutions कैसे खरीदे जाते हैं, इसकी 3-stage progression (AI-Curious, AI-Piloting, AI-Native)। Different motions curve के different stages पर land करते हैं। (ऊपर Buyer maturity and timing खंड देखें।)

CAC (Customer Acquisition Cost)। एक नए paying customer को जीतने के लिए कंपनी कितना money spend करती है। CAC में advertising, बिक्री दल की salaries, sales engineering, free-trial costs और similar expenses शामिल हैं।

CAC Payback Period। नए customer से gross margin को उन्हें acquire करने वाले CAC repay करने में लगने वाले months की संख्या। Healthy SaaS businesses आम तौर पर CAC payback 18 months से नीचे चलाते हैं।

Channel। Third party, value-added reseller, systems integrator या marketplace, जो आपका product end customers को बेचता है। (पद्धति 11 देखें।)

Cycle Length। Buyer के seller से first contact से first deal close होने तक का समय। Cycle length hours (PLG) से 18 months (strategic enterprise) तक vary करता है।

Deal Size। Single closed deal की dollar value। Self-serve deals आम तौर पर <$10K होते हैं; enterprise deals आम तौर पर $100K-1M; strategic deals >$1M।

ESP (Email Service Provider)। Email infrastructure (SendGrid, AWS SES, Postmark) जो scale पर outbound email handle करता है। AI-augmented outbound healthy ESP relationships और deliverability infrastructure पर निर्भर करता है।

FDE (Forward-Deployed Engineering)। Sales motion जिसमें engineers (और AI Workers) customer organization के अंदर embed होते हैं ताकि custom solutions बनाए जाएँ, फिर जो काम करता है उसे productize किया जाए। Palantir ने इसे pioneer किया। (इस catalog में पद्धति 8 देखें।)

Founder-Led Sales। Sales motion जिसमें founder personally पहले 5-50 deals hand-close करता है ताकि बिक्री दल hire करने से पहले playbook सीखी जाए। (पद्धति 5 देखें।)

Free Tier। Product का ऐसा version जो बिना charge available होता है, designed to produce activation, usage और अंततः paid tiers में upgrade। Self-serve PLG की core mechanic। (पद्धति 1 देखें।)

Gross Margin। Revenue minus product deliver करने की direct cost, revenue के percentage के रूप में expressed। SaaS gross margins आम तौर पर 70-85% होते हैं। AI-native gross margins शुरुआती वर्षों में आम तौर पर 50-75% होते हैं, compute costs high होने के कारण, लेकिन scale economics improve होने पर चढ़ते हैं।

Hyperscaler। बड़ा cloud provider, जैसे AWS, Microsoft Azure, Google Cloud, जो massive scale पर global cloud infrastructure operate करता है। Hyperscaler co-sell motions hyperscaler के sales organization के साथ partner करते हैं। (पद्धति 12 देखें।)

Land-and-Expand। Sales strategy जिसमें seller account में छोटा initial deal जीतता है, फिर additional users, products या business units के through account के अंदर expand करता है। Datadog ने 2010s में इस motion को perfect किया।

LTV (Lifetime Value)। Seller के साथ customer relationship की duration में expected total revenue। LTV / CAC ratio core SaaS health metric है; healthy businesses LTV / CAC 3 से ऊपर चलाते हैं।

Marketplace। Platform-operated directory जहाँ third-party software platform के customers को बेचा जाता है। Salesforce AppExchange, Shopify App Store, AWS Marketplace, ChatGPT Apps. (पद्धति 2 देखें।)

MEDDIC / MEDDPICC। Enterprise sales qualification frameworks (Metrics, Economic buyer, Decision criteria, Decision process, Identify pain, Champion; और longer version के लिए Paper process, Competition)। Field-sales motions में common।

Motion। Deals close करने का repeatable, named approach। Self-Serve PLG एक motion है। Enterprise Field Sales एक motion है। इस catalog की 12 motions 2026 में AI-native कंपनियों की सबसे common motions हैं।

MRR / ARR (Monthly / Annual Recurring Revenue)। Predictable recurring subscription revenue, monthly या annually expressed। SaaS businesses के लिए core revenue metric।

NRR (Net Revenue Retention)। Existing customers से revenue का वह percentage जो किसी period में retained, expanded या contracted होता है। 100% से ऊपर NRR का मतलब है existing customers समय के साथ ज़्यादा खर्च कर रहे हैं। 130% से ऊपर NRR category-leading business indicate करता है।

Outcome-Based Pricing। Pricing model जिसमें customer software access के लिए नहीं, results के लिए pay करता है। (पद्धति 9 देखें।)

Pilot। Time-bounded, scope-limited initial deployment जो buyer को production contract commit करने से पहले अपने environment में product validate करने देता है। इस catalog में standalone motion नहीं; pilots Enterprise Field, FDE, AI-Augmented Outbound और Pay-Per-Outcome motions के अंदर typical entry structure हैं। (Cross-cutting concepts में Pilot economics देखें।)

PLG (Product-Led Growth)। Go-to-market motion जिसमें product खुद customer acquisition, conversion और expansion का primary mechanism है। Seller की भूमिका direct outreach के बजाय product-design और frictionless onboarding है। (पद्धति 1 देखें।)

Pipeline। Sales process से flow होते qualified opportunities का collection। Pipeline coverage, pipeline value to revenue target ratio, vendor-led motions के लिए core operating metric है।

Procurement। Formal process जिसके through buyer organization vendor services की purchase approve करता है। Procurement cycles days (PLG, marketplace) या 18 months (strategic enterprise) ले सकते हैं।

Production Contract। Successful pilot के बाद आने वाला long-term commercial contract। Production contracts आम तौर पर preceding pilot के dollar size से 3-10× होते हैं।

Quota। Individual sales rep या दल को assigned annual revenue target। Quotas vendor-led motions के core में हैं; PLG या marketplace-led motions में मौजूद नहीं।

RevOps (Revenue Operations)। Internal function जो revenue motion support करने वाले systems, processes और data के लिए responsible है: CRM administration, sales analytics, forecasting, compensation design, sales enablement। (Cross-cutting concepts में The RevOps stack देखें।)

SaaS (Software as a Service)। Software जिसे एक बार खरीदने के बजाय monthly या annually rent किया जाता है। लगभग 2005 से 2025 तक B2B software के लिए dominant pricing model; AI-native कंपनियों में outcome-based pricing से आंशिक रूप से displaced हो रहा है।

SDR (Sales Development Representative)। Specialized salesperson जो upper sales funnel पर focused होता है: inbound leads qualify करना या outbound outreach produce करना। AI-augmented outbound SDR काम को increasingly automate कर रहा है।

Seat-Based Pricing। Pricing model जिसमें customer per user (seat) per period pay करता है, आम तौर पर per month या per year। SaaS के लिए standard; AI-native कंपनियों में outcome-based pricing से आंशिक रूप से displaced हो रहा है।

Self-Serve। Sales motion जिसमें buyer direct seller interaction के बिना sign up, evaluate और purchase करता है। Most usage में PLG का synonym। (पद्धति 1 देखें।)

SI (Systems Integrator)। Consulting firm जो enterprise customers के लिए technology implement करती है: typical examples Accenture, Deloitte, IBM Global Services, Slalom, Capgemini। SI partnerships enterprise AI deployments में channel motions के core में हैं। (पद्धति 11 देखें।)

Service-as-Software। Pricing model जिसमें seller software seats के बजाय outcomes, resolved tickets, drafted documents, processed claims, के लिए charge करता है। (इस catalog में पद्धति 9 देखें।)

Trust Ladder। AI Workers के लिए 3-stage maturity curve: co-pilot (AI suggest करता है, human हर action approve करता है), supervised autonomous (AI defined task type पर act करता है, human aggregate output review करता है), full autopilot (AI per-task supervision के बिना act करता है)। Pricing models ladder को track करते हैं।

Value-Based Pricing। Pricing model जिसमें deal size customer के measurable economic outcome के percentage के रूप में set होता है। (पद्धति 10 देखें।)

Vendor-Led Motion। Sales motion जिसमें seller deal शुरू और orchestrate करता है। Buyer-led motions से contrast करता है, जहाँ buyer cycle drive करता है। (खंड B: Vendor-led motions, पद्धतियाँ 5-8 देखें।)

नोट्स

¹ Wes Bush, Product-Led Growth: How to Build a Product That Sells Itself, ProductLed Press, 2019। PLG motion पर standard text। Bush का framework, खास तौर पर "free trial" और "freemium" के बीच distinction को 2 different PLG strategies के रूप में रखना, पद्धति 1 के लिए foundational है।

² Mark Roberge, The Sales Acceleration Formula: Using Data, Technology, and Inbound Selling to go from $0 to $100 Million, Wiley, 2015। Founder-led से repeatable motion तक HubSpot की sales engine बनाने पर Roberge का account founder-led-to-vendor-led transition के लिए standard reference है। पद्धति 5 और Common Hybrid Motions का framework Roberge की stage analysis पर draw करता है।

³ Aaron Ross और Marylou Tyler, Predictable Revenue: Turn Your Business into a Sales Machine with the $100 Million Best Practices of Salesforce.com, PebbleStorm, 2011। Salesforce के 2000s playbook पर लिखी Ross की SDR-driven outbound motion की articulation outbound motion के pre-AI version को define करती है जिसे पद्धति 6 evolve करती है। AI-augmented outbound Ross द्वारा documented funnel structure और operating cadence inherit करता है, जबकि human-SDR research और drafting काम को AI agents से replace करता है।

⁴ Jacco van der Kooij, Blueprints for a SaaS Sales Organization: How to Design, Build and Scale a Customer-Centric Sales Organization, Winning by Design, 2018। Enterprise sales organization design के लिए Van der Kooij के frameworks, खास तौर पर AE, SE और customer success के बीच role specialization, पद्धति 7 में enterprise field motion के लिए widely-adopted templates हैं।

⁵ Sangram Vajre और Eric Spett, ABM is B2B: Why B2B Marketing and Sales is Broken and How to Fix It, IdeaPress Publishing, 2019। Enterprise motion के रूप में Account-Based Marketing पर standard text। Named accounts की finite list के around marketing, sales और customer success orchestrate करने पर Vajre और Spett का framework इस catalog की vendor-led motions को inform करता है और पद्धति 7 के ABM half के नीचे explicitly है।

⁶ McKinsey Global Institute, "Generative AI की economic potential: productivity की अगली frontier", June 2023। McKinsey की bottom-up analysis estimate करती है कि generative AI enterprise functions में annual productivity gains में trillions contribute कर सकता है, जिसका सबसे बड़ा impact customer operations, sales, marketing, software engineering और R&D में concentrated है। Outcome-based pricing (पद्धति 9) और value-based engagement (पद्धति 10) के नीचे labor-budget argument इन estimates पर draw करता है।

⁷ Tien Tzuo और Gabe Weisert, Subscribed: Why the Subscription Model Will Be Your Company's Future — And What to Do About It, Portfolio, 2018। Subscription business mechanics पर Tzuo का framework, खास तौर पर net revenue retention को core operating metric मानना, SaaS motions के लिए foundational है और इस catalog में NRR की discussion को inform करता है।

यह दस्तावेज़ कहाँ फिट होता है​

इस दस्तावेज़ को कैसे पढ़ें​

शुरुआती पाठक के लिए 10 मिनट वाला संस्करण​

कार्यकारी सारांश​

यह पृष्ठ किसलिए है​

पद्धति कैसे चुनें​

विक्रेता diagnostic: 8 सवाल​

पद्धतियों की summary table​

मुझे कौन सी पद्धति अपनानी चाहिए?​

Buyer maturity और timing​

परिपक्वता legend​

A. खरीदार-नेतृत्व वाली पद्धतियाँ​

पद्धति 1: Self-Serve PLG (Product-Led Growth)​

पद्धति 2: Marketplace-Led​

पद्धति 3: Open-Source-Led​

पद्धति 4: Community-Led​

B. विक्रेता-नेतृत्व वाली पद्धतियाँ​

पद्धति 5: Founder-Led Sales​

पद्धति 6: AI-Augmented Outbound​

पद्धति 7: Enterprise Field Sales​

पद्धति 8: Forward-Deployed Engineering (FDE)​

C. परिणाम-नेतृत्व वाली पद्धतियाँ​

पद्धति 9: Pay-Per-Outcome (Service-as-Software)​

पद्धति 10: Value-Based Engagement​

D. साझेदार-नेतृत्व वाली पद्धतियाँ​

पद्धति 11: Channel & SI Partnership​

पद्धति 12: Hyperscaler Co-Sell​

सभी पद्धतियों में आने वाले concepts​

AI हर पद्धति में क्या बदलता है​

Common hybrid motions​

Common motion failures​

Catalog का इस्तेमाल कैसे करें​

परिशिष्ट A: शब्दावली​

नोट्स​

यह दस्तावेज़ कहाँ फिट होता है

इस दस्तावेज़ को कैसे पढ़ें

शुरुआती पाठक के लिए 10 मिनट वाला संस्करण

कार्यकारी सारांश

यह पृष्ठ किसलिए है

पद्धति कैसे चुनें

विक्रेता diagnostic: 8 सवाल

पद्धतियों की summary table

मुझे कौन सी पद्धति अपनानी चाहिए?

Buyer maturity और timing

परिपक्वता legend

A. खरीदार-नेतृत्व वाली पद्धतियाँ

पद्धति 1: Self-Serve PLG (Product-Led Growth)

पद्धति 2: Marketplace-Led

पद्धति 3: Open-Source-Led

पद्धति 4: Community-Led

B. विक्रेता-नेतृत्व वाली पद्धतियाँ

पद्धति 5: Founder-Led Sales

पद्धति 6: AI-Augmented Outbound

पद्धति 7: Enterprise Field Sales

पद्धति 8: Forward-Deployed Engineering (FDE)

C. परिणाम-नेतृत्व वाली पद्धतियाँ

पद्धति 9: Pay-Per-Outcome (Service-as-Software)

पद्धति 10: Value-Based Engagement

D. साझेदार-नेतृत्व वाली पद्धतियाँ

पद्धति 11: Channel & SI Partnership

पद्धति 12: Hyperscaler Co-Sell

सभी पद्धतियों में आने वाले concepts

AI हर पद्धति में क्या बदलता है

Common hybrid motions

Common motion failures

Catalog का इस्तेमाल कैसे करें

परिशिष्ट A: शब्दावली

नोट्स