एक सेल्स प्लेबुक बनाना जिसे रेप्स असल में इस्तेमाल करेंगे

लगभग हर सेल्स ऑर्ग के पास कहीं न कहीं एक प्लेबुक होती है — एक शेयर्ड डॉक, एक विकी पेज, पिछले सेल्स किकऑफ की एक स्लाइड डेक। लगभग किसी को भी पहले दो हफ्तों के बाद नहीं खोला जाता। ऐसा इसलिए नहीं है क्योंकि रेप्स आलसी हैं या कंटेंट गलत है; यह इसलिए है क्योंकि ज़्यादातर प्लेबुक्स उस तरह बनाई जाती हैं जैसे एक टेक्स्टबुक बनाई जाती है, उस तरह नहीं जिस तरह एक रेप को असल में इसका इस्तेमाल करने की ज़रूरत होती है। एक रेप कॉल से पहले एक प्लेबुक पढ़ने के लिए नहीं बैठता। उसे एक खास समस्या का जवाब चाहिए होता है, लाइव में इसका रिस्पॉन्स देने से तीस सेकंड पहले। अगर प्लेबुक यह डिलीवर नहीं कर सकती, तो यह एक टूल बनना बंद कर देती है और शेल्फवेयर बन जाती है।

स्टैटिक-डॉक्यूमेंट प्रॉब्लम

टिपिकल प्लेबुक एक बार लिखी जाती है, आमतौर पर एक एनेबलमेंट या प्रोडक्ट-मार्केटिंग टीम द्वारा, और एब्स्ट्रैक्ट कैटेगरीज़ के इर्द-गिर्द ऑर्गनाइज़्ड होती है: कंपनी ओवरव्यू, आइडियल कस्टमर प्रोफाइल, कॉम्पिटिटिव पोज़िशनिंग, मेथडोलॉजी ओवरव्यू, ऑब्जेक्शन-हैंडलिंग अपेंडिक्स। यह कॉम्प्रिहेंसिव है, अच्छी नीयत से बनी है, और लगभग पूरी तरह उस पल से डिसकनेक्टेड है जब एक रेप को असल में मदद की ज़रूरत होती है। जब एक प्रॉस्पेक्ट कहता है "हम पहले से एक कॉम्पिटिटर इस्तेमाल कर रहे हैं और बदलने की कोई वजह नहीं दिखती," तो एक रेप कॉल के बीच में PDF के पेज 34 पर स्क्रॉल नहीं करने वाला। वह इम्प्रोवाइज़ करेगा, बुरी तरह, और प्लेबुक अपने एकमात्र काम में फेल हो जाएगी।

इससे भी बुरा, इस तरह की प्लेबुक को आमतौर पर एक शुरुआत और अंत की तारीख वाले प्रोजेक्ट की तरह ट्रीट किया जाता है। यह शिप होती है, एनेबलमेंट अगली पहल की ओर बढ़ जाता है, और छह महीने बाद प्राइसिंग बदल चुकी होती है, कॉम्पिटिटिव लैंडस्केप शिफ्ट हो चुका होता है, और किसी ने डॉक्यूमेंट को छुआ तक नहीं। रेप्स नोटिस करते हैं। एक बार प्लेबुक के गलत या पुरानी होने के बाद, रेप्स इस पर भरोसा करना बंद कर देते हैं — और इसे खोलना बंद कर देते हैं — भले ही बाद में इसे ठीक कर दिया जाए।

थ्योरी के बजाय पलों के इर्द-गिर्द ऑर्गनाइज़ करें

उपाय पूरे स्ट्रक्चर को पलट देना है। एब्स्ट्रैक्ट सेल्स थ्योरी के इर्द-गिर्द ऑर्गनाइज़्ड चैप्टर्स के बजाय, प्लेबुक को उन खास पलों के इर्द-गिर्द ऑर्गनाइज़ करें जिनसे रेप्स असल में एक कॉल में टकराते हैं: कॉमन ऑब्जेक्शंस का एक तय सेट (प्राइस, कॉम्पिटिटर कंपैरिज़न, "हमें इस पर सोचना होगा," टाइमिंग), और स्टेकहोल्डर टाइप्स का एक तय सेट (इकोनॉमिक बायर, टेक्निकल इवैल्युएटर, स्केप्टिकल एंड यूज़र)। हर एंट्री छोटी होनी चाहिए — फ्रेमिंग के एक या दो वाक्य, साथ ही उस पल में एक टॉप रेप जो असली भाषा इस्तेमाल करता है — और सिनेरियो के हिसाब से सर्च करने लायक, किसी चैप्टर टाइटल के हिसाब से नहीं जिसे रेप को अंदाज़ा लगाना पड़े।

इसका मतलब यह भी है कि इस बारे में डिसिप्लिन्ड रहना कि प्लेबुक में क्या नहीं होना चाहिए। जनरल कंपनी बैकग्राउंड, ऑर्ग चार्ट्स, और इंटरनल प्रोसेस डॉक्यूमेंटेशन को पूरी तरह कहीं और रहना चाहिए। एक प्लेबुक जो रेफरेंस मटीरियल को इन-कॉल लैंग्वेज के साथ मिलाती है, सर्च करने में तेज़ रहना बंद कर देती है, और स्पीड ही पूरा पॉइंट है। अगर एक रेप तीस सेकंड से कम में जो चाहिए वह नहीं ढूंढ सकता, तो यह अपना काम नहीं कर रही।

