प्रोफ़ेशनल सर्विसेज़ फ़र्मों के लिए इंटेक ऐप: एक व्यावहारिक योजना

बिखरी हुई इंटेक प्रक्रिया से होने वाली देरी से बचें

किसी नए क्लाइंट का अनुरोध अक्सर ईमेल से शुरू होता है और फिर फ़ॉरवर्ड किए गए संदेशों, कॉल नोट्स और बाद में अपडेट की गई स्प्रेडशीट में फैल जाता है। कंपनी का नाम एक जगह होता है, प्रोजेक्ट का दायरा दूसरी जगह और वादा की गई समयसीमा इनबॉक्स में दब जाती है। स्टाफ को ऐसी जानकारी फिर से माँगनी पड़ती है जो क्लाइंट पहले ही किसी और को दे चुका होता है।

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

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

प्रोफ़ेशनल सर्विसेज़ फ़र्मों के लिए इंटेक ऐप पहली पूछताछ से ही ज़रूरी जानकारी को एक साझा रिकॉर्ड में रखता है। हर अनुरोध की स्पष्ट स्थिति होती है, जैसे नया, कॉन्फ्लिक्ट समीक्षा की प्रतीक्षा में, मंज़ूर या असाइन किया गया। टीम ईमेल से पूरी कहानी दोबारा बनाने के बजाय मौजूदा जानकारी देखती है।

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

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

यह साझा रिकॉर्ड ईमेल खंगालने की ज़रूरत हटाकर एक दोहराई जा सकने वाली हैंडऑफ प्रक्रिया देता है। मैनेजर खुले अनुरोध, उनकी वर्तमान स्थिति और अगले कदम के ज़िम्मेदार व्यक्ति भी देख सकते हैं।

शामिल लोगों और निर्णयों का नक्शा बनाएँ

हर अनुरोध के लिए फ़र्म के भीतर एक स्पष्ट रास्ता होना चाहिए। फ़ील्ड या स्क्रीन बनाने से पहले तय करें कि अनुरोध पर कौन-कौन काम करेगा और हर व्यक्ति को कौन सा निर्णय लेना है। इससे साझा इनबॉक्स की वह आम समस्या दूर होती है जिसमें हर कोई मानता है कि कोई दूसरा जवाब देगा।

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

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

क्लाइंट के सवालों को आंतरिक नोट्स से अलग रखें

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

इससे संवेदनशील जानकारी सुरक्षित रहती है और फ़ॉर्म कम डरावना लगता है। बातचीत शुरू करने के लिए क्लाइंट को फ़र्म की कॉन्फ्लिक्ट समीक्षा प्रक्रिया समझने की ज़रूरत नहीं है।

वर्कफ़्लो बनाने से पहले देखने की अनुमति तय करें:

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

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

हर चरण की एक ज़िम्मेदारी तय करें

हर चरण के लिए एक ज़िम्मेदार व्यक्ति तय करें, भले ही कई लोग मदद कर सकते हों। उसे रिमाइंडर मिलना चाहिए और वही अनुरोध को आगे बढ़ाए, अधिक जानकारी के लिए वापस भेजे या बंद करे। साझा ज़िम्मेदारी से अक्सर काम बिना देखरेख के रह जाता है।

एक सरल फ़्लो में इंटेक कोऑर्डिनेटर को पूर्णता जाँच, कॉन्फ्लिक्ट टीम को समीक्षा, प्रैक्टिस लीड को मंज़ूरी और प्रोजेक्ट मैनेजर को हैंडऑफ की ज़िम्मेदारी दी जा सकती है। अनुरोध में वर्तमान चरण और नामित ज़िम्मेदार व्यक्ति दोनों दर्ज करें।

AppMaster भूमिकाओं, अनुमतियों और हैंडऑफ को विज़ुअल तरीके से मॉडल कर सकता है। इससे टीमें किसी सामान्य फ़ॉर्म की नकल करने के बजाय अपने वास्तविक निर्णयों के अनुसार क्लाइंट इंटेक वर्कफ़्लो बना सकती हैं।

प्रोजेक्ट से जुड़ी जानकारी चुनें

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

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

समस्या का सामान्य भाषा में वर्णन माँगें। «आपको किस मदद की ज़रूरत है और आप किस परिणाम की उम्मीद करते हैं?» जैसा सवाल «प्रोजेक्ट विवरण» नाम वाले बड़े बॉक्स से बेहतर जवाब दिलाता है। जवाब से कड़ी लॉन्च तारीख, नियामक समस्या या कई क्षेत्रों में होने वाला काम सामने आ सकता है।

