फ्रीलांसरों के लिए प्रस्ताव पाइपलाइन ऐप: Draft से Won/Lost तक

क्यों प्रस्ताव फिस्ल जाते हैं

अधिकांश फ्रीलांसर प्रस्ताव इसलिए नहीं हारते क्योंकि उनका काम कमजोर है। वे हारते हैं क्योंकि प्रस्ताव गायब हो जाता है।

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

प्रस्ताव ये जगहों पर बिखर जाते हैं:

• "Proposal v7 FINAL (2)" नाम का Google Doc
• तीन अलग-अलग सब्जेक्ट लाइन वाले ईमेल थ्रेड
• फोन में एक नोट जिसमें फॉलो-अप की तारीख लिखी हो
• बिना संदर्भ के कैलेंडर रिमाइंडर
• आपके दिमाग़ में (जब तक बहुत देर न हो जाए)

प्रस्ताव इसलिए फिसलते हैं क्योंकि एक ही जगह पर अगला कदम दिख रहा होता। अगर आप 10 सेकंड में जवाब नहीं दे सकते "मुझे आगे क्या करना है, और किस क्लाइंट के लिए?", तो फॉलो-अप देर हो जाते हैं। देर से किए गए फॉलो-अप खोई हुई डील में बदल जाते हैं, भले ही क्लाइंट रुचि दिखा रहा था।

यही पाइपलाइन है, सरल शब्दों में: कुछ स्पष्ट स्टेटस जो दिखाते हैं कि हर प्रस्ताव कहाँ है और अगला कदम क्या होना चाहिए। एक प्रस्ताव पाइपलाइन ऐप कोई भड़काऊ सेल्स मशीन नहीं है। यह स्कोरबोर्ड और टू-डू सूची दोनों है।

उम्मीदें धरातल पर रखें। आप एक जटिल CRM नहीं बना रहे हैं जिसमें फोरकास्टिंग, टेरिटोरीज़ और ऐसी रिपोर्ट्स हों जिन्हें आप कभी नहीं पढ़ेंगे। आप एक हल्का टूल चाहते हैं जो आपके काम करने के तरीके में फिट बैठे और "अगला कदम" स्पष्ट कर दे।

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

एक हल्के प्रस्ताव पाइपलाइन को क्या करना चाहिए

एक प्रस्ताव पाइपलाइन ऐप का एक काम है: हर प्रस्ताव को Draft से Won या Lost तक कम से कम प्रयास के साथ आगे रखना। अगर यह अतिरिक्त एडमिन काम बनाता है, तो आप इसका उपयोग बंद कर देंगे जब आपको इसकी सबसे ज्यादा ज़रूरत होगी।

किसी भी चीज़ को डिज़ाइन करने से पहले तय करें कि कुछ महीनों बाद भी आपको किसी प्रस्ताव के बारे में क्या जानना ज़रूरी है। इसे उन थोड़े से विवरणों तक रखें जो फॉलो-अप, आय का पूर्वानुमान और यह सीखने में मदद करें कि क्या बिकता है।

प्रत्येक प्रस्ताव के लिए व्यावहारिक न्यूनतम:

• क्लाइंट (व्यक्ति या कंपनी) और संपर्क तरीका
• सेवा प्रकार (उदाहरण: वेबसाइट रीफ़्रेश, मोबाइल ऐप, मासिक SEO)
• अनुमानित राशि (या सीमा) और अपेक्षित शुरूआत तारीख
• अगली फॉलो-अप तारीख
• वर्तमान स्टेटस (Draft, Sent, Negotiation, Won, Lost)

फिर परिभाषित करें कि "डन" का क्या मतलब है ताकि ऐप भरोसेमंद रहे। एक प्रस्ताव को हमेशा Sent में नहीं बैठना चाहिए। "डन" का मतलब है: रुके हुए आइटम रिमाइंडर ट्रिगर करें, जब आप जवाब पाते हैं तो परिणाम लॉग करें, और आप बिना स्प्रेडशीट एक्सपोर्ट किए सरल रिपोर्ट देख सकें।