एक चेकलिस्ट: एक प्लेबुक जो असली कॉल के संपर्क में आकर भी टिकती है

• हर एंट्री एक खास ऑब्जेक्शन या स्टेकहोल्डर टाइप के इर्द-गिर्द ऑर्गनाइज़्ड है, किसी जनरल टॉपिक के इर्द-गिर्द नहीं।
• हर एंट्री एक स्क्रीन में फिट होती है — इस्तेमाल करने लायक असली भाषा ढूंढने के लिए कोई स्क्रॉलिंग ज़रूरी नहीं।
• हर एंट्री में भाषा वह है जो एक टॉप रेप ने असल में कही है और जो काम कर चुकी है, किसी व्हाइटबोर्ड सेशन से लिखी गई नहीं।
• इसे अपडेट करने के लिए ज़िम्मेदार एक ओनर है, और रिव्यू के लिए एक तय कैडेंस (मासिक, सालाना नहीं) है।
• जब एक रेप कोई ऐसा सिनेरियो खोजता है जिसे प्लेबुक अभी कवर नहीं करती, तो नई एंट्रीज़ जोड़ी जाती हैं।
• रेप्स के पास यह फ्लैग करने का तरीका है कि जब कोई भाषा का टुकड़ा काम करना बंद कर दे, ताकि इसे रिटायर या दोबारा लिखा जा सके।

इसे एक लिविंग डॉक्यूमेंट बनाएं, एक बार का प्रोजेक्ट नहीं

एक इस्तेमाल होने वाली प्लेबुक और एक जो नहीं होती, उसके बीच सबसे बड़ा फर्क यह है कि क्या इसे ऑनगोइंग इंफ्रास्ट्रक्चर की तरह ट्रीट किया जाता है या एक शिप्ड डिलीवरेबल की तरह। नए प्लेबुक कंटेंट का सबसे अच्छा सोर्स कोई स्ट्रैटेजी ऑफसाइट नहीं है — यह अभी हो रहे कॉल्स हैं। एक रेप जो एक ऐसी फ्रेमिंग ढूंढता है जो लगातार एक खास ऑब्जेक्शन को डिफ्यूज़ करती है, उसने असल में फील्ड-टेस्टेड कंटेंट बनाया है जिसे तुरंत प्लेबुक में होना चाहिए, अगले क्वार्टरली रिफ्रेश पर नहीं। इसे सामने लाने के लिए एक लाइटवेट प्रोसेस बनाना — एक Slack चैनल, टीम मीटिंग्स में एक रिकरिंग पांच-मिनट का एजेंडा आइटम, CRM में एक टैग — प्लेबुक को करंट रखता है बिना इसे वापस एक बड़े एनुअल प्रोजेक्ट में बदले।

प्लेबुक पढ़ना इसे इस्तेमाल करने के लिए तैयार होने जैसा क्यों नहीं है

यहां तक कि एक अच्छी तरह बनी प्लेबुक की भी अपनी एक सीमा है: सही भाषा पढ़ना इसे प्रेशर में, रियल टाइम में, एक प्रॉस्पेक्ट के पुशबैक करते हुए डिलीवर कर पाने के बराबर नहीं है। यही the Practice Gap है — यह जानने और जब मायने रखे तब इसे फ्लुएंटली बोल पाने के बीच की जगह। एक रेप प्लेबुक की कॉम्पिटिटर-ऑब्जेक्शन एंट्री दस बार पढ़ सकता है और फिर भी उस पहली बार फ्रीज़ हो सकता है जब एक प्रॉस्पेक्ट असल में कॉल के बीच में उस कॉम्पिटिटर का नाम लेता है, क्योंकि पढ़ना रिहर्सल नहीं है।

यहीं पर प्लेबुक को सिर्फ पब्लिश करना नहीं बल्कि प्रैक्टिस करना डिफरेंशिएटर बन जाता है। Frontline Coach एनेबलमेंट टीमों को प्लेबुक में मौजूद सटीक सिनेरियोज़ — एक खास ऑब्जेक्शन, एक खास स्टेकहोल्डर पर्सोना — को AI रोलप्ले ड्रिल्स में बदलने देता है जिन्हें रेप्स बार-बार चला सकते हैं जब तक रिस्पॉन्स याद रखे जाने के बजाय रिफ्लेक्सिव न हो जाए। क्योंकि प्लेटफॉर्म की प्रोडक्ट-नॉलेज इंजेशन यह खींचती है कि आपके रेप्स असल में क्या बेचते हैं, रोलप्ले आपके असली प्रोडक्ट और आपके असली कॉम्पिटिटिव लैंडस्केप को दिखाता है, किसी टेम्पलेट पर जोड़े गए जेनेरिक सिनेरियो को नहीं। प्लेबुक रोलआउट को एक व्यापक मेथडोलॉजी रोलआउट प्लान के साथ जोड़ें, और प्लेबुक के अंडरलाइंग फ्रेमवर्क्स को एक असली मेथडोलॉजी में ग्राउंड करें — देखें कि MEDDIC, Challenger, और Sandler कैसे तुलना करते हैं — ताकि प्लेबुक एक असली फ्रेमवर्क लागू कर रही हो, शुरू से किसी एक को गढ़ नहीं रही हो।