समय और दायरा जल्दी दर्ज करें

तारीखें स्टाफिंग और जवाब की प्राथमिकता को प्रभावित करती हैं। वांछित शुरुआत की तारीख, कोई पक्की समयसीमा और तात्कालिकता का सरल विकल्प पूछें। «जितनी जल्दी हो सके» जैसे अस्पष्ट विकल्पों से बचें। ऐसे विकल्प दें जिन्हें लोग एक ही तरह समझ सकें, जैसे «48 घंटे के भीतर», «इस सप्ताह» या «कोई निश्चित समयसीमा नहीं»।

स्थान से असाइन की गई टीम, यात्रा की ज़रूरत, लागू नियम या काम के तरीके पर असर पड़ सकता है। जहाँ ज़रूरी हो, प्रोजेक्ट का स्थान पूछें। इसके बाद अपेक्षित डिलीवेरेबल्स को सरल शब्दों में दर्ज करें: लिखित राय, कार्यशाला, फाइलिंग, कार्यान्वयन योजना, लगातार सहायता या कोई अन्य सहमत परिणाम।

एक व्यावहारिक प्रोजेक्ट इंटेक फ़ॉर्म में अक्सर ये चीज़ें होती हैं:

• क्लाइंट संगठन और प्रोजेक्ट का नाम
• माँगी गई सेवा और छोटा सारांश
• वांछित शुरुआत की तारीख, समयसीमा और तात्कालिकता
• संबंधित स्थान या अधिकार क्षेत्र
• अपेक्षित डिलीवेरेबल्स और ज्ञात सीमाएँ

अनिवार्य फ़ील्ड कम रखें

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

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

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

क्लाइंट कॉन्टैक्ट्स को अनुरोध से जोड़कर रखें

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

एक मुख्य कॉन्टैक्ट से शुरुआत करें। पूरा नाम, कार्य ईमेल, फ़ोन नंबर, पद और पसंदीदा संपर्क तरीका लें। कॉल करने से पहले पुराने संदेश खोजने के बजाय स्टाफ को ये विवरण अनुरोध रिकॉर्ड के ऊपर ही दिखाई देने चाहिए।

हर व्यक्ति की भूमिका दर्ज करें

बातचीत आगे बढ़ने पर स्टाफ को नए कॉन्टैक्ट जोड़ने दें। हर कॉन्टैक्ट संगठन और प्रोजेक्ट अनुरोध दोनों से जुड़ा होना चाहिए।

उपयोगी लेबल में ये शामिल हैं:

• मुख्य कॉन्टैक्ट या रोज़मर्रा का समन्वयक
• दायरे या समय के निर्णय लेने वाला
• बिलिंग कॉन्टैक्ट
• पहुँच या आवश्यकताओं के लिए तकनीकी कॉन्टैक्ट
• अनुबंधों के लिए कानूनी या प्रोक्योरमेंट कॉन्टैक्ट

इन लेबल से आम हैंडऑफ गलतियाँ रुकती हैं, जैसे प्रस्ताव ऐसे व्यक्ति को भेजना जो उसे मंज़ूर नहीं कर सकता या इनवॉइस उस व्यक्ति को भेजना जिसने केवल मीटिंग माँगी थी। एक कॉन्टैक्ट एक से अधिक भूमिकाएँ निभा सकता है, इसलिए ज़रूरत पड़ने पर कई लेबल की अनुमति दें।

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

संगठन बनाने से पहले उसकी जाँच करें

स्टाफ से कहें कि नया रिकॉर्ड बनाने से पहले संगठन को खोजें। कंपनी के नाम, ईमेल डोमेन और जहाँ उपलब्ध हो, फ़ोन नंबर के आधार पर मिलान करें। इससे «Acme Ltd» और «Acme Limited» जैसे छोटे अंतर पकड़े जाते हैं, जो एक ही क्लाइंट के दो रिकॉर्ड बना सकते हैं।

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

AppMaster का Data Designer संगठनों, कॉन्टैक्ट्स और अनुरोधों को जुड़े रिकॉर्ड के रूप में मॉडल कर सकता है। स्टाफ मूल अनुरोध से संबंध बनाए रखते हुए वेब या मोबाइल फ़ॉर्म से कॉन्टैक्ट्स जोड़ सकता है।