शुरुआत में स्कोप छोटा रखें। एक उपयोगकर्ता, एक वर्कस्पेस और साधारण फ़ील्ड्स एक बड़े सिस्टम से बेहतर हैं जिसे आप कभी मेंटेन नहीं करते। अगर आप इस हफ्ते तीन प्रस्ताव भेजते हैं (दो "लैंडिंग पेज + कॉपी" के लिए और एक "रिटेनर सपोर्ट" के लिए), तो एक पाइपलाइन जो अगली फॉलो-अप तारीख और एक परिणाम आवश्यक करती है, जल्दी दिखाएगी कौन सी सेवा ज़्यादा बंद होती है और कहाँ समय खोता है।

ऐसे स्टेटस चुनें जो आपके असली वर्कफ़्लो से मेल खाते हों

स्टेटस तभी मदद करते हैं जब वे आपके असली दिन को दर्शाएँ, न कि किसी आदर्श प्रक्रिया को जिसे आप नहीं फॉलो करेंगे। सेट छोटा रखें ताकि कार्ड को आगे बढ़ाना सहज लगे।

एक व्यावहारिक सेट:

• Drafting
• Ready to send
• Sent
• Follow-up due
• Negotiating
• Won
• Lost

नाम छोटे और कार्रवाई-आधारित रखें। अगर आप स्टेटस पढ़कर अगले कदम नहीं समझ पाते, तो उसका नाम बदल दें।

अगला, कुछ आसान नियम सेट करें ताकि कुछ भी ज़ॉम्बी प्रस्ताव न बन जाए।

उदाहरण के लिए:

• कोई प्रस्ताव Sent में तब तक नहीं जा सकता जब तक उसमें क्लाइंट, सर्विस टाइप, कुल कीमत और डिलीवरी विंडो ना हो।
• Negotiating का मतलब होना चाहिए कि क्लाइंट ने जवाब दिया है और स्कोप, कीमत, या शर्तें सक्रिय रूप से बदल रही हैं।
• Won के लिए एक स्पष्ट संकेत चाहिए: साइन किया हुआ एग्रीमेंट, अग्रिम भुगतान, या लिखित "हाँ।"

फॉलो-अप तारीखें एक और गार्डरेल हैं। हर स्टेटस को रिमाइंडर की ज़रूरत नहीं है, पर कुछ को ज़रूर होनी चाहिए। एक ठोस डिफ़ॉल्ट: Sent और Follow-up due में अगली फॉलो-अप तारीख होनी चाहिए। Negotiating में भी जब अगला कदम आप पर हो, तब ज़रूरी कर सकते हैं।

एक त्वरित परिदृश्य: आप सोमवार को वेबसाइट रीडिज़ाइन कोट भेजते हैं। अगर गुरुवार तक जवाब नहीं मिलता, तो वह Follow-up due के रूप में दिखेगा। अगर क्लाइंट जवाब देता है "क्या हम ब्लॉग हटा सकते हैं और कीमत कम कर सकते हैं?", तो आप इसे Negotiating में ले जाकर अगली फॉलो-अप अगले दिन सेट कर देते हैं। इतना संरचना प्रवाह बनाए रखने के लिए काफी है बिना वर्कफ़्लो को कागज़ात में बदलने के।

डेटा डिज़ाइन: क्लाइंट, प्रस्ताव, सर्विस, गतिविधि

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

चार मुख्य ऑब्जेक्ट्स से शुरू करें: Clients, Proposals, Services, और Activities।

मुख्य तालिकाएँ (और वे क्या स्टोर करती हैं)

पहले वर्शन को सरल रखें:

• Clients: नाम, संपर्क व्यक्ति, ईमेल, नोट्स (और वैकल्पिक रूप से कंपनी आकार)
• Proposals: शीर्षक, client_id, service_type (या services), value, status, sent_date, next_follow_up_date, outcome_reason
• Services: नाम (उदाहरण: “Website refresh”, “SEO audit”), वैकल्पिक डिफ़ॉल्ट प्राइस रेंज
• Activities: proposal_id, प्रकार (note, reminder, call, email), टाइमस्टैम्प, विवरण

Proposals के लिए, next_follow_up_date आपका भविष्य का सुरक्षा नेट है। outcome_reason तब महत्वपूर्ण होता है जब आप Won या Lost मार्क करते हैं, क्योंकि "Lost: too expensive" और "Lost: timing" अलग-लक्षित सुधार चाहते हैं।

