B2B संस्थापकों के लिए सेल्स पाइपलाइन स्कीमा: न्यूनतम फ़ील्ड, स्टेज और गतिविधि ट्रैकिंग ताकि फ़ोरकास्ट साफ़ रहे और डील बिना CRM के फूले हुए हुए आगे बढ़ें।

शुरू में आपकी पाइपलाइन साफ़ लगती है क्योंकि डील कम होते हैं और ज़्यादातर संदर्भ आपके सिर में रहता है। फिर सूची बढ़ती है, आप एक फॉलो-अप मिस कर देते हैं, और पाइपलाइन हकीकत से बेहतर कहानी बताने लगती है। इसे “पाइपलाइन का झूठ बोलना” कह सकते हैं: नज़रों में इरादतन नहीं, बल्कि इसलिए कि सिस्टम में सच्चाई को मजबूर करने वाला कुछ नहीं है।
यह अक्सर इन पैटर्न में दिखता है:
एक सामान्य प्रतिक्रिया होती है CRM को ओवरबिल्ड कर देना: और फ़ील्ड, और कस्टम स्टेज, लंबी नोट्स। विडंबना यह है कि इससे अक्सर फ़ोरकास्टिंग और खराब हो जाती है। जब अपडेट करना भारी लगे, लोग कम अपडेट करते हैं, और पाइपलाइन चुपचाप सड़ जाती है।
न्यूनतम काम करने वाला सेल्स पाइपलाइन स्कीमा इसका उल्टा करता है। यह निर्णय लेने के लिए पर्याप्त संरचना देता है—सब कुछ कैप्चर करने की कोशिश नहीं करता। यह वे कुछ तथ्य कैप्चर करता है जो आपको खुद को धोखा देने से रोकते हैं।
अगर आप सिर्फ़ एक नियम इस्तेमाल करें, तो यह रखें: हर ओपन डील के पास (1) एक स्पष्ट अगला क्रिया, (2) उस क्रिया की एक तारीख, और (3) एक क्लोज़ तारीख जो किसी वास्तविक खरीदार टाइमलाइन से जुड़ी हो (मीटिंग, कानूनी कदम, बजट समीक्षा)। यदि इनमें से कोई भी गायब है, तो डील सक्रिय नहीं है।
स्टेज का भी मतलब होना चाहिए। एक डील तभी आगे बढ़े जब कोई ठोस बात हुई हो, न कि क्योंकि सबको अच्छा लग रहा है। लक्ष्य खूबसूरत डैशबोर्ड नहीं है; लक्ष्य एक ईमानदार दृश्य है जिस पर आप बिज़नेस चला सकें।
एक सेल्स पाइपलाइन स्कीमा तभी काम करता है जब हर कोई इसे एक ही तरह से ट्रीट करे। फ़ील्ड जोड़ने या स्टेज पर बहस करने से पहले तय करें कि एक सिंगल पाइपलाइन आइटम किसका प्रतिनिधित्व करता है।
B2B के लिए एक साफ़ डिफ़ॉल्ट यही है: एक डील = एक खरीद निर्णय। अगर एक ही कंपनी दो बार खरीद सकती है (दो टीमें, दो प्रोडक्ट, दो बजट), तो वह दो डील हों, न कि एक उलझा हुआ रिकॉर्ड।
ऑब्जेक्ट्स को सरल रखें। आप तीन बकेट से काफी कुछ कर सकते हैं: लीड (जिससे आप संपर्क कर सकते हैं), अकाउंट (कंपनी), और डील (वह ख़रीद जो आप बंद करने की कोशिश कर रहे हैं)। अगर आप अकेले हैं, तो आप फॉर्मल लीड और अकाउंट रिकॉर्ड छोड़ भी सकते हैं और सिर्फ़ यह सुनिश्चित कर सकते हैं कि हर डील में कंपनी और मुख्य संपर्क स्पष्ट रूप से लिखा हो।
कुछ ऑपरेटिंग नियम लिखें, खासकर अगर आपको छोड़कर और लोग पाइपलाइन को छूते हैं:
उदाहरण: आप Northwind में Alex से फ़ाइनेंस टीम के लिए पायलट के बारे में बात करते हैं। यह एक डील है। अगर एक महीने बाद प्रोडक्ट अलग कॉन्ट्रैक्ट चाहती है, तो दूसरी डील बनाएं। एक रिकॉर्ड को दो निर्णयों के लिए खींचें नहीं।
पाइपलाइन तब उपयोगी रहती है जब हर डील के पास वे थोड़े फ़ील्ड हों जिन्हें आप हर हफ्ते चेक करते हैं। “बस फ़िलहाल” के लिए फ़ील्ड जोड़ें और वे सिर्फ़ शोपीस बन जाते हैं।
डुप्लिकेट्स रोकने वाला एक डील नाम फॉर्मेट से शुरू करें। एक सरल पैटर्न काम करता है: Company - Product/Scope - Quarter/Month। उदाहरण: “Acme - Team plan - Mar 2026.” इससे स्पष्ट हो जाता है कि “Acme - Demo” और “Acme - Follow-up” वास्तव में एक ही डील तो नहीं।
हर डील को पहचान की स्पष्टता भी चाहिए:
रोल मायने रखता है क्योंकि यह बदल देता है कि अगला कदम क्या होगा। एक champion को enablement चाहिए; decision maker को बिज़नेस केस चाहिए।
जवाबदेही फ़ील्ड जोड़ें:
फिर सिर्फ़ पैसा और समय जोड़ें जो आप वाकई इस्तेमाल करेंगे:
अगर किसी फ़ील्ड के बारे में अनिश्चित हैं तो छोड़ दें। आप बाद में जोड़ सकते हैं। आदतें बन जाने के बाद फ़ील्ड हटाना मुश्किल होता है।
अधिकांश “बड़ी” पाइपलाइन्स ज़्यादा बड़ी नहीं होतीं। वे उन डील्स से भरी होतीं जो देखने में अच्छी लगती हैं पर जिनके पास स्पष्ट YES की राह नहीं होती।
एक फ़ील्ड से शुरुआत करें जो स्पष्टता को मजबूर करे: Use case (scope)। खरीदार क्या हासिल करना चाह रहा है और “डन” कैसा दिखेगा—साफ़ शब्दों में लिखें। अगर आप दो वाक्यों में आउटकम बयान नहीं कर सकते, तो शायद आप डील को अभी तक नहीं समझते।
अगला, decision process एक जगह कैप्चर करें। यह संपर्कों की बाढ़ नहीं है; यह कहानी है कि निर्णय कैसे लिया जाएगा: कौन साइन करेगा, कौन ब्लॉक कर सकता है, और किन स्टेप्स को फॉलो करना होगा (security review, legal, procurement)। अगर आप साइनर नहीं जानते, तो डील को शुरुआती मानें।
एक pricing fit signal भी रखें, भले ही मोटा हो। रेंजें (“< $5k”, “$5-25k”, “$25k+”) ठीक हैं, या Likely / Unclear / Unlikely—जो आपने सुना उस पर आधारित। मकसद यह है कि उन डील्स को आगे न बढ़ाएँ जिनके पास आपकी कीमत वहन करने का संभावना नहीं है।
अंत में, red flags एक लाइन तक सीमित रखें। अगर वह एक पैराग्राफ बनता है तो उसे नोट्स में रखें।
एक कॉम्पैक्ट सेट जो अधिकांश B2B संस्थापकों के लिए काम करता है:
उदाहरण: “Renewal से पहले CRM क्लीनअप चाहिए, साइनर VP Sales हैं, security review जरूरी, बजट लगभग $10-20k, मुकाबला: कुछ न करना, red flag: champion प्रोजेक्ट का मालिक नहीं।” यह रिकॉर्ड खुद को धोखा देना कठिन बना देता है।
पाइपलाइन तब खराब होती है जब वह इच्छाओं की सूची बन जाती है। समाधान ज़्यादा फ़ील्ड नहीं है। यह कुछ activity सिग्नल हैं जो हर डील से एक सवाल का जवाब माँगते हैं: अगला क्या हो रहा है?
अगर आप पाइपलाइन स्कीमा में सिर्फ़ एक परत जोड़ते हैं, तो ये activity फ़ील्ड्स जोड़ें:
एक व्यावहारिक नियम: अगर किसी डील में नेक्स्ट स्टेप या ड्यू डेट नहीं है, तो वह असली डील नहीं है। इसे पार्क करें या बंद कर दें। यह किसी भी स्कोरिंग मॉडल से ज़्यादा फ़ोरकास्ट सटीकता देता है।
“Reason lost” छोटा रखें ताकि आप वाकई में इस्तेमाल करें: price, no budget, no decision, chose competitor, timing, not a fit।
यह कैसा दिखता है: आपकी एक मीटिंग मंगलवार को ops लीड के साथ हुई। कॉल के तुरंत बाद आप सेट करते हैं last activity date = Tue, last touch channel = meeting, next step = “2 केस स्टडी भेजें और बताएं कौन साइन करेगा”, next step due date = Thu। अगर Thu बीत जाता है और कोई जवाब नहीं आता, तो बिना किसी बहस के डील रेड हो जाती है क्योंकि अगला कदम पूरा नहीं हुआ।
एक अच्छा स्टेज मॉडल एक काम करता है: यह हर डील के बारे में सच बताता है, बिना आपको दर्जनों छोटे-छोटे कदम पर नागरानी करने के। अगर आप यह नहीं कह सकते कि एक डील के उस स्टेज में होने के लिए क्या सच्चा होना चाहिए, तो स्टेज एक भावना बन जाती है।
यह छह-स्टेज सेटअप अधिकांश B2B संस्थापकों के लिए काम करता है:
New: आपके पास नाम है और पहुँचने की वजह। पहला संपर्क हो चुका है या शेड्यूल किया गया है।
Qualified: बेसिक फिट कन्फ़र्म हो चुका है। समस्या वास्तविक है, ग्राहक आपके ICP से मेल खाता है, और खरीद का एक संभावित रास्ता है।
Discovery done: आपक/े पास असली बातचीत हुई है। आप यूज़ केस, सक्सेस क्राइटीरिया, और शामिल लोगों को समझते हैं।
Proposal sent: प्राइसिंग और स्कोप ग्राहक के हाथ में हैं। अगला कदम बुक हो चुका है या स्पष्ट रूप से रिक्वेस्ट किया गया है।
Negotiation/Legal: procurement, security, बजट स्वीकृति, या कॉन्ट्रैक्ट एडिट्स शुरू हो चुके हैं।
Closed won / Closed lost: परिणाम मार्क किया गया और कारण कैप्चर किया गया।
डील तभी आगे बढ़ाएँ जब असल दुनिया में कुछ हुआ हो (मीटिंग पूरी हुई, प्रस्ताव भेजा गया, लीगल शुरू हुआ)। अगर कुछ नहीं हुआ, तो स्टेज जस का तस रहे।
स्टेज का नाम स्टेज की परिभाषा नहीं है। अगर आप सिर्फ़ एक कॉलम को “Qualified” या “Negotiation” लेबल कर देंगे, तो अंत में आपको ऐसे डील मिलेंगे जो वहीं पड़े रहेंगे क्योंकि कोई सहमत नहीं कि “पूरा” क्या दिखता है।
स्टेज नियम सरल true/false चेक के रूप में लिखें। जब किसी स्टेज में हर डील एक समान तथ्य साझा करता है, आपकी पाइपलाइन भरोसेमंद रहती है।
एंट्री क्राइटीरिया बताता है कि किसी डील के स्टेज में आने से पहले क्या सत्य होना चाहिए। एग्ज़िट क्राइटीरिया बताता है कि आगे बढ़ने से पहले क्या बदलना चाहिए। दोनों को छोटा और मापने योग्य रखें।
उदाहरण:
अगर आप “good”, “strong”, या “interested” जैसे शब्दों के बिना क्राइटीरिया नहीं लिख पा रहे, तो स्टेज बहुत फ़ज़ी है।
प्रत्येक स्टेज के लिए अधिकतम आयु बताएं—यह सजा नहीं बल्कि जल्दी चेतावनी है। उदाहरण: Discovery अधिकतम 14 दिन, Proposal अधिकतम 21 दिन। जब डील सीमा पार कर ले, तो रीसेट ट्रिगर करें: अगला कदम बुक करें, उसे पीछे ले जाएँ, या बंद करें।
निर्धारित करें कि जब क्राइटीरिया पूरे नहीं होते तो डिफ़ॉल्ट एक्शन क्या होगा:
यह “ज़ॉम्बी डील्स” को आपके फ़ोरकास्ट को फूलने से रोकता है।
अगर आप इसे एक छोटे प्रोडक्ट की तरह ट्रीट करें—पहले नियम, फिर वही जो उन नियमों का समर्थन करे—तो आप कुछ घंटों में सेल्स पाइपलाइन स्कीमा बना सकते हैं।
खाली पन्ने से शुरू करें, किसी टूल के अंदर नहीं। अपने स्टेज और एंट्री/एग्ज़िट क्राइटीरिया plain English (या आपकी टीम की भाषा) में लिखें। अगर आप किसी स्टेज को एक वाक्य में समझा नहीं पा रहे, तो वह शायद दो स्टेज है (या स्टेज ही नहीं)।
एक सरल बिल्ड फ़्लो:
सेटअप के समय एक वास्तविक परीक्षण करें: एक सक्रिय डील लें और उसे स्टेज दर स्टेज आगे बढ़ाने की कोशिश करें। अगर आप बार-बार अनुमान लगा रहे हैं, तो आपके क्राइटीरिया बहुत अस्पष्ट हैं।
एक नियम जल्दी लागू करें: अगर next activity date खाली है तो डील active स्टेज में नहीं रह सकती।
ज़्यादातर CRM बloat अच्छी नीयत से शुरू होता है: आप अधिक सटीकता चाहते हैं, इसलिए और फ़ील्ड, और स्टेज, और नोट-टेकिंग जोड़ते हैं। परिणाम उलटा होता है। लोग अपडेट करना बंद कर देते हैं, और आपकी पाइपलाइन एक कब्रिस्तान बन जाती है जहां डील्स जाने के लिए रखी जाती हैं।
अगर दो स्टेज एक जैसे महसूस होते हैं, वे भी एक जैसे इस्तेमाल होंगे। “Discovery”, “Deep discovery”, और “Discovery follow-up” अक्सर बस “हमने बात की” मतलब देते हैं, बिना स्पष्ट अगले ईवेंट के। स्टेज केवल तब बदलने चाहिए जब कुछ असली बदले।
एक त्वरित परीक्षण: अगर आप यह नहीं कह सकते कि किसी स्टेज में एंटर होने के लिए क्या सच्चाई होनी चाहिए एक वाक्य में, तो वह स्टेज शायद अतिरिक्त है।
क्लोज़ डेट तभी उपयोगी है जब वह किसी कारण से जुड़ी हो। इसे अगले निर्णय बिंदु की तारीख मानें (बजट अप्रूवल, procurement मीटिंग, सिग्नेचर डेडलाइन), और उस इवेंट के हिलने पर ही इसे आगे-पीछे करें।
लंबी नोट्स उस एक चीज़ को छिपा देती हैं जो आपको चाहिए: आख़िरी क्या हुआ और आगे क्या होगा। नोट्स को छोटा रखें, और एक्टिविटी को last activity date + next step (owner और due date के साथ) से ट्रैक करें।
बिना परिभाषा के “qualified” का मतलब बन जाता है “उन्होंने अच्छा लगा।” 3–4 चेक चुनें जो होने ज़रूरी हैं (समस्या, खरीदार, टाइमलाइन, और किसी रूप में बजट)। अगर एक भी गायब है, तो वह अभी qualified नहीं है।
वो पाइपलाइन्स जो सिर्फ़ बढ़ते ही रहते हैं, वे पाइपलाइन नहीं रहतीं; वे कब्रिस्तान बन जाती हैं। जब डील निष्क्रिय हो या फिट गलत हो तो उसे तेज़ी से close lost करें और एक स्पष्ट कारण कैप्चर करें ताकि आप सीख सकें।
हर हफ्ते एक समय चुनें (30 मिनट काफी है) और इसे अपने भविष्य के आप के साथ मीटिंग समझकर करें। पाइपलाइन हाइजीन फ़ील्ड जोड़ने से ज़्यादा यह सुनिश्चित करने का काम है कि हर डील के पास असली आगे का रास्ता है।
सरल समीक्षा फ़्लो:
ठोस उदाहरण: अगर कोई डील “Proposal sent” पर है पर उसे रिव्यू करने के लिए कोई मीटिंग बुक नहीं है, तो यह प्रस्ताव-स्टेज डील नहीं है। उसे वापस ले जाएँ, अगला कदम सेट करें, और तब तक उसे काउंट न करें जब तक खरीदार फिर से एंगेज न हो।
आप एक B2B एनालिटिक्स टूल बेचते हैं एक 50-व्यक्ति की ई-कॉमर्स कंपनी को। पहली कॉल के बाद आप एक डील बनाते हैं और केवल वही भरते हैं जो अगले हफ्ते काम आएगा। एक सरल स्कीमा यहाँ काम करता है क्योंकि यह कागज़ नहीं बल्कि स्पष्टता मजबूर करता है।
कॉल के तुरंत बाद रिकॉर्ड कुछ इस तरह दिखता है:
डील Discovery में शुरू होती है। आप उसे तभी आगे बढ़ाते हैं जब कैलेंडर इनवाइट स्वीकार हो (न कि जब किसी ने “दिलचस्पी” दिखाई)। डेमो के बाद, Evaluation में जाने का ट्रिगर एक ठोस रिक्वेस्ट होती है (उदा. “क्या आप Shopify और हमारा वेयरहाउस डेटा कनेक्ट कर सकते हैं?”), उसके बाद सहमति वाली एक तकनीकी चेक।
अब रुकावट: CFO प्राइसिंग के बाद चुप हो जाते हैं। आपके लॉग में दो फॉलो-अप हैं, कोई जवाब नहीं, और नेक्स्ट स्टेप डेट निकल जाती है। नियम सरल है: अगर कोई सहमत अगला कदम नहीं है, तो डील Proposal में नहीं रह सकती।
तो आप ईमानदार कदम उठाते हैं: या तो उसे Evaluation में वापस ले जाते हैं (अगर आपको नया sponsor चाहिए या जानकारी ग़ायब है) या close lost कर देते हैं (अगर decision maker तय तारीख तक engage नहीं करेगा)। इस उदाहरण में आप उसे वापस ले जाते हैं, stakeholders अपडेट करते हैं (Ops finance manager को खींचता है), नई नेक्स्ट स्टेप डेट सेट करते हैं, और CFO एक निर्णय मीटिंग कन्फ़र्म करने पर ही Proposal में वापस आती है।
एक सेल्स पाइपलाइन स्कीमा तभी काम करता है जब आप उस पर भरोसा करते हैं। सबसे तेज़ रास्ता है न्यूनतम से शुरू करें और 30 दिनों तक उस पर रहें। इससे आप जान पाएँगे कि आप वाकई क्या इस्तेमाल करते हैं, न कि आप क्या सोचते हैं कि चाहिए।
पहले महीने के लिए कड़ाई बरतें: अगर कोई फ़ील्ड निर्णय बदलने लायक नहीं है तो उसे हटाएँ। अगर कोई निर्णय बार-बार आता है और आप पाइपलाइन से उसका जवाब नहीं पा रहे, तो ठीक एक फ़ील्ड जोड़ें जो उस गैप को भर दे।
किसी भी नए फ़ील्ड को जोड़ने से पहले एक सरल टेस्ट करें: “अगर यह खाली है, तो हम यह निर्णय नहीं ले सकते कि ___।”
अगर आप कोई हल्का कस्टम CRM बनाना चाहते हैं बजाय generic टूल को ज़बरदस्ती फिट करने के, तो Koder.ai (koder.ai) जैसे टूल मदद कर सकते हैं जब आपने अपने स्टेज, आवश्यक फ़ील्ड और वैलिडेशन नियम लिख लिए हों। एक सरल ऐप जनरेट और इटरेट करना बहुत आसान होता है जब स्कीमा पहले से साफ़ हो।
पाइपलाइन तब “झूठ बोलती” है जब वह प्रगति दिखाती है जो वास्तविक खरीदार की कार्रवाई से समर्थित नहीं होती। सामान्य कारण हैं: नेक्स्ट-स्टेप न होना, आख़िरी गतिविधि की तारीख पुरानी होना, और क्लोज़ तारीखें बिना खरीदार-निर्धारित टाइमलाइन के आगे बढ़ा दी जाना।
हर ओपन डील के लिए तीन फ़ील्ड नॉन-नेगोशिएबल बनाएं: एक ठोस अगला कदम, उस कदम की ड्यू तारीख, और एक क्लोज़ डेट जो किसी वास्तविक खरीदार इवेंट (मीटिंग, समीक्षा, सिग्नेचर) से जुड़ी हो। यदि ये किसी भी डील में खाली हैं, तो उसे निष्क्रिय मानें जब तक वे भर न दिए जाएँ।
डिफ़ॉल्ट नियम रखें: “एक डील = एक खरीद निर्णय।” अगर एक ही कंपनी अलग टीमों, अलग बजट या अलग कॉन्ट्रैक्ट के माध्यम से दो बार खरीद सकती है, तो अलग डील बनाएं।
डुप्लिकेट से बचने वाला डील नाम फॉर्मेट, एक कंपनी, प्राथमिक संपर्क, एक ओनर, अपेक्षित मूल्य, लक्ष्य क्लोज़ तारीख और स्पष्ट स्रोत के साथ शुरू करें। फिर केवल उतनी योग्यता जोड़ें जितनी बंद होने का कारण बताती हो: यूज़ केस, निर्णय प्रक्रिया, और प्राइसिंग फिट।
एक वाक्य में यूज़ केस + “सक्सेस” क्राइटीरिया लिखना यह मजबूर करता है कि आप परिणाम समझें, न कि सिर्फ़ खरीदार की दिलचस्पी। अगर आप परिणाम साफ़ नहीं बता सकते, तो डील आमतौर पर अनुमान लगाने के लिए बहुत जल्दी है।
निर्णय प्रक्रिया को एक छोटी कहानी के रूप में लिखें: कौन साइन करता है, कौन ब्लॉक कर सकता है, और किन स्टेप्स की ज़रूरत है (security, legal, procurement)। अगर साइनर नहीं पता है तो डील को शुरुआती स्टेज में रखें और अगला कदम साइनर/प्रक्रिया खोजने पर फोकस करें।
बजट के लिए एक मोटा रेंज या Likely/Unclear/Unlikely का सिग्नल रखें—उद्देश्य परफेक्ट नंबर नहीं बल्कि यह रोकना है कि आप ऐसे डील्स को आगे न बढ़ाएँ जिनके पास वास्तविक बजट नहीं है।
हफ्ते दर हफ्ते जिन फ़ील्ड्स की ज़रूरत होती है वे हैं: आख़िरी गतिविधि तारीख, अगला कदम, अगला कदम ड्यू डेट, और अंत में क्लोज़ रीज़न। नोट्स हो सकती हैं, पर ये activity फ़ील्ड्स ही डील्स को बहकने से रोकती हैं।
स्टेज तब ही बढ़ाएँ जब असल दुनिया में कुछ हुआ हो—जैसे डिस्कवरी कॉल पूरी हुई, प्रस्ताव भेजा गया, या लीगल शामिल हुआ। अगर स्टेज बदलना सिर्फ़ “अच्छा लगना” पर निर्भर है तो रुल्स बहुत फ़ज़ी हैं।
प्रत्येक स्टेज के लिए अधिकतम दिनों की सीमा सेट करें ताकि समय सीमा पार होते ही रीसेट ट्रिगर हो: या तो असली अगला कदम बुक करें, डील को पिछली उपयुक्त स्टेज में लौटाएँ, या स्पष्ट फॉलो-अप के बाद उसे ‘नो डिसीजन’ के रूप में क्लोज़ कर दें।