ऐसी कॉन्फ्लिक्ट समीक्षा बनाएँ जिसे लोग आसानी से अपना सकें

कॉन्फ्लिक्ट जाँच के लिए केवल टेक्स्ट बॉक्स और ईमेल थ्रेड पर्याप्त नहीं हैं। इंटेक ऐप को ऐसे नाम और विवरण जुटाने चाहिए जिनसे समीक्षक नए अनुरोध की तुलना वर्तमान और पुराने काम से कर सकें।

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

कॉन्फ्लिक्ट की जानकारी को सामान्य इंटेक विवरण से अलग रखें। प्रोजेक्ट विवरण या बजट सीमा की तुलना में कॉन्फ्लिक्ट रिकॉर्ड पर अधिक सख्त पहुँच नियंत्रण होना चाहिए। इन्हें केवल जाँच करने और क्लियरेंस का निर्णय लेने वाले लोगों तक सीमित रखें।

समीक्षा की स्थिति स्पष्ट रखें

हर अनुरोध को एक दिखाई देने वाली स्थिति दें, जो समीक्षा आगे बढ़ने पर बदलती रहे। जब स्टाफ को यह जानना हो कि अगला कदम किसे लेना है, तब «समीक्षा में» जैसे अस्पष्ट लेबल से बचें।

• लंबित: अनुरोध में इतना विवरण है कि समीक्षक काम शुरू कर सकता है।
• क्लियर: समीक्षक को ऐसा कोई कॉन्फ्लिक्ट नहीं मिला जो काम रोकता हो।
• फॉलो-अप आवश्यक: समीक्षक को अधिक तथ्य या मंज़ूरी चाहिए।
• अवरुद्ध: फ़र्म के कॉन्फ्लिक्ट नियमों के तहत अनुरोध स्वीकार नहीं किया जा सकता।

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

निर्णय का छोटा रिकॉर्ड रखें

हर निर्णय में समीक्षक का नाम, तारीख, स्थिति और सामान्य भाषा में कारण का स्थायी रिकॉर्ड बनना चाहिए। उदाहरण: «14 मई को J. Patel ने क्लियर किया। किसी सहयोगी संस्था के लिए पुराना काम 2022 में समाप्त हो गया था, वर्तमान में कोई विरोधी मामला नहीं मिला।»

जब प्रोजेक्ट लीड पूछे कि इंटेक क्यों रुका या कोई दूसरा समीक्षक काम संभाले, तो इससे समय बचता है। कारण छोटा और तथ्यात्मक रखें। कॉन्फ्लिक्ट जाँच का उद्देश्य निर्णय समझाना है, दूसरा केस रिकॉर्ड बनाना नहीं।

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

AppMaster सीमित पहुँच वाली कॉन्फ्लिक्ट टेबल, भूमिका आधारित अनुमति और विज़ुअल Business Process Editor के ज़रिए हर इंटेक को सही समीक्षक तक भेजने में मदद कर सकता है।

बजट पूछें, लेकिन इंटेक को कोटेशन न बनाएँ

बजट से जुड़े सवाल से स्टाफ तय कर सकता है कि अनुरोध फ़र्म के सामान्य काम के दायरे में आता है या नहीं। इससे कीमत का वादा नहीं होना चाहिए। शुरुआती इंटेक में घंटों, दायरे में बदलाव, विशेषज्ञ सहायता या समयसीमा के दबाव का सही अनुमान लगाने के लिए पर्याप्त जानकारी आम तौर पर नहीं होती।

ऐसी सीमाएँ इस्तेमाल करें जो फ़र्म के स्वीकार किए जाने वाले काम के अनुरूप हों। कोई कंसल्टिंग फ़र्म «$10,000 से कम», «$10,000 से $25,000», «$25,000 से $75,000» और «$75,000 से अधिक» जैसे विकल्प दे सकती है। विकल्प इतने व्यापक रखें कि क्लाइंट जल्दी जवाब दे सके।

फ़ील्ड के पास छोटा नोट जोड़ें: «यह सीमा आपके अनुरोध को सही जगह भेजने में हमारी मदद करती है। यह कोटेशन या फीस समझौता नहीं है।» क्लाइंट अपनी बजट क्षमता बता सकता है और फ़र्म फिर भी काम का सही आकलन कर सकती है।