एक प्रस्ताव पर एक सर्विस बनाम कई सर्विसेस

प्रति-प्रस्ताव एक सर्विस टाइप सबसे तेज़ सेटअप है और तब काम करता है जब आप स्पष्ट पैकेज बेचते हैं। कई सर्विसेस तब बेहतर हैं जब आप बंडल (डिज़ाइन + बिल्ड + मेंटेनेंस) बेचते हैं, पर इससे जटिलता बढ़ती है। आपको एक जॉइन टेबल (जैसे ProposalServices) चाहिए होगी और आपकी रिपोर्टिंग कठिन होगी।

एक अच्छा समझौता यह है कि पहले एक सर्विस टाइप से शुरू करें और तभी कई सर्विसेस जोड़ें जब आप वास्तविक मिश्रित प्रस्ताव देखें।

Activities आपको ईमेल खोदने की जरूरत के बिना हल्का इतिहास देती हैं। प्रस्ताव भेजने के बाद एक त्वरित नोट लॉग करें जैसे "Sent v2, क्लाइंट ने टाइमलाइन के बारे में पूछा।" बाद में आप एक नज़र में देख सकेंगे क्या हुआ।

स्क्रीन प्लान करें: बोर्ड, सूची, विवरण, रिपोर्ट

एक प्रस्ताव पाइपलाइन ऐप को कुछ ही स्क्रीन चाहिए अगर हर एक स्पष्ट प्रश्न का उत्तर देता हो। उद्देश्य गति है: खोलें, देखें किसे ध्यान चाहिए, एक अपडेट करें, आगे बढ़ें।

पाइपलाइन बोर्ड (दैनिक दृश्य)

यह वह स्क्रीन है जिसमें आप रहते हैं। हर कॉलम एक स्टेटस है। हर कार्ड में सिर्फ उतनी जानकारी होनी चाहिए कि आप अगला कदम तय कर सकें:

• क्लाइंट का नाम
• प्रस्ताव मूल्य (या अनुमानित मासिक रिटेनर)
• अगली फॉलो-अप तारीख
• सर्विस टाइप टैग

क्विक एक्शंस परफेक्ट लेआउट से ज़्यादा मायने रखते हैं। कार्ड से (या एक छोटा डिटेल ड्रॉअर) आप स्टेटस बदल सकें, फॉलो-अप तारीख सेट कर सकें, नोट जोड़ सकें, और बिना लंबा फॉर्म भरे Won या Lost मार्क कर सकें।

प्रस्ताव सूची (खोज और पकड़ने का दृश्य)

बोर्ड्स फ्लो के लिए अच्छे हैं, पर खोजने के लिए सूचियाँ बेहतर हैं। एक साधारण टेबल-स्टाइल सूची रखें जिसमें फ़िल्टर हों जैसे स्टेटस, क्लाइंट, सर्विस टाइप, और ओवरड्यू फॉलो-अप। यह आपके "कैच-अप" व्यू बन जाएगा जब सप्ताह व्यस्त हो।

विवरण पेज (तेज़ संपादन, कागज़ नहीं)

आपको केवल दो चाहिए: एक Proposal पेज और एक Client पेज।

Proposal पेज टाइमलाइन के लिए है (नोट्स, स्टेटस बदलाव, अगली फॉलो-अप तारीख) साथ ही मुख्य फ़ील्ड्स जैसे value और service type। Client पेज वह जगह है जहाँ संदर्भ रहता है: संपर्क जानकारी, वर्तमान प्रस्ताव और हाल की गतिविधि।

अगर फॉलो-अप तारीख बदलने में 30 सेकंड लगते हैं, तो आप इसे अपडेट नहीं रखेंगे। इन पेजों को वन-टैप एडिट के लिए ऑप्टिमाइज़ करें।

सरल रिपोर्ट (एक स्क्रीन)

पहले के लिए एक हल्की रिपोर्ट काफी है: सर्विस टाइप के अनुसार क्लोज़ रेट और औसत क्लोज़ समय। इसे दो सवालों का जवाब देना चाहिए: "मुझे क्या ज्यादा बेचना चाहिए?" और "डील कहां अटकी रहती है?"

शून्य से उपयोगी तक बनाना

