सेल्स टीमों के लिए कॉम्पिटिटिव इंटेलिजेंस पर प्रोग्राम संचालकों की गाइड: PMM, RevOps और एनेबलमेंट के बीच ज़िम्मेदारियों का बँटवारा, इस्तेमाल बढ़ाने वाला AI-असिस्टेंट डिलीवरी चैनल, और प्रोग्राम की सफलता साबित करने वाले मेट्रिक्स।
अगर आप सेल्स-CI प्रोग्राम चलाते हैं, तो आपके पाठक और आपके खरीदार एक जैसे नहीं हैं। यह लेख आप पढ़ रहे हैं। अपने सेल्स प्रतिनिधियों को ध्यान में रखकर आप प्रोग्राम कैसे डिज़ाइन करते हैं, उसका असर वे झेलते हैं। "सेल्स के लिए कॉम्पिटिटिव इंटेलिजेंस" पर ज़्यादातर सामग्री ऐसे लिखी जाती है जैसे उसके पाठक सेल्स प्रतिनिधि हों। ऐसा नहीं है। वे आपके बनाए प्रोग्राम के उपयोगकर्ता हैं, और वे उसका इस्तेमाल करेंगे या नहीं, यह ऐसे फ़ैसलों पर निर्भर करता है जो किसी भी बैटल कार्ड के बनने से बहुत पहले लिए जाते हैं।
यह संस्करण प्रोग्राम संचालकों के लिए है। यह RevOps, सेल्स एनेबलमेंट और सेल्स लीडरशिप के लिए है, जिन्हें तय करना है कि किसकी क्या ज़िम्मेदारी होगी, कौन-सा डिलीवरी चैनल डील के दौरान प्रतिनिधियों तक वास्तव में पहुँचता है, और किन मेट्रिक्स से पता चलता है कि सिस्टम काम कर रहा है या नहीं। इस विषय के समग्र परिचय के लिए कॉम्पिटिटिव इंटेलिजेंस का मुख्य लेख पढ़ें। PMM की ओर से शुरुआती तैयारी का नज़रिया जानने के लिए प्रोडक्ट मार्केटिंग मैनेजरों के लिए कॉम्पिटिटिव इंटेलिजेंस देखें।
सेल्स-CI प्रोग्राम की विफलता का सबसे आम कारण ज़िम्मेदारियों का स्पष्ट न होना है। CRO इसे प्रायोजित करता है क्योंकि बोर्ड ने ऐसा करने को कहा। PMM को बैटल कार्ड की ज़िम्मेदारी दे दी जाती है क्योंकि वह "मैसेजिंग के सबसे करीब" है। नाम के लिए प्रतिनिधि इसके लक्षित उपयोगकर्ता होते हैं, लेकिन फ़ॉर्मैट पर उनकी राय कभी नहीं ली जाती। छह महीने बाद प्रोग्राम ठप पड़ जाता है और किसी को पता नहीं होता कि यह किसकी समस्या है।
काम करने वाला प्रोग्राम ज़िम्मेदारी के चार क्षेत्रों को स्पष्ट रूप से तय करता है।
| विभाग | उनकी ज़िम्मेदारी | उनकी ज़िम्मेदारी में क्या नहीं है |
|---|---|---|
| प्रोडक्ट मार्केटिंग (PMM) | बैटल कार्ड की सामग्री, हर प्रतिस्पर्धी के लिए पोज़िशनिंग का आधार, प्रासंगिक संकेतों की परिभाषा, प्रतिस्पर्धी के लॉन्च के जवाब में मैसेजिंग | CRM डेटा की साफ़-सफ़ाई, प्रतिनिधियों में इस्तेमाल बढ़ाने की प्रक्रियाएँ, जीत-हार डेटा दर्ज करना |
| RevOps / सेल्स ऑप्स | CRM फ़ील्ड (डील बंद होते समय प्रतिस्पर्धी, डील के चरण की टैगिंग), डेटा रूटिंग, इंटीग्रेशन की बुनियादी व्यवस्था (Gong से CRM, MCP फ़ीड), टूल संबंधी फ़ैसले | बैटल कार्ड की शब्दावली, पोज़िशनिंग की कहानी |
| सेल्स एनेबलमेंट | CI प्रोग्राम में ऑनबोर्डिंग, इस्तेमाल बढ़ाने के लिए कोचिंग, प्रशिक्षण का नियमित क्रम, डील से जुड़े CI परामर्श सत्र | रणनीतिक पोज़िशनिंग, शीर्ष स्तर के मेट्रिक्स की परिभाषा |
| सेल्स लीडरशिप (VP / CRO) | जीत-हार की मासिक समीक्षा, कार्यकारी स्तर पर समर्थन, इस्तेमाल रुकने पर हस्तक्षेप, प्रोग्राम में बदलाव शुरू कराने वाला मेट्रिक | रोज़मर्रा की सामग्री तैयार करना |
बड़े संगठनों में यह बँटवारा आम तौर पर पहले से होता है और छोटे संगठनों को इसे जानबूझकर करना पड़ता है। 15 लोगों की GTM टीम में भी चारों भूमिकाएँ तय होनी चाहिए, भले ही एक व्यक्ति दो भूमिकाएँ निभाए। ज़िम्मेदारी स्पष्ट करना ज़रूरी है; अस्पष्टता ही प्रोग्राम को डुबोती है।
यह जाँचने का एक ठोस तरीका कि बँटवारा काम कर रहा है या नहीं: जब कोई प्रतिस्पर्धी मंगलवार दोपहर नया प्राइसिंग टियर जारी करता है, तो बैटल कार्ड कौन अपडेट करता है, उस प्रतिस्पर्धी के ख़िलाफ़ सक्रिय डील पर काम कर रहे प्रतिनिधियों के लिए Slack अलर्ट कौन भेजता है, कौन पुष्टि करता है कि प्रतिनिधियों ने उसे देख लिया है, और अगले महीने की कार्यकारी समीक्षा में इस प्रक्रिया को पूरा कौन करता है? अगर इन चार सवालों के जवाब में चार अलग-अलग लोगों के नाम आते हैं, तो प्रोग्राम सही चल रहा है। अगर तीन के जवाब में "शायद PMM?" आता है, तो ऐसा नहीं है।
प्रतिनिधि को जवाब चाहिए, दस्तावेज़ नहीं। प्रोग्राम डिज़ाइन की पूरी समस्या एक वाक्य में यही है।
डील के चक्र में तीन मौक़ों पर CI का ज़्यादातर वास्तविक इस्तेमाल होता है।
कॉल से पहले की ज़रूरत मौजूदा माध्यमों से अच्छी तरह पूरी हो जाती है। प्रतिनिधि संभावित ग्राहक का टेक स्टैक देखते हैं, बैटल कार्ड पर नज़र डालते हैं और प्रतिस्पर्धा से जुड़ी संभावित स्थितियों की तैयारी करते हैं। उनके पास समय होता है, उनके हाथ खाली होते हैं, सामग्री पाँच पैराग्राफ़ की भी हो सकती है। ज़्यादातर CI प्रोग्राम इस मौक़े की ज़रूरत ठीक से पूरी करते हैं।
कॉल के दौरान ही इस्तेमाल की प्रक्रिया टूट जाती है। प्रतिनिधि को संभावित ग्राहक के दो सवालों के बीच एक खास जवाब चाहिए होता है। वह 6 ब्लॉक वाला Notion पेज नहीं खोल सकता। Zoom पर सामने वाले से नज़रें हटाए बिना नया टैब खोलना भी मुश्किल है। अगर जवाब तीन सेकंड में नहीं मिलता, तो वह अपने हिसाब से जवाब बना लेता है। इस मौक़े के लिए आप जो भी उपलब्ध कराएँ, अगर उसे देखने के लिए अलग UI खोलना पड़ता है, तो उसका होना और न होना बराबर है।
कॉल के बाद प्रतिनिधियों की बारी होती है कि वे प्रोग्राम को कुछ वापस दें। डील जीती हो या हारी हो, डील नोट में दर्ज होना चाहिए कि प्रतिस्पर्धी ने क्या किया या कहा। ज़्यादातर प्रोग्राम यह डेटा ठीक से नहीं जुटा पाते, क्योंकि फ़ील्ड वैकल्पिक होती है, उसे भरने का निर्देश कहीं दबा होता है, और प्रतिनिधियों को उसे भरने के बदले कोई फ़ायदा दिखाई नहीं देता।
अगर आप केवल कॉल से पहले की ज़रूरत के लिए डिज़ाइन करते हैं, तो बैटल कार्ड की संख्या बढ़ती है और जीत की दर जस की तस रहती है। अगर आप कॉल के दौरान की ज़रूरत के लिए डिज़ाइन करते हैं, तो आपको ऐसा डिलीवरी आर्किटेक्चर बनाना पड़ेगा जो ज़्यादातर प्रोग्रामों की व्यवस्था से बहुत अलग होगा।
ज़्यादातर असफल सेल्स-CI प्रोग्रामों में सामग्री भरपूर होती है, लेकिन उसे पहुँचाने की व्यवस्था कमज़ोर होती है। PMM ने बेहतरीन बैटल कार्ड लिखे। प्रतिनिधि उन्हें खोलते ही नहीं। दोनों बातें एक साथ सच हो सकती हैं, और जब प्रोग्राम संचालक पूछता है कि "हम अपने बैटल कार्ड बेहतर कैसे बनाएँ?", तो वह ग़लत सवाल पूछ रहा होता है।
सही सवाल है: जब किसी प्रतिनिधि को डील के दौरान प्रतिस्पर्धा से जुड़ा कोई खास जवाब चाहिए, तो कौन-सा माध्यम उसे वह जवाब देगा?
डिलीवरी के चार तरीके स्थिर दस्तावेज़ से बेहतर काम करते हैं। ये एक-दूसरे की जगह लेने के बजाय साथ मिलकर काम करते हैं।
CRM में एम्बेड की गई बैटल कार्ड टाइलें प्रतिस्पर्धा से जुड़ी दो या तीन सबसे ताज़ा बातें सीधे ऑपर्च्युनिटी रिकॉर्ड पर दिखाती हैं, जिन्हें डील बंद होते समय के प्रतिस्पर्धी के आधार पर टैग किया जाता है। प्रतिनिधि पहले से CRM में काम कर रहा होता है; सामग्री उसे वहीं मिल जाती है। Klue, Crayon और सेल्स टीम के ज़रिए बिकने वाले ज़्यादातर सुइट इसी पर ध्यान केंद्रित करते हैं, और लगभग 10 से ज़्यादा प्रतिनिधियों वाले किसी भी प्रोग्राम के लिए यह बुनियादी ज़रूरत है।
हर प्राथमिकता वाले प्रतिस्पर्धी के लिए Slack चैनल प्रोग्राम को लगातार अपडेट होने वाली फ़ीड बना देते हैं। Meta Ad Library में दिखा नया विज्ञापन क्रिएटिव, प्रतिस्पर्धी की साइट पर नया प्राइसिंग टियर, उसके ख़िलाफ़ किसी डील की जीत-हार पर ताज़ा चर्चा। कोई भी महत्वपूर्ण बात एक समर्पित चैनल में पोस्ट होती है, जिसे रुचि रखने वाले प्रतिनिधि डिफ़ॉल्ट रूप से म्यूट रखते हैं और ज़रूरत पड़ने पर खोजते हैं।
Gong (या कोई भी कॉल-इंटेलिजेंस टूल) CI को बातचीत वाले माध्यम में वापस लाता है। कॉल में किसी प्रतिस्पर्धी का नाम मिलने पर, प्रतिनिधि को बाद में कॉल की समीक्षा के दौरान उसी जगह संबंधित बैटल कार्ड का अंश दिखाई देता है। कुछ प्लेटफ़ॉर्म कॉल के दौरान भी यह जानकारी रीयल टाइम में दिखाते हैं।
MCP या API के ज़रिए AI असिस्टेंट वह चैनल है जिसे ज़्यादातर टीमों ने अभी नहीं बनाया है और जहाँ अगले दो वर्षों में अतिरिक्त मूल्य मिलने की सबसे ज़्यादा संभावना है। कॉल के बीच प्रतिनिधि अपने आंतरिक कोपायलट या सेल्स असिस्टेंट से पूछता है, "अगर वे Enterprise टियर पर Klue को तरजीह दें, तो प्राइसिंग पर हमारा जवाब क्या होगा?" और उसे उसी बैटल कार्ड डेटा से निकाला गया स्पष्ट जवाब मिलता है। यह तभी काम करता है जब बैटल कार्ड की सामग्री मशीन द्वारा पढ़े जा सकने वाले स्ट्रक्चर्ड डेटा के रूप में हो, PDF में नहीं। MCP एंडपॉइंट या स्थिर API वह तय इंटरफ़ेस है जिससे प्रतिनिधि के स्टैक में मौजूद हर असिस्टेंट एक ही प्रामाणिक स्रोत से जानकारी माँग सकता है।
मैनेजर को संदेश भेजना मानवीय बैकअप है। जब बाकी सब विफल हो जाता है, तो प्रतिनिधि अपने मैनेजर को संदेश भेजता है। अच्छा प्रोग्राम मैनेजर से जवाब माँगने के पैटर्न को इस संकेत की तरह देखता है कि पहले के माध्यम ज़रूरत पूरी नहीं कर पाए, और वहाँ से पीछे जाकर कमी दूर करता है।
AI-असिस्टेंट चैनल पर अलग से चर्चा ज़रूरी है, क्योंकि यह बाकी तीन तरीकों के मुकाबले प्रोग्राम डिज़ाइन के समीकरण को ज़्यादा बदलता है।
प्रतिनिधि पढ़ते नहीं हैं। लेकिन वे सवाल ज़रूर पूछेंगे। उनके लैपटॉप या CRM में आंतरिक कोपायलट आ जाने पर, "सुरक्षा के मामले में Klue की कमज़ोरी उजागर करने वाला सवाल क्या है?" पूछना संभावित ग्राहकों के दो ईमेल के बीच 4 सेकंड का काम बन जाता है। इससे जानकारी पाने के लिए टैब खोलने की जगह सिर्फ़ एक वाक्य टाइप करना पड़ता है, और जिन टीमों ने यह व्यवस्था जोड़ी है उनमें CI का इस्तेमाल लगभग दस गुना बढ़ जाता है।
प्रोग्राम संचालक के लिए इससे आर्किटेक्चर के तीन फ़ैसले निकलते हैं।
बैटल कार्ड की सामग्री स्ट्रक्चर्ड डेटा के रूप में होनी चाहिए। फ़ील्ड, टैग, स्रोत URL, आख़िरी अपडेट के टाइमस्टैम्प। PDF के पैराग्राफ़ के रूप में नहीं। शेयर किए गए ड्राइव पर Word दस्तावेज़ के रूप में नहीं। यही फ़ॉर्मैट वह तय व्यवस्था है जिससे AI असिस्टेंट भरोसेमंद ढंग से जानकारी ढूँढ़कर जवाब तैयार कर सकता है।
जानकारी प्राप्त करने का इंटरफ़ेस होना चाहिए। या तो MCP एंडपॉइंट (AI-नेटिव टीमों के लिए सबसे सीधा विकल्प) या ऐसा API जिसे आंतरिक कोपायलट कॉल कर सकें। कई AI-नेटिव CI वर्कस्पेस (Watchr सहित) यह सीधे उपलब्ध कराते हैं। सेल्स टीम के ज़रिए बिकने वाले सुइट भी इसे अलग-अलग हद तक उपलब्ध कराने की दिशा में बढ़ रहे हैं।
असिस्टेंट की पूरी श्रृंखला को इसका इस्तेमाल करने की अनुमति मिलनी चाहिए। यहीं ज़्यादातर प्रोग्राम गैर-तकनीकी वजहों से अटकते हैं। सुरक्षा और IT टीमों को कनेक्शन की मंज़ूरी देनी होती है। सेल्स एनेबलमेंट को प्रतिनिधियों को सिखाना होता है कि "अपने कोपायलट से पूछें" अब प्लेबुक में दर्ज एक चरण है। दोनों के बिना चैनल तकनीकी रूप से मौजूद रहता है, लेकिन इस्तेमाल नहीं होता।
जो टीमें इसे शुरू से अंत तक जोड़ देती हैं, वे 2026 में सेल्स-CI के किसी भी माध्यम के मुकाबले इस्तेमाल में सबसे तेज़ बढ़ोतरी देखती हैं। इसकी वजह यह नहीं कि AI कोई जादू है। वजह यह है कि आख़िरकार सवाल पूछने में, उसका जवाब खोजने से कम मेहनत लगती है।
ज़्यादातर सेल्स संगठनों में जीत-हार विश्लेषण CI के सबसे कम आँके गए इनपुट में से है, और इसे सुधारना सबसे आसान भी है। समस्या संरचनात्मक है: डेटा बातचीत में रहता है, फ़ील्ड में नहीं, और बातचीत को अपने-आप समेकित नहीं किया जा सकता।
संरचनात्मक सुधार की ज़िम्मेदारी RevOps की है। निष्कर्ष निकालने की ज़िम्मेदारी PMM की है।
सुधार के तीन हिस्से हैं।
हर हारी हुई ऑपर्च्युनिटी पर डील बंद होते समय प्रतिस्पर्धी के लिए एक अनिवार्य CRM फ़ील्ड, जिसमें स्पष्ट ड्रॉपडाउन और "अन्य" का विकल्प हो। ख़राब ड्रॉपडाउन प्रतिनिधियों को टाइप करने पर मजबूर करते हैं, टाइप किए गए डेटा में असंगति होती है, और यह असंगति आगे के विश्लेषण को बेकार कर देती है।
सिर्फ़ समेकित रिपोर्ट के बजाय व्यवस्थित सैंपलिंग। RevOps हर महीने प्रतिस्पर्धा में हारी हुई 15 से 20 डील के नोट निकालता है और उन्हें पढ़ने के लिए PMM तक पहुँचाता है। छोटे सैंपल में ऐसे पैटर्न उभरते हैं जो डैशबोर्ड में ग़ायब हो जाते हैं। डैशबोर्ड बताता है कि पिछली तिमाही में आप Crayon से 14 डील हारे; डील नोट पढ़ने पर पता चलता है कि वे सभी इम्प्लीमेंटेशन में लगने वाले समय से जुड़ी एक खास आपत्ति की वजह से हारे थे।
नियमित समीक्षा चर्चा, जिसमें कम-से-कम डील बंद करने वाला प्रतिनिधि हो, और बेहतर होगा कि संभावित ग्राहक भी शामिल हो। डील हारकर बंद होने के 48 घंटे बाद प्रतिनिधि से 15 मिनट की बातचीत भी ऐसी जानकारी देती है जो CRM नोट में दर्ज नहीं हुई थी। जो प्रोग्राम इसे डील हारकर बंद होने के वर्कफ़्लो में जोड़ते हैं (चरण बदलने पर कैलेंडर आमंत्रण भेजकर), उन्हें डेटा मिलता है; जो प्रतिनिधियों के स्वेच्छा से जानकारी देने का इंतज़ार करते हैं, उन्हें नहीं मिलता।
फ़ीडबैक लूप तब पूरा होता है जब निष्कर्ष अपडेट किए गए बैटल कार्ड, प्रतिस्पर्धी की कमज़ोरी उजागर करने वाले नए सवालों और संबंधित प्रतिस्पर्धी चैनल में बदलावों का सार बताने वाले Slack संदेश के रूप में प्रतिनिधियों तक वापस पहुँचते हैं। अगर लूप पूरा नहीं होता, तो प्रतिनिधि जानकारी देना बंद कर देते हैं, क्योंकि उन्हें डेटा दर्ज करने का कोई फ़ायदा नहीं दिखता। डेटा संबंधी अनुशासन RevOps की ज़िम्मेदारी है; निष्कर्ष वापस पहुँचाने की ज़िम्मेदारी PMM की है।
सेल्स-CI टूल की दुनिया चार परतों में बँटी है। ज़्यादातर परिपक्व प्रोग्राम एक साथ कई परतों का इस्तेमाल करते हैं, क्योंकि वे अलग-अलग समस्याएँ हल करती हैं।
| परत | उदाहरण | क्या हल करती है | किस चरण के लिए उपयुक्त |
|---|---|---|---|
| सेल्स टीम के ज़रिए बिकने वाला CI सुइट | Klue, Crayon, Kompyte | बैटल कार्ड तैयार करना, CRM में एम्बेड करके पहुँचाना, कभी-कभी एकीकृत जीत-हार विश्लेषण | मिड-मार्केट और उससे ऊपर, जहाँ रेवेन्यू ऑप्स का बुनियादी ढाँचा हो |
| कॉल इंटेलिजेंस | Gong, Clari, Avoma | कॉल में प्रतिस्पर्धियों के उल्लेख पहचानना, उसी जगह संबंधित CI दिखाना | रिकॉर्ड की जाने वाली कॉल पर काम करने वाले >20 प्रतिनिधियों की कोई भी टीम |
| AI-नेटिव CI वर्कस्पेस | Watchr, नए प्रदाता | हर प्रतिस्पर्धी के लिए प्रासंगिकता परखने वाला प्रॉम्प्ट, MCP से पढ़ी जा सकने वाली फ़ीड, कम सेटअप लागत | SMB से मिड-मार्केट तक, AI की मदद से काम करने वाली टीमें |
| बदलाव पहचानने वाले / खास काम के टूल | Visualping, Wachete, ऐड-लाइब्रेरी रैपर | प्रतिस्पर्धियों के माध्यमों से बिना छँटे संकेत जुटाना | किसी भी चरण में; आम तौर पर एक घटक के रूप में |
मिड-मार्केट और एंटरप्राइज़ प्रोग्रामों के केंद्र में सेल्स टीम के ज़रिए बिकने वाले सुइट होते हैं, क्योंकि इनमें CRM में एम्बेड किए गए बैटल कार्ड की डिलीवरी पहले से उपलब्ध होती है, जो डील के दौरान इस्तेमाल के लिए सबसे ज़्यादा फ़ायदा देने वाला माध्यम है। Klue रेवेन्यू वर्कफ़्लो के साथ सबसे अधिक एकीकृत है। वेब पर बदलाव पहचानने के क्षेत्र में Crayon का अनुभव सबसे लंबा है। Kompyte इन दोनों के बीच आता है और सोशल तथा विज्ञापन निगरानी में अधिक मज़बूत है। तीनों की कीमतें एंटरप्राइज़ स्तर की हैं और अनुबंध सालाना होते हैं; इन्हें संभालने के लिए रेवेन्यू ऑप्स स्टाफ़ न रखने वाली टीमों के लिए इन्हें लागू करना भारी काम है।
कॉल इंटेलिजेंस प्लेटफ़ॉर्म अपने-आप में CI का माध्यम बनते जा रहे हैं। कॉल में प्रतिस्पर्धियों के उल्लेख पहचानने और कॉल समीक्षा के दौरान संबंधित बैटल कार्ड का अंश दिखाने की Gong की क्षमता, संदर्भ के भीतर मिलने वाले उन कुछ CI अनुभवों में से है जिन्हें प्रतिनिधि बिना याद दिलाए इस्तेमाल करते हैं। अगर आप पहले से Gong या ऐसा ही कोई टूल इस्तेमाल करते हैं, तो कुछ और ख़रीदने से पहले पूछें कि आपके मौजूदा टियर में कौन-से CI फ़ीचर मिलते हैं।
AI-नेटिव CI वर्कस्पेस नई श्रेणी हैं, जो नियम-आधारित फ़िल्टर के बजाय हर प्रतिस्पर्धी के लिए प्रासंगिकता परखने वाले LLM प्रॉम्प्ट पर आधारित हैं। इनमें MCP से पढ़ी जा सकने वाली डिलीवरी होती है, जिससे AI असिस्टेंट सीधे छाँटी गई प्रासंगिक इंटेलिजेंस से जानकारी माँग सकते हैं। ये उन SMB और मिड-मार्केट सेल्स संगठनों के लिए उपयुक्त हैं जिनके पास एंटरप्राइज़ CI का बजट नहीं है और जो AI की मदद से चलने वाले आंतरिक वर्कफ़्लो बना रहे हैं। 10 से 30 प्रतिनिधियों वाले संगठन के लिए सेल्फ़-सर्व प्राइसिंग, ख़रीद पर सहमति जुटाने के समीकरण को काफ़ी बदल देती है।
बदलाव पहचानने वाले और खास काम के टूल ऊपर दिए गए किसी भी विकल्प के नीचे बिना छँटे संकेत जुटाने वाली परत के रूप में काम आते हैं। काम करने वाला प्रोग्राम शायद ही केवल खास काम के टूल पर चलता हो, क्योंकि उनमें प्रासंगिकता परखने की परत नहीं होती; प्रतिनिधियों तक पहुँचने वाले संकेतों में उपयोगी जानकारी का अनुपात बहुत कम बना रहता है।
ज़्यादातर सेल्स-CI प्रोग्राम ग़लत मेट्रिक्स की रिपोर्ट देते हैं। "इस तिमाही प्रकाशित किए गए बैटल कार्ड" सिर्फ़ दिखावे का आँकड़ा है। "प्रतिस्पर्धी पोज़िशनिंग पर प्रशिक्षित प्रतिनिधि" प्रशिक्षण का KPI है, प्रोग्राम की स्थिति का नहीं। पाँच मेट्रिक्स का प्रोग्राम की प्रभावशीलता से वास्तव में संबंध होता है।
| मेट्रिक | परिभाषा | आवृत्ति | ज़िम्मेदारी |
|---|---|---|---|
| प्रतिस्पर्धी डील में जीत की दर | उन ऑपर्च्युनिटी में जीत की दर जहाँ डील में शामिल प्रतिस्पर्धी को टैग किया गया था | मासिक | सेल्स लीडरशिप समीक्षा करती है; RevOps दर्ज करता है |
| बैटल कार्ड कितने अपडेटेड हैं | सक्रिय बैटल कार्डों में आख़िरी अपडेट के बाद बीते दिनों की माध्यिका | साप्ताहिक | PMM की ज़िम्मेदारी; RevOps डैशबोर्ड में दिखाता है |
| AI असिस्टेंट से पूछे गए CI सवालों की संख्या | प्रतिनिधियों द्वारा हर हफ़्ते आंतरिक असिस्टेंट से पूछे गए CI-संबंधी सवालों की संख्या | साप्ताहिक | एनेबलमेंट समीक्षा करता है; RevOps ट्रैकिंग की व्यवस्था करता है |
| जीत-हार डेटा दर्ज करने की दर | हारकर बंद हुई उन डील का प्रतिशत जिनमें डील बंद होते समय प्रतिस्पर्धी फ़ील्ड भरी हो और डील नोट मौजूद हो | मासिक | RevOps की ज़िम्मेदारी |
| प्रतिस्पर्धी के कदम के बाद अपडेट करने में लगा समय | प्रतिस्पर्धी के किसी महत्वपूर्ण कदम (प्राइसिंग टियर में बदलाव, लॉन्च) और उसके बैटल कार्ड में दिखने के बीच के घंटे | हर घटना पर | PMM की ज़िम्मेदारी; एनेबलमेंट जाँच करता है |
पाँचों में दो सिद्धांत समान हैं। ये सभी इस्तेमाल और ताज़ा जानकारी पर केंद्रित हैं, सामग्री बनाने पर नहीं। और ये सभी प्रतिस्पर्धी डील में जीत की दर के अग्रिम संकेतक हैं, बाद में दिखाने वाली उपलब्धियाँ नहीं। मापने का मकसद यह पहचानना है कि प्रोग्राम का कौन-सा माध्यम ज़रूरत पूरी नहीं कर पा रहा, केवल प्रोग्राम के मौजूद होने का जश्न मनाना नहीं।
जो प्रोग्राम अपडेटेड जानकारी, सवालों की संख्या और डेटा दर्ज करने की दर पर अच्छे मानक हासिल करते हैं, उनमें आम तौर पर दो से तीन तिमाहियों में प्रतिस्पर्धी डील की जीत की दर 4 से 8 अंक बढ़ती है। जो ऐसा नहीं करते, वे सामग्री में निवेश के बावजूद अक्सर ठहर जाते हैं या पीछे जाते हैं।
टीम का आकार चाहे जो हो, पाँच बार-बार दिखने वाले पैटर्न प्रोग्राम की विफलता का संकेत देते हैं।
बैटल कार्ड को PDF बनाने का ग़लत तरीका। ख़ूबसूरती से डिज़ाइन किया गया PDF, तिमाही की शुरुआत में जारी हुआ, दो बार खुला और फिर भुला दिया गया। PDF स्थिर होते हैं, AI असिस्टेंट उनमें खोज नहीं कर सकते, कोई भी उनमें grep से खोज नहीं कर सकता, और वे उस CRM माध्यम से कटे रहते हैं जहाँ प्रतिनिधि काम करते हैं। अगर आपका प्रोग्राम PDF जारी करता है, तो अगला बदलाव उन्हें हटाना है।
एक ही प्रामाणिक स्रोत से सब हल हो जाने की कल्पना। यह मानना कि "अगर हम सब कुछ बस एक टूल में समेट दें, तो प्रतिनिधि उसका इस्तेमाल करेंगे।" प्रतिनिधि रोज़ 5 से 8 माध्यमों में काम करते हैं। CI को उन्हीं माध्यमों में उन तक पहुँचना चाहिए, उन्हें छठे में खींचना नहीं चाहिए। कई माध्यमों से डिलीवरी बिखराव नहीं है; यही एक काम करने वाला मॉडल है।
PMM पर सब कुछ डालने का तरीका। जब PMM को एक साथ सामग्री, डेटा जुटाने, रूटिंग और इस्तेमाल बढ़ाने की ज़िम्मेदारी दी जाती है, तो प्रोग्राम ठप पड़ जाता है। PMM सामग्री पर केंद्रित विभाग है। बाकी तीन काम ऑपरेशंस से जुड़े हैं। काम बाँटें, वरना वह होगा ही नहीं।
लीडरशिप की गैरमौजूदगी का पैटर्न। जिन प्रोग्रामों में CRO या VP of Sales हर महीने प्रतिस्पर्धी डील की जीत-हार की समीक्षा नहीं करते, उनका प्रदर्शन ऐसा करने वाले प्रोग्रामों से काफ़ी कम रहता है। उद्योग के डेटा से संकेत मिलता है कि यह समीक्षा होने पर प्रभावशीलता लगभग 76% बढ़ती है। इसके लिए एक कार्यकारी का हर महीने एक घंटा लगता है, और आगे की लगभग पूरी प्रक्रिया बदल जाती है क्योंकि प्रतिनिधियों को पता चलता है कि उनका दर्ज किया गया डेटा वास्तव में पढ़ा जाता है।
"जारी करने के बाद मापेंगे" वाला तरीका। जो प्रोग्राम ट्रैकिंग की व्यवस्था दूसरे चरण तक टालते हैं, वे कभी उसे लागू नहीं करते। जीत-हार फ़ील्ड, बैटल कार्ड कितने अपडेटेड हैं यह दिखाने वाला डैशबोर्ड, और AI सवालों की टेलीमेट्री प्रोग्राम के साथ ही उपलब्ध होनी चाहिए, बाद में नहीं। अगर आप 30वें दिन माप नहीं रहे हैं, तो 300वें दिन भी नहीं मापेंगे।
अगर आप शून्य से सेल्स-CI प्रोग्राम खड़ा कर रहे हैं, तो शुरुआती 60 दिनों के छह कदम तय करेंगे कि वह साल भर टिक पाएगा या नहीं।
अगर आप देखना चाहते हैं कि सेल्स-CI प्रोग्राम की डिलीवरी परत के रूप में AI-नेटिव CI वर्कस्पेस कैसा दिखता है, तो ओपन बीटा के दौरान Watchr मुफ़्त है। MCP से पढ़ी जा सकने वाली फ़ीड और हर प्रतिस्पर्धी के लिए प्रासंगिकता परखने वाला प्रॉम्प्ट, उसी आर्किटेक्चर को ध्यान में रखकर बनाए गए हैं जिसकी यह लेख वकालत करता है।
सेल्स-CI प्रोग्राम की ज़िम्मेदारी किसकी होनी चाहिए: PMM, RevOps, एनेबलमेंट या सेल्स?
चारों की, स्पष्ट बँटवारे के साथ। सामग्री और पोज़िशनिंग के आधार की ज़िम्मेदारी PMM की है। डेटा जुटाने और रूटिंग की ज़िम्मेदारी RevOps की है। इस्तेमाल बढ़ाने की ज़िम्मेदारी एनेबलमेंट की है। फ़ीडबैक लूप और कार्यकारी स्तर पर समर्थन की ज़िम्मेदारी सेल्स लीडरशिप की है। सबसे आम विफलता एक ही विभाग से चारों काम सँभालने को कहना है।
30 से कम प्रतिनिधियों वाली टीम के लिए न्यूनतम उपयोगी सेल्स-CI प्रोग्राम क्या है?
डील बंद होते समय प्रतिस्पर्धी के लिए अनिवार्य CRM फ़ील्ड, प्राथमिकता वाले प्रतिस्पर्धियों के लिए तीन से पाँच Slack चैनल, हर प्राथमिकता वाले प्रतिस्पर्धी के लिए Notion या आपके CRM में एक अपडेट रखा जाने वाला बैटल कार्ड (PDF नहीं), और बैटल कार्ड की सामग्री से जुड़ा AI असिस्टेंट या कोपायलट। इस आकार पर एंटरप्राइज़ टूल न लें; AI-नेटिव स्टैक और कॉल इंटेलिजेंस मिलकर ज़रूरतें पूरी कर देते हैं।
हम प्रतिनिधियों से बैटल कार्ड का वास्तव में इस्तेमाल कैसे करवाएँ?
यह ग़लत सवाल है। सही सवाल यह है कि बैटल कार्ड की सामग्री उन जगहों पर कैसे पहुँचाएँ जहाँ प्रतिनिधि पहले से काम करते हैं (CRM, Slack, AI असिस्टेंट, कॉल समीक्षा), ताकि उन्हें अलग से "बैटल कार्ड इस्तेमाल करने" की आदत न बनानी पड़े। इस्तेमाल इस बात से बढ़ता है कि माध्यम काम के अनुकूल है या नहीं, प्रशिक्षण की तीव्रता से नहीं।
सेल्स-CI प्रोग्राम में Gong की क्या भूमिका है?
Gong (या कोई भी कॉल-इंटेलिजेंस टूल) अपने-आप में CI का माध्यम है। प्रतिस्पर्धियों के उल्लेख पहचानना, संदर्भ के भीतर बैटल कार्ड दिखाना और कॉल समीक्षा में CI के अंश देना—ये सभी देखने में जितने उपयोगी लगते हैं, उससे कहीं ज़्यादा उपयोगी हैं। अगर आप पहले से Gong इस्तेमाल करते हैं, तो अतिरिक्त टूल ख़रीदने से पहले जाँचें कि आपके टियर में कौन-से CI फ़ीचर मिलते हैं।
सेल्स लीडरशिप को प्रतिस्पर्धी डील की जीत-हार के डेटा की समीक्षा कितनी बार करनी चाहिए?
हर महीने। आवृत्ति से ज़्यादा नियमितता मायने रखती है। प्रतिनिधियों तक यह संदेश जाता है कि उनका जुटाया डेटा शीर्ष स्तर पर पढ़ा जाता है।
प्रोग्राम सेल्स एनेबलमेंट को चलाना चाहिए या RevOps को?
अकेले किसी को नहीं। एनेबलमेंट इस्तेमाल बढ़ाने और प्रशिक्षण का काम सँभालता है। RevOps ट्रैकिंग की व्यवस्था और टूल संबंधी फ़ैसले सँभालता है। जो प्रोग्राम एक को चुनकर दूसरे को नज़रअंदाज़ करते हैं, उनका प्रदर्शन स्पष्ट बँटवारा करने वाले प्रोग्रामों से कम रहता है।
नए सेल्स-CI प्रोग्रामों की सबसे बड़ी ग़लती क्या है?
डिलीवरी की व्यवस्था बनाने से पहले सामग्री जारी कर देना। ऐसी जगहों पर बेहतरीन लिखे हुए बैटल कार्ड रखना जहाँ कोई प्रतिनिधि जाता ही नहीं, विफलता का सबसे आम कारण है। पहले डिलीवरी आर्किटेक्चर बनाएँ; सामग्री बाद में उसमें फ़िट हो जाती है।