जब बाहरी खर्च काम को प्रभावित करते हों, तो पूछें कि बजट में केवल फ़र्म की फीस शामिल है या बाहरी खर्च भी। इनमें फाइलिंग फीस, यात्रा, विशेषज्ञ ठेकेदार, सॉफ़्टवेयर या अन्य विक्रेता शामिल हो सकते हैं।

अनुमानित सीमा, ज़रूरत पड़ने पर मुद्रा, बजट मंज़ूरी की स्थिति और सीमाओं या प्रोक्योरमेंट नियमों से जुड़ा नोट दर्ज करें। स्टाफ के पास ऐसे अनुरोधों को चिह्नित करने का विकल्प भी होना चाहिए जिनके लिए विस्तृत अनुमान चाहिए। उदाहरण के लिए, जब संभावित क्लाइंट सबसे ऊँची सीमा चुने लेकिन बहुत व्यापक और अस्पष्ट प्रोजेक्ट बताए, तो इंटेक कोऑर्डिनेटर «अनुमान आवश्यक» चुन सकता है।

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

इंटेक फ़्लो चरण दर चरण बनाएँ

एक स्पष्ट इंटेक ऐप को हर अनुरोध को कुछ समान निर्णयों से आगे बढ़ाना चाहिए। स्टाफ को दिखना चाहिए कि अनुरोध की ज़िम्मेदारी किसकी है, किस चीज़ की समीक्षा होनी है और किस समय कार्रवाई करनी है।

अनुरोध रिकॉर्ड से शुरुआत करें

हर संभावित प्रोजेक्ट के लिए एक रिकॉर्ड बनाएँ। इसमें संदर्भ संख्या, क्लाइंट या संगठन का नाम, माँगी गई सेवा और अनुरोध भेजने वाले का नाम रखें। पहली स्थिति «नया» रखें, ताकि टीम बिना समीक्षा वाले काम को सक्रिय अनुरोधों से अलग पहचान सके।

ऐसी स्थितियाँ रखें जो वास्तविक निर्णय बिंदुओं को दिखाएँ:

• नया: फ़र्म को अनुरोध मिला है, लेकिन किसी ने उसकी समीक्षा नहीं की।
• समीक्षा में: कोई व्यक्ति दायरे, कॉन्टैक्ट्स और कॉन्फ्लिक्ट की जाँच कर रहा है।
• क्लाइंट की प्रतीक्षा में: टीम को अधूरी जानकारी चाहिए।
• मंज़ूर: फ़र्म प्रस्ताव तैयार कर सकती है या प्रोजेक्ट खोल सकती है।
• अस्वीकार: फ़र्म काम नहीं लेगी।

सूची छोटी रखें। अगर स्टाफ कुछ सेकंड में स्थिति नहीं चुन सकता, तो लेबल में सुधार की ज़रूरत है।

अनुरोध भेजें, असाइन करें और सूचित करें

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

समीक्षक को नियत तारीख दें और अगले कदम के लिए एक नामित ज़िम्मेदार व्यक्ति तय करें। साझा टीम इनबॉक्स से दृश्यता बढ़ती है, लेकिन ज़िम्मेदारी तय नहीं होती।

सूचनाएँ हमेशा किसी कार्रवाई की ओर इशारा करें, जैसे «कॉन्फ्लिक्ट समीक्षा पूरी करें» या «बजट की जानकारी माँगें»। नया असाइनमेंट मिलने पर समीक्षक को सूचित करें और नियत तारीख बीतने पर इंटेक कोऑर्डिनेटर को सूचना दें।

मंज़ूर काम को अगली प्रक्रिया तक पहुँचाएँ

अनुरोध मंज़ूर होने पर पहले से जुटाई गई जानकारी सुरक्षित रखें। कॉन्टैक्ट सूची, प्रोजेक्ट सारांश, बजट सीमा और समीक्षा नोट्स प्रस्ताव या सक्रिय प्रोजेक्ट रिकॉर्ड में चले जाने चाहिए। स्टाफ को दूसरे फ़ॉर्म में वही जानकारी फिर से नहीं लिखनी चाहिए।

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