एक उपयोगी प्रस्ताव पाइपलाइन ऐप "फुल CRM" नहीं है। यह एक जगह है जहाँ आप देख सकें क्या सक्रिय है, क्या अटका है, और आज किसको फॉलो-अप करना है।

पहले ही दिन उपयोग करने लायक पहला वर्शन बनाएं

डेटा मॉडल और कुछ नकली रिकॉर्ड्स के साथ शुरू करें ताकि आप फ़्लो टेस्ट कर सकें। एक क्लाइंट बनाकर दो प्रस्ताव और कम से कम दो सर्विस टाइप (जैसे “Website refresh” और “Ongoing SEO”) रखें।

फिर दो मुख्य स्क्रीन बनाएं: एक बोर्ड (स्तम्भ स्टेटस के हिसाब से) और एक प्रस्ताव डिटेल फॉर्म। बोर्ड दैनिक स्कैन के लिए है। फॉर्म सटीक अपडेट के लिए है।

एक निर्माण क्रम जो आपको आगे बढ़ाए:

• मॉडल: Client, Proposal, ServiceType, Activity
• UI: बोर्ड व्यू + प्रस्ताव डिटेल फॉर्म (स्टेटस, वैल्यू, भेजने की तारीख, अगली फॉलो-अप)
• नियम: मुख्य फ़ील्ड्स के बिना स्टेटस मूव को ब्लॉक करें (उदाहरण: Sent के लिए sent_date चाहिए)
• रिमाइंडर: फॉलो-अप ड्यू पर नोटिफ़ाई करें (और वैकल्पिक रूप से जब प्रस्ताव पहली बार Sent हो)
• डैशबोर्ड: स्टेटस के अनुसार काउंट और सर्विस टाइप द्वारा एक क्लोज़-रेट चार्ट

"आगे नहीं बढ़ सकते जब तक..." चेक जोड़ें

यही चीज़ ऐप को भरोसेमंद बनाती है।

उदाहरण: आप एक प्रस्ताव को Draft से Sent में खींचते हैं, पर ऐप रोक दे अगर क्लाइंट ईमेल या प्रस्ताव राशि नहीं है। यह छोटा friction बाद में गंदा डेटा रोकता है।

एक डिफ़ॉल्ट नियम सब कुछ ड्रिफ्ट होने से रोकता है: हर ओपन प्रस्ताव के पास अगली फॉलो-अप तारीख होनी चाहिए। अगर यह गायब है, तो बोर्ड पर चेतावनी दिखाएँ।

"उपयोगी" की सरल परिभाषा:

• आप 60 सेकंड के भीतर एक प्रस्ताव जोड़ सकें
• एक नज़र में पता चल जाए कि आज किसे फॉलो-अप करना है
• स्टेटस परिवर्तन सुसंगत रहें (कोई आधा-सेंट नहीं)
• सर्विस टाइप द्वारा क्लोज़ रेट दिखे
• जब आप पहले से ही शीर्ष पर हों तो रिमाइंडर शांत रहें

स्टेटस-ड्रिवन रिमाइंडर जो आपको परेशान न करें

रिमाइंडर तब बेहतर काम करते हैं जब वे पाइपलाइन के स्पष्ट क्षण से जुड़े हों, न कि किसी यादृच्छिक कैलेंडर पिंग से। अगर आपका ऐप वर्तमान स्टेटस जानता है, तो यह तभी आपको झुकायेगा जब प्रस्ताव सुलगने वाला हो।

आपको अधिक ट्रिगर्स की ज़रूरत नहीं है। एक सरल सेटअप इस तरह दिखता है:

• जब प्रस्ताव Sent में जाता है, तो फॉलो-अप तारीख आवश्यक करें।
• फॉलो-अप तारीख पर एक रिमाइंडर भेजें।
• अगर Sent में X दिनों तक कोई जवाब नहीं आता, तो स्वचालित रूप से एक फॉलो-अप टास्क बनाएं।

रिमाइंडर टेक्स्ट छोटा और कार्रवाई-केंद्रित रखें। केवल कौन, किस बारे में, और अगला कदम शामिल करें:

• "Follow up with {Client}: {Proposal} - quick check-in"
• "{Client} / {Proposal} - ask if they want changes before approval"
• "{Client} / {Proposal} - confirm timeline and start date"

