ग्राहक ऑनबोर्डिंग ट्रैकर: B2B हैंडऑफ व्यवस्थित करें

B2B ऑनबोर्डिंग का काम समझना मुश्किल क्यों हो जाता है

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

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

ज़िम्मेदारी स्पष्ट न होने से भी यही समस्या आती है। «डेटा फ़ील्ड की पुष्टि करें» वाली पंक्ति यह नहीं बताती कि ग्राहक, अकाउंट मैनेजर या इम्प्लीमेंटेशन विशेषज्ञ में से किसे कार्रवाई करनी है। लोग मान लेते हैं कि कोई और इसे संभाल रहा है और काम बिना छुए पड़ा रहता है।

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

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

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

ट्रैकर बातचीत की जगह नहीं लेता। वह बातचीत को छोटा और उपयोगी बनाता है। «इस अकाउंट की स्थिति क्या है?» पूछने के बजाय टीम देख सकती है कि किस काम पर निर्णय चाहिए, फॉलो-अप किसे करना है और ग्राहक को अगली जानकारी क्या देनी है।

अपने ऑनबोर्डिंग ट्रैकर में क्या शामिल करें

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

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

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

स्थितियों के लिए कम और ऐसे लेबल इस्तेमाल करें जिनका मतलब सभी के लिए एक जैसा हो:

• शुरू नहीं हुआ
• जारी है
• ग्राहक की प्रतीक्षा में
• अटका हुआ
• पूरा

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

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

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

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

ट्रैकर चरण दर चरण बनाएँ

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

काम को ऐसे टास्क में बाँटें जिन्हें कोई व्यक्ति पूरा करके पूर्ण चिह्नित कर सके। «ग्राहक तैयार करें» बहुत अस्पष्ट है। «मंज़ूर की गई उपयोगकर्ता सूची लें» टीम को वास्तविक कार्रवाई और स्पष्ट समाप्ति बिंदु देता है।

एक सामान्य टेम्पलेट में ये काम हो सकते हैं:

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

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

लक्षित लॉन्च से पीछे की ओर तारीखें तय करें। अगर ग्राहक 30 जून को लाइव होना चाहता है, तो लॉन्च समीक्षा उससे कुछ दिन पहले, ट्रेनिंग समीक्षा से पहले और एक्सेस सेटअप शुरुआत के करीब रखें। इससे देरी पहचानना आसान होता है। अस्पष्ट शुरुआत की तारीख से यह पता नहीं चलता कि कौन-सा काम अब लॉन्च के लिए खतरा बन रहा है।

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

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

टास्क इस तरह व्यवस्थित करें कि लोग कार्रवाई कर सकें

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

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

अकाउंट व्यू और वर्कलोड व्यू इस्तेमाल करें

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

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

उदाहरण के लिए, «Northwind के लिए SSO कॉन्फ़िगर करें» Northwind के सेटअप चरण में रहेगा, इम्प्लीमेंटेशन विशेषज्ञ के वर्कलोड में दिखाई देगा और शुक्रवार तक पूरे होने वाले साप्ताहिक कामों की सूची में भी आ सकता है। एक ही रिकॉर्ड पर्याप्त है।

काम का इतिहास बनाए रखें

पूरे हुए कामों को ग्राहक रिकॉर्ड में रहने दें। वे आम सवालों का जवाब देते हैं: ट्रेनिंग किसने कराई? ग्राहक ने टेस्ट वातावरण को कब मंज़ूर किया? किकऑफ के दौरान टीम ने क्या तय किया? पूरे हुए कामों को स्पष्ट रूप से चिह्नित करें, ताकि वे सक्रिय कामों में बाधा न बनें, लेकिन उन्हें मिटाएँ नहीं।

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

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

उदाहरण:

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

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

रुकावटों को जल्दी स्पष्ट करें

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

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

हर अटके हुए काम के लिए दर्ज करें:

• क्या रुका है और क्यों
• देरी आंतरिक है या ग्राहक की ओर से
• रुकावट कब शुरू हुई
• अगली कार्रवाई के लिए कौन ज़िम्मेदार है
• अगला फॉलो-अप कब होगा

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

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

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

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

ग्राहक को स्पष्ट अपडेट साझा करें

ग्राहकों को टीम के पूरे ट्रैकर की कॉपी नहीं चाहिए। उन्हें प्रगति, अपने अगले निर्णय और अगली प्रगति की अपेक्षित तारीख का स्पष्ट व्यू चाहिए। छोटा और नियमित अपडेट स्टेटस ईमेल कम करता है और अलग-अलग धारणाओं के आधार पर काम करने से रोकता है।

हर बार एक ही चार हिस्सों वाला प्रारूप इस्तेमाल करें:

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