क्लाइंट के साथ साझा करने से पहले वास्तविक अनुरोधों के साथ फ़्लो का परीक्षण करें। एक ऐसा अनुरोध शामिल करें जिसमें जानकारी अधूरी हो, एक जिसमें संभावित कॉन्फ्लिक्ट हो और एक जिसे मंज़ूरी मिलती हो। इन मामलों से अस्पष्ट स्थितियाँ, अधूरे रूटिंग नियम और गलत व्यक्ति को भेजी गई सूचनाएँ सामने आती हैं।

उदाहरण: पहली बातचीत से हैंडऑफ तक एक अनुरोध

एक कंसल्टिंग फ़र्म को Northline Foods की ऑपरेशंस डायरेक्टर Maya Chen का ईमेल मिलता है। उनकी कंपनी क्षेत्रीय विस्तार की योजना बना रही है और नए बाज़ारों, सप्लायरों और संचालन लागत का आकलन करने में मदद चाहती है। ईमेल को इधर-उधर फ़ॉरवर्ड करने के बजाय कोऑर्डिनेटर एक इंटेक रिकॉर्ड खोलता है।

कोऑर्डिनेटर Maya को मुख्य कॉन्टैक्ट के रूप में जोड़ता है, फिर Northline के वित्त मैनेजर को जोड़ता है, जो खर्च को मंज़ूरी देगा, और प्रोजेक्ट मैनेजर को भी जोड़ता है, जो रोज़मर्रा के सवाल संभालेगा। इंटेक फ़ॉर्म में विस्तार का क्षेत्र, व्यावसायिक लक्ष्य, लॉन्च की लक्षित तारीख और शुरुआती सीमाएँ दर्ज होती हैं। Maya 30 सितंबर को लक्ष्य तारीख बताती हैं, $75,000 से $100,000 की शुरुआती बजट सीमा देती हैं और लिखती हैं कि फ़र्म को चार सप्ताह के भीतर शुरुआती सिफारिश देनी होगी।

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

अगर समीक्षक अनुरोध को क्लियर करता है, तो कोऑर्डिनेटर उसकी स्थिति «डिस्कवरी के लिए तैयार» कर देता है। अगर समीक्षक को कानूनी या नेतृत्व संबंधी राय चाहिए, तो अनुरोध उचित समीक्षा स्थिति में रहता है और टीम देख सकती है कि कॉल क्यों बुक नहीं हुई। इससे उत्सुक बिक्री बातचीत कॉन्फ्लिक्ट जाँच प्रक्रिया से आगे नहीं निकलती।

इसके बाद कोऑर्डिनेटर रिटेल और सप्लाई चेन विस्तार के अनुभव वाले प्रैक्टिस लीड को असाइन करता है। लीड को क्लाइंट कॉन्टैक्ट्स, अपेक्षित परिणाम, समयसीमा, बजट सीमा और कॉन्फ्लिक्ट निर्णय सहित पूरा अनुरोध मिलता है। डिस्कवरी कॉल के बाद लीड उसी रिकॉर्ड में दायरे से जुड़े नोट्स और प्रस्ताव का निर्णय अपडेट करता है।

AppMaster से बना ऐप फ़ॉर्म, समीक्षा स्थिति, असाइनमेंट और फॉलो-अप काम को एक ही नो-कोड ऐप्लिकेशन में रख सकता है, बजाय इसके कि उन्हें ईमेल थ्रेड्स और स्प्रेडशीट में बाँटा जाए।

इंटेक की आम गलतियों से बचें

इंटेक ऐप को पहली समीक्षा आसान बनानी चाहिए, दूसरा काम नहीं बनाना चाहिए। अधिकांश समस्याएँ अस्पष्ट सवालों, अस्पष्ट अधिकार या सबमिट होने के बाद गायब हो जाने वाले अनुरोधों से आती हैं।

बहुत जल्दी बहुत कुछ न पूछें

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

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

निर्णयों को बिना ज़िम्मेदार व्यक्ति के न छोड़ें

हर नए अनुरोध के लिए एक नामित व्यक्ति तय करें जिसे उसकी समीक्षा करनी हो, उसे आगे बढ़ाना हो या यह बताना हो कि फ़र्म काम क्यों नहीं लेगी। ऐप में उस व्यक्ति का नाम और वर्तमान स्थिति दिखाई देनी चाहिए।

कॉन्फ्लिक्ट निर्णयों पर अधिक सख्त नियंत्रण चाहिए। टीम सदस्य संभावित कॉन्फ्लिक्ट चिह्नित कर सकते हैं और संबंधित कॉन्टैक्ट जोड़ सकते हैं, लेकिन केवल अधिकृत समीक्षक ही उसे क्लियर, अस्वीकार या अतिरिक्त जानकारी के लिए वापस भेज सकें। निर्णय, समीक्षक, तारीख और नोट्स दर्ज करें।

