HubSpot / व्यावहारिक गाइड
HubSpot CRM ऑडिट: निष्कर्षों से प्राथमिकता वाली कार्यसूची तक
HubSpot डेटा, प्रॉपर्टी, जीवनचक्र चरण, वर्कफ़्लो और रिपोर्ट जाँचें। प्रमाण से CRM निष्कर्षों को जिम्मेदार व्यक्ति वाली प्राथमिकता-आधारित कार्यसूची में बदलें।
संक्षेप में
HubSpot खाते का ऑडिट इन नौ चरणों में करें: पहुँच तय करें, शुरुआती माप सुरक्षित रखें, डेटा और प्रॉपर्टी जाँचें, स्टेज और ऑटोमेशन का रास्ता देखें, इंटीग्रेशन जाँचें, रिपोर्ट मिलाएँ और परीक्षण योग्य बदलाव योजना बनाएँ। चलते-चलते साक्ष्य लिखें। ऑडिट खाते का निदान करता है; सुधार समीक्षा की गई योजना के अनुसार होते हैं।
- निष्कर्ष दोहराकर जाँचने के लिए सेव किए व्यू और रिकॉर्ड ID इस्तेमाल करें।
- रिकॉर्ड बनने के स्रोत से ऑटोमेशन और रिपोर्ट तक उसका रास्ता देखें।
- प्रॉपर्टी, वर्कफ़्लो या सिंक बदलने से पहले निर्भरताएँ और अपवाद जाँचें।
खाली टेम्पलेट। इसे अपने स्प्रेडशीट टूल में खोलें और चरणों पर काम करते हुए प्रमाण दर्ज करें।
शुरू करने से पहले: इस ऑडिट का दायरा समझें
कल्पना करें कि आपने एक सरल सवाल के लिए HubSpot खोला: हमारे पास कितनी योग्य पाइपलाइन है? दो डैशबोर्ड अलग जवाब देते हैं। कोई तीसरा बनाने को कहता है। संग्रह और बढ़ने से पहले उनके नीचे के रिकॉर्ड और नियम देखना बेहतर होगा।
यह मार्गदर्शिका CRM का निदान करने वाले RevOps लीड, एडमिन या उसे इस्तेमाल करने वाली टीमों के साथ काम कर रहे सलाहकार के लिए है। इसमें रिकॉर्ड, प्रॉपर्टी, लाइफ़साइकल और डील स्टेज, वर्कफ़्लो, इंटीग्रेशन और रिपोर्ट शामिल हैं। हर मार्केटिंग सामग्री का ऑडिट या पूरे खाते का नया डिज़ाइन इसका उद्देश्य नहीं है।
नीचे के नेविगेशन और उत्पाद व्यवहार को 7 अक्टूबर 2026 को HubSpot के आधिकारिक दस्तावेज़ों से जाँचा गया था। अलग खातों में मेनू, ऑब्जेक्ट नाम, अनुमतियाँ, सदस्यता और बीटा पहुँच अलग हो सकती हैं। कुछ टूल More के नीचे मिलते हैं। सुविधा उपलब्ध न हो तो सीमा दर्ज करें और अधिकृत रिकॉर्ड व्यू या एक्सपोर्ट इस्तेमाल करें; अनुपलब्ध सुविधा को व्यावसायिक नियंत्रण की विफलता न गिनें।
वर्कशीट खोलें और पहली बार के लिए एक सक्रिय पाइपलाइन या हस्तांतरण चुनें। उदाहरण काल्पनिक हैं। निर्देश दस्तावेज़ों पर आधारित हैं; यह दावा नहीं कि हमने आपके खाते में उन्हें जाँचा है।
1. दायरा, पहुँच और समीक्षा की जिम्मेदारियाँ तय करें
व्यावसायिक समस्या और उससे जुड़े ऑब्जेक्ट से शुरू करें। इम्पोर्ट के बाद नई लीड का जिम्मेदार व्यक्ति हट जाता है तो संबंधित संपर्क, कंपनियाँ, आवंटन और इम्पोर्ट का रास्ता देखें। हर डील वर्कफ़्लो जाँचने से काम बढ़ेगा, जरूरी नहीं कि जवाब मिले।
कार्यान्वयन देखने से पहले प्रक्रिया के जिम्मेदार व्यक्ति से अपेक्षित नियम पूछें। “क्षेत्र के अनुसार सौंपें” से अज्ञात क्षेत्र, मौजूदा ग्राहक या अनुपस्थित व्यक्ति का मामला स्पष्ट नहीं होता। ये अपवाद भी ऑडिट में शामिल करें।
- दायरे का खाता, पाइपलाइन, ऑब्जेक्ट प्रकार, टीमें, अवधि और समय क्षेत्र लिखें। प्रक्रिया के जिम्मेदार व्यक्ति और सेटिंग समझाने वाले एडमिन का नाम दें।
- आपकी अनुमति से दिखने वाले व्यू और टूल की सूची बनाएँ। सशुल्क सुविधा पर योजना बनाने से पहले दिए दस्तावेज़ में सदस्यता की शर्तें जाँचें।
- तय करें कि निदान के दौरान रिकॉर्ड वर्कफ़्लो में नामांकित नहीं करेंगे, डुप्लिकेट मर्ज नहीं करेंगे, प्रॉपर्टी नहीं बदलेंगे और सिंक दोबारा नहीं चलाएँगे। प्रभाव और जिम्मेदारी स्पष्ट होने तक प्रस्तावित सुधार वर्कशीट में रखें।
- स्टेज परिभाषाएँ, रूटिंग नियम, मुख्य रिपोर्ट और जुड़े सिस्टम की सूची जुटाएँ। पूछें कि हर एक का रखरखाव कौन करता है और विफलताएँ कहाँ देखी जाती हैं।
अंत में आपके पास क्या होना चाहिए
दायरे और पहुँच का रिकॉर्ड तथा अज्ञात बातों की सूची। अनुपलब्ध अनुमति सीमा के रूप में दिखे, निष्कर्षों में छिपे नहीं।
2. दोहराया जा सकने वाला शुरुआती माप सुरक्षित रखें
जाँचे जाने वाले रिकॉर्ड की स्थिर परिभाषा बनाएँ। कई पाइपलाइन हों या रिकॉर्ड केवल उनके जिम्मेदार व्यक्ति को दिखते हों तो “खुले सौदे” अधूरा है। संबंधित पाइपलाइन, स्टेज, बिक्री प्रक्रिया और बहिष्करण शामिल करें।
HubSpot के वर्तमान सेव्ड-व्यू दस्तावेज़ में ऑब्जेक्ट का CRM इंडेक्स खोलना, व्यू जोड़ना, फ़िल्टर और कॉलम तय करना तथा व्यू की सेटिंग प्रकाशित करना बताया गया है। इससे व्यू सेव होता है; रिकॉर्ड वेब पर प्रकाशित नहीं होते। साझा पहुँच ऑडिट टीम तक सीमित रखें।
- संबंधित CRM ऑब्जेक्ट की सूची खोलें, जैसे Deals। टेबल व्यू जोड़ें और स्पष्ट नाम दें, जैसे “ऑडिट — नए ग्राहकों के खुले सौदे — अक्टूबर”।
- तय फ़िल्टर लगाएँ। Record ID, जिम्मेदार व्यक्ति, स्टेज, राशि, मुद्रा, क्लोज़ डेट और सवाल से संबंधित संबंध या अगली कार्रवाई के फ़ील्ड शामिल करें।
- दिखती गिनती, सटीक फ़िल्टर, जाँच का समय और पहुँच की सीमाएँ लिखें। अनुमति प्राप्त एक्सपोर्ट या तारीख वाला परिणाम सुरक्षित रखें, क्योंकि सेव्ड व्यू में रिकॉर्ड बदलते रहते हैं।
- अलग स्रोत, जिम्मेदार व्यक्ति और परिणाम वाले उदाहरण चुनें। पूरी शुरुआती गिनती को हाथ से जाँचे जाने वाले छोटे समूह से अलग रखें।
अंत में आपके पास क्या होना चाहिए
शुरुआती गिनती, सेव्ड व्यू या समान चयन और पहचाने जा सकने वाले नमूना रिकॉर्ड। समान पहुँच वाला सहकर्मी वही चयन दोहरा सके।
3. सुधार स्वीकार करने से पहले डेटा की समस्याएँ जाँचें
उपलब्ध हो तो Data Management → Data Quality खोलें। HubSpot के दस्तावेज़ डुप्लिकेट, फ़ॉर्मैटिंग और प्रॉपर्टी की जानकारी वाले व्यू बताते हैं; पहुँच और सुविधा की सीमाएँ खाते पर निर्भर हैं। यह अवलोकन शुरुआत है। यह तय नहीं करता कि आपके वर्कफ़्लो के लिए कौन-सी समस्या महत्वपूर्ण है।
पहचानी गई समस्या के पीछे के रिकॉर्ड देखें। जहाँ कभी फ़ोन नहीं किया जाता, वहाँ नंबर गायब होना हानिरहित हो सकता है। मिलते-जुलते नाम अलग कंपनियों के हो सकते हैं। मिली स्थिति और प्रस्तावित सुधार अलग कॉलम में रखें।
- खाते में उपलब्ध समस्या श्रेणियाँ देखें और उनकी तारीखों की अवधि लिखें। अनुपलब्ध क्षमताएँ दर्ज करें, उनके परिणाम का अनुमान न लगाएँ।
- चिह्नित रिकॉर्ड की तुलना अपने ऑडिट समूह से करें। पूरे खाते का आँकड़ा पाइपलाइन के निष्कर्ष में डालने के बजाय उस समूह की प्रभावित गिनती दोबारा निकालें।
- उदाहरण खोलें और ID, विरोधाभासी मान, बनने के स्रोत तथा प्रभावित वर्कफ़्लो लिखें। पहचान जाँचने तक संभावित डुप्लिकेट को अपुष्ट रखें।
- सुझाई कार्रवाई को लागू किए बिना दर्ज करें। सजावटी फ़ॉर्मैटिंग से पहले रूटिंग, संबंध या रिपोर्टिंग तोड़ने वाली समस्याओं को प्राथमिकता दें।
अंत में आपके पास क्या होना चाहिए
गिनती, प्रभावित काम और अगली प्रस्तावित जाँच सहित पड़ताली गई डेटा समस्याओं की सूची। यह चरण पूरा करने के लिए सामूहिक सफ़ाई जरूरी नहीं है।
4. प्रक्रिया चलाने वाली प्रॉपर्टी का रास्ता देखें
ऑडिट किए जा रहे हस्तांतरण, रूटिंग नियम या रिपोर्ट में इस्तेमाल प्रॉपर्टी चुनें। जिम्मेदार व्यक्ति, लाइफ़साइकल या स्टेज, क्लोज़ डेट, राशि, वर्ग और शाखा तय करने वाले फ़ील्ड से शुरू करें। सक्रिय फ़ील्ड समझने से पहले हर अप्रयुक्त फ़ील्ड लिखने का लाभ कम है।
प्रॉपर्टी एडिटर में Details और उपलब्ध Monitor अनुभाग देखें। HubSpot उपयोग, भराव दर, प्रॉपर्टी अपडेट करने वाले टूल और गुणवत्ता निगरानी का विवरण देता है। दिखाई देने वाले नाम के साथ आंतरिक नाम भी लिखें: इंटीग्रेशन आंतरिक नाम इस्तेमाल करते हैं, जिसे बनने के बाद बदला नहीं जा सकता।
- हर महत्वपूर्ण प्रॉपर्टी की परिभाषा, ऑब्जेक्ट, आंतरिक नाम, स्वीकार्य मान और प्रक्रिया का जिम्मेदार व्यक्ति छोटे फ़ील्ड शब्दकोश में लिखें।
- देखें कि प्रॉपर्टी कहाँ इस्तेमाल होती है और कौन-से टूल उसे अपडेट करते हैं। ऑडिट से जुड़े वर्कफ़्लो, फ़ॉर्म, इम्पोर्ट, इंटीग्रेशन और रिपोर्ट शामिल करें।
- परिभाषा की तुलना शुरुआती समूह के असली मानों से करें। खाली, अज्ञात, अमान्य और वास्तव में लागू न होने वाले मान अलग रखें।
- अंतर हो तो उदाहरण रिकॉर्ड का बदलाव इतिहास देखें और जिम्मेदार अपडेट स्रोत पहचानें। हटाने, नाम बदलने या फ़ील्ड प्रकार बदलने का प्रस्ताव देने से पहले निर्भरता सूची सुरक्षित रखें।
| प्रॉपर्टी का उद्देश्य | सवाल | साक्ष्य |
|---|---|---|
| सौदे का जिम्मेदार व्यक्ति | क्या इस सौदे को सक्रिय जिम्मेदार व्यक्ति या स्पष्ट कतार चाहिए? | शुरुआती समूह के अपवाद और आवंटन का इतिहास |
| समाप्ति तिथि | इस तारीख को कौन-सी घटना दर्शानी चाहिए? | परिभाषा, हाल के बदलाव और रिपोर्ट फ़िल्टर |
| ग्राहक वर्ग | क्या सभी अपडेट स्रोत वही स्वीकार्य मान इस्तेमाल करते हैं? | मानों का वितरण और अपडेट स्रोत |
| अगली कार्रवाई | क्या फ़ील्ड भविष्य की कार्रवाई, तारीख या दोनों दर्ज करता है? | फ़ील्ड की परिभाषा और जिम्मेदार व्यक्ति से समझना |
अंत में आपके पास क्या होना चाहिए
महत्वपूर्ण प्रॉपर्टी और उनकी निर्भरताओं का शब्दकोश। हर सुझाया बदलाव बताए कि और क्या प्रभावित हो सकता है।
5. लाइफ़साइकल नियम और डील स्टेज के साक्ष्य जाँचें
संपर्क और कंपनियाँ सौदों से अलग जाँचें। विस्तार का नया सौदा चलते हुए भी कंपनी का संबंध “ग्राहक” रह सकता है। लाइफ़साइकल और डील स्टेज को एक मानने से हस्तांतरण और रूपांतरण रिपोर्ट समझना कठिन होता है।
HubSpot के दस्तावेज़ आगे बढ़ने वाले स्वचालित लाइफ़साइकल अपडेट बताते हैं। उसके टूल से पिछला स्टेज तय करने के लिए पहले मौजूदा मान खाली करना पड़ता है। ऑडिट में इतिहास और अपेक्षित व्यवहार जाँचें; स्क्रीन एक जैसी दिखाने के लिए मान न बदलें।
डील पाइपलाइन का दस्तावेज़ित रास्ता है Settings → Data Management → Objects, फिर Deals और Pipelines चुनें। स्टेज और संभावनाएँ देखें। HubSpot भारित राशि निकालने में स्टेज की संभावना इस्तेमाल करता है। इसलिए खरीदार का व्यवहार बदले बिना भी सेटिंग का चुनाव रिपोर्ट बदल सकता है।
- हस्तांतरण के लिए अपेक्षित लाइफ़साइकल बदलाव लिखें। हाल के रिकॉर्ड में किस व्यक्ति या सिस्टम ने मान बदला, यह देखें; फिर से सौंपे गए और लौटे ग्राहक भी शामिल करें।
- हर डील स्टेज में प्रवेश और निकास का जरूरी साक्ष्य तय करें। कुछ असली स्टेज बदलावों से उसकी तुलना करें।
- जाँचें कि जीते और हारे परिणाम सही दिखते हैं। बार-बार बदली क्लोज़ डेट, गायब अगली कार्रवाई या असामान्य स्टेज अवधि वाले सक्रिय सौदे पहचानें और जिम्मेदार व्यक्ति से समझें।
- जहाँ UI में फ़ील्ड भरना अनिवार्य है, उन्हें लिखें। फिर देखें कि रिकॉर्ड बनाने के दूसरे रास्ते भी मान देते हैं या नहीं। हाथ से एंट्री का नियंत्रण इम्पोर्ट और इंटीग्रेशन पर लागू होगा, यह न मानें।
अंत में आपके पास क्या होना चाहिए
रिकॉर्ड इतिहास, अपेक्षित व्यवहार और जिम्मेदार व्यक्ति सहित लाइफ़साइकल तथा स्टेज अपवादों की सूची।
6. रिकॉर्ड को उसके वर्कफ़्लो में आगे बढ़ते देखें
महत्वपूर्ण मान बदलने या काम दूसरे व्यक्ति को सौंपने वाला ऑटोमेशन चुनें। परिणाम गलत मानने से पहले नामांकन नियम, दोबारा नामांकन, शाखाएँ, देरी और कार्रवाइयाँ पढ़ें। वर्कफ़्लो का नाम शायद ही पूरा विवरण देता है।
निष्पादन देखने का दस्तावेज़ित रास्ता है Automation → Workflows, फिर वर्कफ़्लो के More मेनू में View details → Action logs। रिकॉर्ड की यात्रा के लिए Enrollment history देखें। सेटिंग के बदलाव अलग हैं: वर्कफ़्लो खोलें और View → Revision History देखें।
दस्तावेज़ वर्तमान में एक्शन लॉग के लिए 90 दिन और पुराने नामांकन डेटा के लिए छह महीने की अवधि बताते हैं। सेव किए जाने वाले सफल निष्पादनों की दैनिक सीमा भी है। इसलिए सफलता का लॉग न मिलना यह साबित करने के लिए पर्याप्त नहीं कि कार्रवाई कभी चली ही नहीं।
- एक पात्र रिकॉर्ड और एक अपवाद का अपेक्षित परिणाम लिखें। घटना दो बार हो या जिम्मेदार व्यक्ति गायब हो तो क्या होना चाहिए, यह भी लिखें।
- उपलब्ध एक्शन और नामांकन इतिहास में वे रिकॉर्ड ढूँढें। दिखी शाखा और परिणाम की तुलना लिखे नियम से करें।
- घटना के आसपास संशोधन इतिहास देखें। संबंधित संस्करण, तारीख और नियम का बदलाव दर्ज करें; आज की सेटिंग तब भी लागू थी, यह न मानें।
- प्रतिस्पर्धी अपडेट स्रोत पहचानें: वर्कफ़्लो सफल होने के बाद दूसरा वर्कफ़्लो या इंटीग्रेशन मान बदल सकता है। टाइमलाइन और प्रभावित ID सुरक्षित रखें।
अंत में आपके पास क्या होना चाहिए
इनपुट से नामांकन, शाखा, कार्रवाई और रिकॉर्ड के अंतिम मान तक का विवरण, साथ में इतिहास की संबंधित सीमाएँ।
7. सिंक की विफलताएँ और जानबूझकर बाहर रखे रिकॉर्ड जाँचें
दायरे के फ़ील्ड पढ़ने या लिखने वाले सिस्टम की सूची बनाएँ। हर एक का संचालन जिम्मेदार व्यक्ति, मिलान कुंजी, दिशा और विरोध होने पर प्राथमिक सिस्टम लिखें। इंटीग्रेशन जुड़ा होने पर भी रिकॉर्ड के किसी खास समूह में समस्या हो सकती है।
HubSpot डेटा सिंक इस्तेमाल करने वाले ऐप के लिए रास्ता है Settings → Integrations → Connected Apps → ऐप → CRM syncs। ऑब्जेक्ट व्यू सिंक हुए, विफल और बाहर रखे रिकॉर्ड अलग दिखाता है। फ़िल्टर या मिलान कुंजी की शर्तों से रिकॉर्ड बाहर रह सकते हैं; यह सिंक त्रुटि के समान नहीं है। दूसरे इंटीग्रेशन के लॉग और नियंत्रण अलग हो सकते हैं।
- संबंधित ऑब्जेक्ट सिंक की स्थिति देखें और प्रभावित रिकॉर्ड समूह खोलें। वास्तविक विफलता कारण या बाहर रखने की शर्त सुरक्षित रखें।
- विफल या बाहर रखे रिकॉर्ड की तुलना सफलतापूर्वक सिंक हुए रिकॉर्ड से करें। पहचानकर्ता, जरूरी मान, मैपिंग और फ़िल्टर पात्रता जाँचें।
- उपलब्ध समय और इतिहास से दोनों सिस्टम में महत्वपूर्ण मान का रास्ता देखें। दर्ज करें कि बाद का अपडेट पहले वाले को उलटता है या नहीं।
- इंटीग्रेशन के जिम्मेदार व्यक्ति को साक्ष्य और प्रस्तावित परीक्षण दें। निदान में दोबारा चलाना या सेटिंग बदलना शामिल न करें; इससे आगे के सिस्टम अपडेट हो सकते हैं।
अंत में आपके पास क्या होना चाहिए
हर कनेक्शन के नामित जिम्मेदार व्यक्ति सहित सूची, जिसमें त्रुटियाँ, अपेक्षित बहिष्करण और अनसुलझा व्यवहार अलग हों।
8. रिपोर्ट को उसके मूल रिकॉर्ड से मिलाएँ
जिस डैशबोर्ड के कारण ऑडिट शुरू हुआ, उसमें एक मीट्रिक चुनें। कुल देखने से पहले लिखें कि वह ठीक क्या मापने का दावा करता है। “इस तिमाही की पाइपलाइन” का अर्थ इस तिमाही बने सौदे, बंद होने की उम्मीद वाले सौदे या तिमाही शुरू होने का स्नैपशॉट हो सकता है।
HubSpot के कस्टम रिपोर्ट बिल्डर में मुख्य और संबंधित डेटा स्रोत तय करते हैं कि कौन-से रिकॉर्ड दिख सकते हैं। दस्तावेज़ित View data join info पैनल इन संबंधों को समझाता है। कई ऑब्जेक्ट की रिपोर्ट एक ऑब्जेक्ट के व्यू से न मिले तो इसे देखें।
- स्रोत, फ़िल्टर, तारीख वाला फ़ील्ड, समय क्षेत्र, राशि वाला फ़ील्ड, मुद्रा और गणना का तरीका लिखें। कुल राशि और भारित राशि अलग रखें।
- कुछ ज्ञात डील ID चुनें: एक जिसे दिखना चाहिए, एक जिसे नियम से बाहर रखा गया है और एक जिसके कई संपर्क जुड़े हैं। हर एक का व्यवहार जाँचें।
- अलग-अलग डील ID और कुल की शुरुआती माप से तुलना करें। स्रोत डेटा को गलत मानने से पहले गायब संबंध, जॉइन का व्यवहार और दोहराई पंक्तियाँ देखें।
- उदाहरण में €10,000 और €20,000 के दो काल्पनिक सौदों का कुल €30,000 है। जुड़े डेटा की एक्सपोर्ट तालिका में पहले सौदे के दो संपर्क होने से वह दोहराए, तो तीन पंक्तियाँ जोड़ने पर €40,000 बनेंगे। रिपोर्ट भी यही गलती करती है, यह मानने के बजाय उसकी गणना जाँचें।
अंत में आपके पास क्या होना चाहिए
मिलान नोट जिसमें अंतर की सटीक परिभाषा, संबंध या गणना का कारण हो; या अनसुलझे अंतर का स्पष्ट रिकॉर्ड।
9. सुधार योजना और स्वीकृति जाँच बनाएँ
मान लें काल्पनिक शुरुआती समूह में 120 खुले सौदे हैं और 18 का जिम्मेदार व्यक्ति नहीं है: 15%। सभी 18 जाँचने पर कल्पना करें कि 12 एक इम्पोर्ट से आए और छह तय कतार के अपवाद हैं। दोनों तथ्य बताएँ। मूल “जिम्मेदार व्यक्ति गायब” जाँच को चुपचाप “गलत आवंटन” बनाकर नई गिनती को समान आधार वाला सुधार न बताएँ।
इम्पोर्ट के कारण, मौजूदा रिकॉर्ड और नियमित नियंत्रण के लिए अलग काम बनाएँ। उपयोगी बदलाव करने से पहले एडमिन को फ़ील्ड परिभाषा या आवंटन नियम पर बिक्री टीम का निर्णय चाहिए हो सकता है।
- निष्कर्ष, साक्ष्य, व्यावसायिक प्रभाव, विश्वास, निर्भरता, जिम्मेदार व्यक्ति और प्रस्तावित बदलाव लिखें। रुके काम और अविश्वसनीय निर्णयों को पहले प्राथमिकता दें।
- संपादन से पहले परीक्षण मामले तय करें: अपेक्षित जिम्मेदार व्यक्ति, गायब रूटिंग इनपुट, सुरक्षित रखा जाने वाला मौजूदा जिम्मेदार व्यक्ति और दोहराया इम्पोर्ट या घटना।
- टीम के पास उपलब्ध उचित परिवेश में परीक्षण करें। तत्काल रिकॉर्ड के साथ निर्भर वर्कफ़्लो और रिपोर्ट भी जाँचें तथा वापस लौटने का तरीका लिखें।
- स्वीकृत सुधार के बाद शुरुआती जाँच दोहराएँ और नए रिकॉर्ड का बैच अलग जाँचें। बार-बार होने वाली विफलताओं की समीक्षा किसी को सौंपें और प्रक्रिया के जिम्मेदार व्यक्ति से परिणाम की पुष्टि लें।
| काम | जिम्मेदार व्यक्ति | स्वीकृति का साक्ष्य |
|---|---|---|
| इम्पोर्ट आवंटन और कतार के अपवाद तय करें | बिक्री प्रक्रिया का जिम्मेदार व्यक्ति | सामान्य और अपवाद मामलों का लिखित नियम |
| इम्पोर्ट का रास्ता सुधारें | CRM एडमिन | टेस्ट रिकॉर्ड को सही व्यक्ति मिले और पुराने सही मान न मिटें |
| प्रभावित 12 इम्पोर्ट किए सौदे जाँचें | बिक्री प्रबंधक | हर रिकॉर्ड का वैध जिम्मेदार व्यक्ति या दर्ज अपवाद हो |
| अगले इम्पोर्ट की निगरानी करें | इंटीग्रेशन या इम्पोर्ट का जिम्मेदार व्यक्ति | नए समूह को उसी नियम से जाँचा गया और परिणाम दर्ज है |
अंत में आपके पास क्या होना चाहिए
प्राथमिकता वाली परीक्षण योग्य कार्यसूची, शुरुआती माप और साक्ष्य। हर सुझाव का जिम्मेदार व्यक्ति और सफलता जाँचने का तरीका तय हो तो ऑडिट समीक्षा के लिए तैयार है।
स्रोत और आगे पढ़ने के लिए
- HubSpot: सेव किए गए व्यू बनाना और प्रबंधित करना ↗
- HubSpot: डेटा गुणवत्ता के टूल और पहुँच की आवश्यकताएँ ↗
- HubSpot: प्रॉपर्टी की परिभाषाएँ, उपयोग और अपडेट के स्रोत ↗
- HubSpot: संपर्कों और कंपनियों के लाइफ़साइकल स्टेज ↗
- HubSpot: ऑब्जेक्ट पाइपलाइन और स्टेज की संभावनाएँ ↗
- HubSpot: वर्कफ़्लो एक्शन लॉग और नामांकन का इतिहास ↗
- HubSpot: वर्कफ़्लो संशोधनों का इतिहास ↗
- HubSpot: डेटा सिंक की स्थिति, विफलताएँ और बाहर रखे गए रिकॉर्ड ↗
- HubSpot: रिपोर्ट के डेटा स्रोत और उनके बीच संबंध ↗
- HubSpot: रिकॉर्ड मर्ज करने का व्यवहार और सीमाएँ ↗
तरीके को काम में लाएँ।
CRM लागू करने और उसका प्रबंधन करने के बारे में जानें.
Five Dots ↗ एक्सप्लोर करें