गार्डरेल जोड़ें ताकि यह शोर न बने: प्रति प्रस्ताव प्रति दिन एक रिमाइंडर तक सीमित करें, और Snooze विकल्प दें (1 दिन, 3 दिन, अगला सप्ताह)।

हर रिमाइंडर पर क्या हुआ यह भी ट्रैक करें। एक छोटा आउटकम लॉग स्टोर करें: completed, snoozed (कब तक), skipped, या sent।

उदाहरण: आप "Website refresh - Acme Co" को सोमवार को Sent मार्क करते हैं और फॉलो-अप गुरुवार के लिए सेट करते हैं। गुरुवार सुबह आपको एक रिमाइंडर मिलता है और आप उसे शुक्रवार तक snooze कर देते हैं। शुक्रवार को आप फॉलो-अप करते हैं, रिमाइंडर को पूरा मार्क करते हैं, और "Sent में X दिन बाद कोई जवाब नहीं" टाइमर रीसेट हो जाता है।

सेवा प्रकार द्वारा क्लोज़ रेट ट्रैक करें (और संख्याओं का उपयोग करें)

एक प्रस्ताव पाइपलाइन ऐप तभी मूल्यवान है जब यह आपको निर्णय लेने में मदद करे। सबसे आसान तरीका है सेवा प्रकार के अनुसार क्लोज़ रेट ट्रैक करना, सिर्फ कुल मिलाकर नहीं। "Website redesign" और "monthly maintenance" अक्सर अलग व्यापार की तरह व्यवहार करते हैं।

पहले, परिणामों को सुसंगत बनाएं:

• Won का मतलब स्पष्ट हाँ है (साइन किया हुआ एग्रीमेंट, अग्रिम भुगतान, या पुष्टि की गई शुरूआत तारीख)।
• Lost का मतलब है आप इसे आगे नहीं बढ़ा रहे (उन्होंने ना कहा, किसी और को चुना, या यह इतना निष्क्रिय रहा कि आप इसे मृत मान लें)।

एक नियम चुनें और उसे लागू रखें, वरना आपकी संख्याएँ शोर बन जाएंगी।

नुकसान के कारण छोटे और सुसंगत रखें:

• Price
• Timing
• Scope mismatch
• No response
• Chose competitor

फिर क्लोज़ रेट प्रति सर्विस टाइप की गणना करें उन विंडो पर जो आप उपयोग करते हैं (पिछले 30 या 90 दिन)। अगर आपने 12 "Brand strategy" प्रस्ताव भेजे और 3 जीते, तो वह 25% है। अगर आपने 6 "Landing page builds" भेजे और 4 जीते, तो यह 67% है। यह परफेक्ट नहीं होना चाहिए, बस स्थिर रखें।

"टाइम टू क्लोज़" जोड़ें ताकि आप ईमानदार रहें। Sent से Won या Lost तक के दिन ट्रैक करें। आप सीख सकते हैं कि "SEO audit" 5-10 दिन में बंद होता है, जबकि "Full website rebuild" 30-45 दिन लेता है। यह फॉलो-अप की आवृत्ति और आय का पूर्वानुमान बदल सकता है।

संख्याओं को एक सरल नियम के साथ actionable बनाएं। अगर किसी सर्विस की क्लोज़ रेट कम है और टाइम टू क्लोज़ लंबा है, तो ऑफर को तंग करें (स्कोप, प्रूफ़, प्राइसिंग) या प्रोजेक्ट से पहले कड़ी क़्वालिफ़ाइ करें। अगर किसी सर्विस की क्लोज़ रेट ऊँची है, तो उसे बचाएँ: जो काम कर रहा है उसे दोहराएँ और सावधानी से कीमत बढ़ाएँ।

प्रस्ताव CRM बनाते समय सामान्य जाल

प्रस्ताव पाइपलाइन ऐप बेकार बनाने का सबसे तेज़ तरीका है इसे भ्रमित करना। फ्रीलांसर अच्छी नियत से शुरू करते हैं, फिर एक ऐसे टूल में पहुंचते हैं जिस पर वे भरोसा नहीं करते।

एक जाल बहुत सारे स्टेटस होना है जिनका अर्थ एक ही हो। अगर आप "Sent", "Submitted", "Delivered", और "In review" के बीच का फर्क एक वाक्य में समझा नहीं पा रहे, तो संभावना है कि आपको सिर्फ एक चाहिए।