सबमिट किए गए प्रोजेक्ट इंटेक फ़ॉर्म को मंज़ूर प्रोजेक्ट न मानें। सबमिशन का अर्थ है कि फ़र्म को जानकारी मिल गई है। मंज़ूरी के लिए कॉन्फ्लिक्ट समीक्षा, दायरे पर बातचीत और ज़रूरी आंतरिक जाँच के बाद अलग स्थिति बदलनी चाहिए।

पुराने सवाल हमेशा न बनाए रखें

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

ऐसे सवाल हटाएँ जिनसे कोई निर्णय नहीं लिया जाता, काम नहीं बाँटा जाता, कॉन्फ्लिक्ट की जाँच नहीं होती या प्रस्ताव तैयार करने में मदद नहीं मिलती। अगर कोई फ़ील्ड केवल एक प्रैक्टिस एरिया पर लागू होती है, तो उसे तभी दिखाएँ जब अनुरोध भेजने वाला वह क्षेत्र चुने। AppMaster कंडीशनल फ़्लो का समर्थन करता है, जिससे बाकी सभी के लिए स्क्रीन सरल रहती है।

स्पष्ट ज़िम्मेदारी वाला छोटा फ़ॉर्म उस विस्तृत फ़ॉर्म से बेहतर जानकारी देता है जिसे लोग जल्दबाज़ी में भरते हैं।

लॉन्च से पहले जल्दी जाँच करें

फ़र्म में इंटेक ऐप साझा करने से पहले पुष्टि करें कि फ़ॉर्म पहली समीक्षा के लिए पर्याप्त संदर्भ जुटाता है: क्लाइंट की ज़रूरत, सेवा क्षेत्र, संबंधित स्थान या अधिकार क्षेत्र, समय, बजट सीमा और मुख्य कॉन्टैक्ट की जानकारी।

एक परीक्षण अनुरोध खोलें और समीक्षक की तरह उसका पूरा फ़्लो देखें। कॉन्फ्लिक्ट जाँच प्रक्रिया में स्पष्ट स्थिति, नामित समीक्षक और दर्ज किया गया निर्णय होना चाहिए। हर अनुरोध में एक वर्तमान ज़िम्मेदार व्यक्ति और नियत तारीख भी होनी चाहिए। जैसे-जैसे काम बिज़नेस डेवलपमेंट से प्रैक्टिस लीड या डिलीवरी टीम तक जाता है, ज़िम्मेदारी बदल सकती है, लेकिन ऐप को हमेशा यह दिखाना चाहिए कि अगली कार्रवाई कौन करेगा।

कई कॉन्टैक्ट्स, कड़ी समयसीमा, संभावित कॉन्फ्लिक्ट और अधूरी बजट जानकारी वाला वास्तविक परीक्षण मामला इस्तेमाल करें। जाँचें कि ऐप उसे सही समीक्षक तक भेजता है, कॉन्फ्लिक्ट क्लियर होने से पहले हैंडऑफ रोकता है और नोट्स उसी रिकॉर्ड में रखता है। स्टाफ से फ़्लो आज़माने को कहें, फिर अस्पष्ट लेबल और अनावश्यक फ़ील्ड सुधारें।

ऐसे इंटेक ऐप के लिए जिसमें साधारण प्रोजेक्ट इंटेक फ़ॉर्म से अधिक सुविधाएँ चाहिए, AppMaster फ़ॉर्म, बिज़नेस नियम और वेब या मोबाइल पहुँच के लिए एक नो-कोड वर्कस्पेस देता है। टीमें अनुरोध और कॉन्टैक्ट रिकॉर्ड मॉडल कर सकती हैं, विज़ुअल Business Process Editor में समीक्षा चरण बना सकती हैं और अलग-अलग स्प्रेडशीट संभाले बिना ऐप्लिकेशन तैयार कर सकती हैं।

सबसे छोटे ऐसे फ़्लो से शुरुआत करें जिसे आपकी टीम लगातार अपना सके। फ़ील्ड और नियम तभी जोड़ें जब स्टाफ समझा सके कि उनका किसी निर्णय या अगले कदम पर क्या असर पड़ता है।