क्लाइंट इम्प्लीमेंटेशन अपडेट तय कार्यक्रम के अनुसार भेजें। कई B2B ऑनबोर्डिंग प्रोजेक्ट के लिए साप्ताहिक अपडेट उपयोगी होता है, जबकि छोटे इम्प्लीमेंटेशन में हर माइलस्टोन के बाद छोटा संदेश पर्याप्त हो सकता है। समस्या आने तक प्रतीक्षा न करें। नियमित अपडेट से देरी पर बात करना आसान होता है, क्योंकि ग्राहक पहले से प्रोजेक्ट की स्थिति समझता है।

आंतरिक काम को ग्राहक के व्यू से अलग रखें। टीम के नोट्स में अनिश्चित अनुमान, हैंडऑफ की समस्या या यह चर्चा हो सकती है कि काम किसे ठीक करना चाहिए। ये विवरण टीम को कार्रवाई में मदद करते हैं, लेकिन योजना बनने से पहले ग्राहक को भ्रमित कर सकते हैं। जब आंतरिक रुकावट ग्राहक की कार्रवाई, समय या दायरे पर असर डाले, तभी उसे ग्राहक के साथ साझा करें।

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

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

उदाहरण: एक ग्राहक इम्प्लीमेंटेशन को ट्रैक करना

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

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

रुकावट से योजना बदलती है

मंगलवार को तकनीकी विशेषज्ञ Northstar के IT संपर्क से सिंगल साइन-ऑन विवरण माँगता है। काम «ग्राहक की प्रतीक्षा में» स्थिति में चला जाता है और देय तारीख गुरुवार रखी जाती है। विशेषज्ञ लिखता है: «IT की Priya से आइडेंटिटी प्रोवाइडर मेटाडेटा और एक टेस्ट अकाउंट चाहिए।»

शुक्रवार तक विवरण नहीं आते। इम्प्लीमेंटेशन लीड साप्ताहिक व्यू में रुकावट देखता है और प्रस्तावित लॉन्च को 18 जून से 25 जून कर देता है। वह ट्रेनिंग और अंतिम टेस्टिंग की तारीखें भी बदलता है, बजाय इसके कि ओवरड्यू कामों की ऐसी श्रृंखला छोड़ दे जिसे कोई समझ न सके।

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

तकनीकी काम अपने ऊपर लिए बिना प्रगति देखें

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

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

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

ऐसी गलतियाँ जो ट्रैकर को कम उपयोगी बनाती हैं

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

अस्पष्ट ज़िम्मेदारी और अलग-थलग तारीखें

काम «सपोर्ट», «इंजीनियरिंग» या «ग्राहक» को न सौंपें। कोई विभाग सवाल का जवाब नहीं दे सकता या काम को आगे नहीं बढ़ा सकता। हर काम पर एक नामित ज़िम्मेदार व्यक्ति रखें, भले ही कई लोग योगदान दें। वह व्यक्ति मदद माँग सकता है, स्थिति अपडेट कर सकता है और अगला कदम बता सकता है।

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

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

छिपे अपडेट और बहुत लंबे फ़ॉर्म

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

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

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

उपयोगी ट्रैकर हमेशा अपडेट रहता है, क्योंकि लोग उसे एक मिनट से कम समय में बदल सकते हैं। अगर टीम उससे बचकर चैट या स्प्रेडशीट पर लौटती है, तो और ऑटोमेशन जोड़ने से पहले फ़ील्ड कम करें।

साप्ताहिक ऑनबोर्डिंग समीक्षा से पहले जल्दी जाँच

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

हर खुले काम से शुरुआत करें। हर टास्क के लिए एक नामित ज़िम्मेदार व्यक्ति और वास्तविक देय तारीख होनी चाहिए। अगर दो लोगों का योगदान चाहिए, तो अलग-अलग काम बनाएँ और दोनों को तारीख दें।

समीक्षा से पहले यह छोटी चेकलिस्ट इस्तेमाल करें:

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

अगर टीम ने मंगलवार को डेटा मैपिंग पूरी कर ली है, लेकिन ग्राहक ने एक्सेस विवरण नहीं भेजे हैं, तो ट्रैकर में «ग्राहक: एक्सेस विवरण दें» अगली कार्रवाई के रूप में दिखना चाहिए। इसमें यह भी दिखना चाहिए कि ग्राहक को याद कौन दिलाएगा और कब।

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

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

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

अपना अगला ऑनबोर्डिंग चक्र सेट अप करें

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

हर ग्राहक के लाइव होने के बाद 15 मिनट ट्रैकर की समीक्षा में लगाएँ। जिन कामों का किसी ने इस्तेमाल नहीं किया उन्हें हटाएँ, टीम ने जिन्हें बार-बार ट्रैकर के बाहर संभाला उन्हें जोड़ें और भ्रम पैदा करने वाले नाम स्पष्ट करें। «एक्सेस सेट अप करें» अस्पष्ट है। «ग्राहक एडमिन उपयोगकर्ताओं और एक्सेस भूमिकाओं की पुष्टि करता है» ज़िम्मेदार व्यक्ति को बताता है कि पूरा होने का मतलब क्या है।

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

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

एक सरल कार्य समझौता मदद करता है:

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

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

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