एक और जाल Sent को कब्रिस्तान बनने देना है। अगर आप फॉलो-अप तारीख नहीं माँगते, तो बाद में बोर्ड खोलेंगे और कई प्रस्ताव बिना अगले कदम के देखेंगे। एक सरल नियम ज्यादातर समस्या सुलझा देता है: Sent में हर प्रस्ताव के पास एक अगला कदम तय होना चाहिए।

कुछ और गलतियाँ जो ध्यान भटका सकती हैं:

• प्रस्तावों को सामान्य लीड्स के साथ मिलाना, ताकि आपका पाइपलाइन एक रैंडम इनबॉक्स बन जाए
• Lost कारण लॉग न करना, ताकि आप वही प्राइसिंग और स्कोप की गलती दोहराएँ
• शुरुआती चरण में अत्यधिक ऑटोमेशन करना, और रिमाइंडर्स ट्यून करने में अधिक समय बिताना बजाय प्रस्ताव भेजने के

रिमाइंडर्स को उबाऊ और विशिष्ट रखें। एक फॉलो-अप तारीख से जुड़ा एक रिमाइंडर आमतौर पर काफी है। और अधिक नियम तब तक इंतज़ार कर सकते हैं जब तक कि आपके पास एक महीने का असली उपयोग डेटा न हो।

अगर आप तीन प्रस्ताव लगातार खो देते हैं और नोट में लिखा है "timeline too long", तो संकेत है कि एक छोटा पहला चरण ऑफर करें, न कि पांच नए स्टेटस जोड़ें।

भरोसा करने से पहले तेज़ चेकलिस्ट

पहले कि आप अपनी पाइपलाइन ऐप को सिंगल सोर्स ऑफ ट्रूथ मानें, यह सुनिश्चित करें कि कुछ भी अटके न रहे और अगला कदम स्पष्ट हो।

पाइपलाइन व्यू खोलें और खुद को टाइम करें। आपको 30 सेकंड में आज की प्राथमिकताएँ समझ आ जानी चाहिए। अगर आपको अगला कदम जानने के लिए कई प्रस्तावों में क्लिक करना पड़ता है, तो आपका डिज़ाइन सबसे महत्वपूर्ण फ़ील्ड को छुपा रहा है।

चेकलिस्ट:

• हर ओपन प्रस्ताव स्पष्ट स्टेटस और अगली फॉलो-अप तारीख दिखाता है। अगर कोई अगला कदम नहीं है, तो उसे बंद कर दें।
• आपका "आज" व्यू ऐसी कार्रवाइयाँ दिखाता है जिन्हें आप अब कर सकते हैं (फॉलो-अप, भेजना, संशोधन), सिर्फ तनाव की सूची नहीं।
• जब कुछ Won या Lost बनता है, आप अंतिम राशि और एक छोटा कारण कैप्चर करते हैं।
• सर्विस टाइप द्वारा क्लोज़ रेट हाल की विंडो (30-90 दिन) के लिए दिखता है।
• रिमाइंडर snooze किए जा सकते हैं, और उसी दिन एक ही प्रस्ताव के लिए डुप्लिकेट नहीं आते।

एक छोटा स्ट्रेस टेस्ट करें। तीन नमूना प्रस्ताव बनाएं विभिन्न सेवाओं के लिए, उन्हें स्टेटस में मूव करें, और रिमाइंडर ट्रिगर करें। अगर आप इसे पाँच मिनट में तोड़ सकते हैं, तो व्यस्त सप्ताह में भी आप इसे तोड़ देंगे।

उदाहरण: प्रस्तावों का एक सरल सप्ताह (और आप क्या सीखते हैं)

सोमवार को आप पांच प्रस्ताव भेजते हैं। तीन वेब रीडिज़ाइन पैकेज के हैं, और दो मासिक सपोर्ट रिटेनर के। सब कुछ Draft से शुरू होता है, फिर ईमेल जाने पर Sent में चला जाता है।

बुधवार तक स्टेटस कहानी बताते हैं:

• दो रीडिज़ाइन प्रस्ताव Viewed में चले गए (आपने देखा कि क्लाइंट ने डॉक खोल दिया)
• एक रीडिज़ाइन प्रस्ताव अभी भी Sent पर है (कोई व्यू नहीं)
• एक रिटेनर प्रस्ताव Negotiating में चला गया (उन्होंने घंटे समायोजित करने के लिए कहा)
• एक रिटेनर प्रस्ताव Won में चला गया (उन्होंने साइन किया)

रिमाइंडर्स आपको गेंद छोड़ने से बचाते हैं। "Viewed but no reply in 2 days" नियम आपको शुक्रवार सुबह दो रीडिज़ाइन लीड्स को फॉलो-अप करने के लिए प्रेरित करता है। "Sent but not viewed in 3 days" नियम शांत एक पकड़ करता है, ताकि आप छोटा संदेश भेजकर स्पष्ट अगला कदम दें।

हकीकत गन्दा है। एक क्लाइंट रविवार को देर से जवाब देता है "माफ़, व्यस्त सप्ताह था" और अगले महीने शुरू करने को कहता है, इसलिए आप उसे On Hold में रखते हैं बजाय Sent में सड़ने देने के। नेगोशिएशन सक्रिय रहता है, पर रिमाइंडर एक बार चेक करता है, हर दिन नहीं।

सप्ताह के अंत तक, सर्विस टाइप द्वारा क्लोज़ रेट आँखें खोल देता है: सपोर्ट रिटेनर 1/2 जीता, वेब रीडिज़ाइन 0/3। अगले सप्ताह आप एक बात बदलते हैं: रीडिज़ाइन स्कोप को दो टियर में कसते हैं और फीडबैक के लिए एक सरल डेडलाइन जोड़ते हैं।

अगले कदम: एक छोटा वर्शन भेजें, फिर सुधार करें

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

अपने स्टेटस ऐसे सेट करें कि हर एक सीधे जवाब दे: "अब किस कार्रवाई की उम्मीद है?" अगर आप किसी स्टेटस को एक वाक्य में समझा नहीं सकते, तो वह आपको धीमा करेगा।

इस सप्ताह के तीन काम:

• 5 से 7 स्टेटस सेट करें (अधिकांशतः Draft, Sent, Follow-up due, Negotiating, Won, Lost पर्याप्त होते हैं)
• एक बोर्ड व्यू बनाएं ताकि आप सेकेंडों में स्टेटस बदल सकें
• केवल उन मामलों के लिए रिमाइंडर चालू करें जो मायने रखते हैं (Follow-up due, और Negotiating तब जब अगला कदम आप पर हो)

जब बेसिक लूप नेचुरल लगे, तो सुधार एक-एक करके जोड़ें। एक अच्छा क्रम है: पहले रिमाइंडर्स (ताकि कुछ स्लीप न करे), फिर रिपोर्टिंग (ताकि आप सीखें), और बाद में टेम्प्लेट (ताकि समय बचे)। अगर आप सब कुछ एक साथ जोड़ देंगे, तो आप नहीं जान पाएँगे कौन सी चीज़ मदद कर रही है और क्या शोर बन गया है।

अगर आप बिना ज़्यादा कोडिंग के बनाना चाहते हैं, AppMaster (appmaster.io) एक व्यावहारिक विकल्प है: आप डेटाबेस मॉडल (clients, proposals, services) बना सकते हैं और UI और स्टेटस नियम एक ही जगह में बना कर इटररेट कर सकते हैं क्योंकि आपकी प्रक्रिया बदलती है।

छोटे और मापनीय अपग्रेड रखें। एक सप्ताह बाद पूछें: क्या मैंने तेज़ी से फॉलो-अप किया, और क्या मैंने कम रिप्लाई मिस किए? एक महीने बाद पूछें: कौन सी सर्विस सबसे अच्छा क्लोज़ करती है, और किसे बेहतर ऑफर या ऊँची कीमत चाहिए?

पहला वर्शन व्यक्तिगत टूल की तरह मानें, न कि प्रोडक्ट। अगर नया प्रस्ताव जोड़ने या उसे आगे बढ़ाने में 30 सेकंड से अधिक लगता है, तो फ़ील्ड्स और स्क्रीन को सरल करें इससे पहले कि आप कुछ और जोड़ें। जब यह सहज लगेगा, तब आप वास्तव में इसका उपयोग करेंगे और डेटा भरोसेमंद रहेगा।