RevOps की बुनियाद / व्यावहारिक गाइड
RevOps ऑडिट चेकलिस्ट: क्या जाँचें और सुधारों की प्राथमिकता कैसे तय करें
लोगों, प्रक्रियाओं, सिस्टम और डेटा को शामिल करने वाली व्यावहारिक RevOps चेकलिस्ट। प्रमाण जुटाएँ, निष्कर्षों की प्राथमिकता तय करें और अगली कार्रवाई सौंपें।
संक्षेप में
RevOps ऑडिट ग्राहक के पहले संकेत से बिक्री और डिलीवरी तक काम का पीछा करता है। ये नौ चरण समस्या तय करने, साक्ष्य जुटाने, टीमों के बीच काम सौंपने की प्रक्रिया जाँचने और निष्कर्षों को स्पष्ट जिम्मेदारी वाले बदलावों में बदलने में मदद करते हैं। साथ-साथ वर्कशीट भरें। अंत में आपके पास प्राथमिकता के क्रम में कार्ययोजना, शुरुआती माप और सुधार की पुष्टि करने का तरीका होगा।
- एक राजस्व प्रक्रिया और टीम के सामने मौजूद एक निर्णय से शुरू करें।
- असली रिकॉर्ड के साथ उनसे जुड़े लोगों, नियमों और सिस्टम की जाँच करें।
- पुष्ट अवलोकन और संभावित कारण अलग रखें, फिर सुधारों का परीक्षण करें।
खाली टेम्पलेट। इसे अपने स्प्रेडशीट टूल में खोलें और चरणों पर काम करते हुए प्रमाण दर्ज करें।
शुरू करने से पहले: पहले ऑडिट का उपयोगी दायरा चुनें
सोमवार की राजस्व बैठक की कल्पना करें। बिक्री टीम का पाइपलाइन आँकड़ा अलग है, वित्त का अलग। कोई वह स्प्रेडशीट दिखा रहा है जिसे पिछले गुरुवार तक सही माना जा रहा था। सबने काम किया है। बस इस पर सहमति नहीं है कि नतीजे क्या कहते हैं। राजस्व संचालन का ऑडिट शुरू करने के लिए यह अच्छी जगह है।
CRM ऑडिट सिस्टम की सेटिंग जाँचता है। RevOps ऑडिट पूछता है कि ग्राहक की पूरी यात्रा में लोग, जिम्मेदारी सौंपने की प्रक्रियाएँ, सिस्टम और डेटा साथ काम कर रहे हैं या नहीं। सही तरह से बनाया गया फ़ील्ड भी यह मतभेद नहीं सुलझा सकता कि बिक्री टीम को लीड कब स्वीकार करनी चाहिए।
यह मार्गदर्शिका किसी B2B राजस्व प्रक्रिया के पहले ऑडिट के लिए है। नए ग्राहक, विस्तार या नवीनीकरण में से एक चुनें; बाकी पर बाद में यही तरीका दोहराएँ। एक ऑडिट लीड, संबंधित प्रक्रियाओं के जिम्मेदार लोग, जरूरी रिकॉर्ड और रिपोर्ट तक पहुँच और निष्कर्ष लिखने की जगह चाहिए। क्रमांकित चरण क्रम से पूरे करें। हर चरण का एक ठोस परिणाम है।
ये चरण और वर्कशीट हमारी सुझाई कार्यपद्धति हैं। दिए गए विक्रेता दस्तावेज़ सिस्टम के विशिष्ट उदाहरणों का आधार हैं; वे इस ऑडिट का प्रमाणन नहीं हैं। नीचे दिए सभी संख्यात्मक उदाहरण काल्पनिक हैं, ग्राहक के परिणाम या उद्योग के मानक नहीं।
1. सवाल और निर्णय तय करें
“RevOps का ऑडिट करें” इतना व्यापक है कि शुरुआत समझ नहीं आती। कोई दिखने वाली समस्या चुनें: लीड सौंपने में देरी, क्लोज़ डेट बार-बार बदलना या तय दायरे के बिना ग्राहक का ऑनबोर्डिंग तक पहुँचना। प्रायोजक से पूछें कि कारण समझ आने पर वे कौन-सा निर्णय बदलेंगे।
डैशबोर्ड खोलने से पहले छोटा ऑडिट ब्रीफ़ लिखें। ग्राहक वर्ग और बिक्री प्रक्रिया बताएँ: बड़े उद्यम की नई बिक्री और सेल्फ़-सर्विस अपग्रेड के स्टेज नियम अलग हो सकते हैं। परिभाषाओं और प्राथमिकताओं पर मतभेद सुलझाने के लिए एक व्यक्ति तय करें।
- सवाल एक वाक्य में लिखें: “योग्य इनबाउंड पूछताछ बिना किसी जिम्मेदार व्यक्ति के बिक्री टीम तक क्यों पहुँचती हैं?” साथ में निर्णय लिखें: “कौन-सा रूटिंग नियम और वैकल्पिक प्रक्रिया बदलनी है?”
- सीमा तय करें: टीम, क्षेत्र, उत्पाद, पाइपलाइन, सिस्टम, तारीखों की अवधि और समय क्षेत्र। अभी खुले सौदों के स्नैपशॉट को किसी अवधि में बनी लीड के समूह से अलग रखें।
- बहिष्करण और सीमाएँ लिखें: टेस्ट रिकॉर्ड, पार्टनर द्वारा सँभाले खाते, अनुपलब्ध गतिविधि इतिहास या वे रिकॉर्ड जिन्हें आपकी अनुमति नहीं दिखाती।
- तय करें कि निष्कर्ष कौन जाँचेगा और ऑडिट कब पूरा माना जाएगा: साक्ष्य वाला निदान, प्राथमिकता के क्रम में काम और प्रस्तावित बदलावों की स्वीकृति जाँच।
अंत में आपके पास क्या होना चाहिए
सवाल, दायरा, प्रायोजक, बहिष्करण और निर्णय वाला एक पृष्ठ का ब्रीफ़। यदि दो लोग इसे पढ़कर अलग रिकॉर्ड चुनें, तो दायरा और स्पष्ट करें।
2. शुरुआती माप और साक्ष्य जुटाएँ
क्या हुआ, यह समझने के लिए पर्याप्त इतिहास चाहिए। सफ़ाई शुरू होने से पहले वर्तमान परिभाषाएँ और माप सुरक्षित रखें। लाइव रिपोर्ट आगे के काम में उपयोगी है, लेकिन उसका परिणाम कल बदल सकता है। सेव किए फ़िल्टर के साथ तारीख वाला परिणाम या अनुमति प्राप्त एक्सपोर्ट भी रखें।
पूरे समूह की गिनती के साथ कुछ यात्राओं की गहरी जाँच करें। सभी रिकॉर्ड की जाँच बताती है कि कोई स्थिति कितनी बार दिखती है। सोच-समझकर चुना नमूना कारण समझाता है। कुछ असामान्य सौदे जाँच में उपयोगी हैं, पर उनसे पूरी पाइपलाइन का प्रतिनिधि अनुमान नहीं मिलता।
- स्टेज परिभाषाएँ, लीड रूटिंग नियम, काम सौंपने के समझौते, मुख्य डैशबोर्ड, फ़ील्ड परिभाषाएँ और इंटीग्रेशन मानचित्र जुटाएँ। दस्तावेज़ न मिलें तो “अज्ञात” लिखें; बिना दस्तावेज़ वाले काम को अनुपस्थित न मानें।
- दायरे के रिकॉर्ड के ID, जिम्मेदार व्यक्ति, स्रोत, स्टेज, संबंधित समय, जरूरी राशि और मुद्रा, अगली कार्रवाई तथा संबंधित ग्राहक रिकॉर्ड के लिंक रखें। साक्ष्य उचित पहुँच वाली स्वीकृत साझा जगह पर रखें।
- सफल हस्तांतरण, देरी, जीते और हारे सौदे, जिम्मेदारी बदलने और अपवादों के उदाहरण चुनें। हर चयन का कारण लिखें। समस्या की व्यापकता का अनुमान चाहिए तो अलग यादृच्छिक या स्तरीकृत नमूना लें।
- हर प्रक्रिया के जिम्मेदार व्यक्ति से हाल का वास्तविक रिकॉर्ड समझाने को कहें: क्या आया, क्या जाँचा, क्या बदला और कैसे पता चला कि अगले व्यक्ति ने काम स्वीकार कर लिया।
| साक्ष्य | कहाँ देखें | क्या सुरक्षित रखें |
|---|---|---|
| प्रक्रिया के नियम | बिक्री प्लेबुक, ऑनबोर्डिंग चेकलिस्ट, टीम के समझौते | परिभाषा, जिम्मेदार व्यक्ति, संस्करण या तारीख |
| वास्तविक बदलाव | CRM इतिहास, गतिविधि टाइमलाइन, टास्क सिस्टम | रिकॉर्ड ID, घटना, समय, स्रोत |
| सिस्टम का व्यवहार | वर्कफ़्लो लॉग और इंटीग्रेशन की स्थिति | नियम या जॉब ID, परिणाम, जाँच की सीमाएँ |
| रिपोर्ट किया गया परिणाम | डैशबोर्ड की सेटिंग और मूल रिकॉर्ड | फ़िल्टर, तारीख वाला फ़ील्ड, गणना का तरीका, तारीख सहित परिणाम |
अंत में आपके पास क्या होना चाहिए
शुरुआती माप का फ़ोल्डर और साक्ष्य सूची। दूसरा व्यक्ति वही रिकॉर्ड चुन सके और पूरे समूह तथा जाँच के लिए चुने नमूने में अंतर समझ सके।
3. हर हस्तांतरण और उसकी जिम्मेदारी का मानचित्र बनाएँ
चुनी गई प्रक्रिया में ग्राहक का रास्ता बनाएँ। नई बिक्री में यह पूछताछ, योग्यता जाँच, जरूरत समझना, प्रस्ताव, समझौता और ऑनबोर्डिंग हो सकता है। नवीनीकरण में उसके शुरू होने के संकेत से ग्राहक से बातचीत और व्यावसायिक निर्णय तक जाएँ।
आवर्ती राजस्व के लिए Winning by Design का Bowtie मॉडल ग्राहक पाने, बनाए रखने और विस्तार को एक यात्रा में जोड़ता है। ऑडिट की सीमा जाँचने में यह उपयोगी है: समस्या बिक्री के बाद आती है तो जीते सौदे पर रुकने के बजाय ऑनबोर्डिंग और ग्राहक सफलता टीम को जिम्मेदारी सौंपना भी शामिल करें।
हर सीमा पर काम भेजना और उसे स्वीकार करना अलग रखें। टास्क बनना या स्टेज बदलना निर्देश का प्रमाण है; इससे साबित नहीं होता कि अगली टीम ने जिम्मेदारी ली। दोनों पक्ष अलग विवरण दें तो दोनों से बात करें।
- हर हस्तांतरण में भेजने और पाने वाले जिम्मेदार व्यक्ति, ट्रिगर, जरूरी जानकारी, स्वीकृति संकेत और अपवाद का रास्ता लिखें।
- चुने रिकॉर्ड को इन सीमाओं के पार देखें। अपेक्षित समय और जरूरी जानकारी की तुलना वास्तविक इतिहास से करें।
- सहमति वाले सेवा स्तर के अनुसार देरी दर्ज करें। प्रतिक्रिया समय निकालने से पहले कार्य समय, समय क्षेत्र, छुट्टियाँ और समय गिनना शुरू करने वाली घटना तय करें।
- पूछें: जिम्मेदार व्यक्ति अनुपस्थित हो, क्षेत्र अस्पष्ट हो, लीड अस्वीकार हो या ग्राहक वापस आए तो क्या होता है? केवल किसी की याद में मौजूद वैकल्पिक प्रक्रिया को निष्कर्षों में दर्ज करें।
| हस्तांतरण | स्वीकृति का साक्ष्य | जाँचने योग्य अपवाद |
|---|---|---|
| मार्केटिंग → बिक्री | नियुक्त व्यक्ति कारण सहित स्वीकार या अस्वीकार करता है | क्षेत्र मेल नहीं खाता या रूटिंग की जरूरी जानकारी गायब है |
| बिक्री → ऑनबोर्डिंग | डिलीवरी का जिम्मेदार व्यक्ति दायरा और शुरू करने की शर्तें स्वीकार करता है | जीता सौदा जिसमें कार्यान्वयन की जानकारी नहीं है |
| ग्राहक सफलता → नवीनीकरण का जिम्मेदार व्यक्ति | नामित व्यक्ति नवीनीकरण की तारीख और अगली कार्रवाई की पुष्टि करता है | अलग सिस्टम में अनुबंध समाप्ति की तारीख अलग है |
| ग्राहक सफलता → विस्तार का जिम्मेदार व्यक्ति | व्यावसायिक जिम्मेदार व्यक्ति दर्ज ग्राहक जरूरत स्वीकार करता है | विस्तार के अवसर के लिए खाते का जिम्मेदार व्यक्ति तय नहीं है |
अंत में आपके पास क्या होना चाहिए
नामित जिम्मेदारियों वाला हस्तांतरण मानचित्र और विशिष्ट टूटन की सूची। “बिक्री और मार्केटिंग में तालमेल नहीं है” की जगह रिकॉर्ड, अनुपस्थित स्वीकृति संकेत और जिम्मेदार व्यक्ति सामने आते हैं।
4. योग्यता, स्टेज और पूर्वानुमान में बदलाव जाँचें
स्टेज के नाम सटीक लग सकते हैं, जबकि हर व्यक्ति उनका अलग अर्थ लेता है। पूछें कि किस साक्ष्य पर रिकॉर्ड उस स्टेज में आ सकता है और आगे बढ़ने से पहले क्या होना चाहिए। विक्रेता का प्रस्ताव भेजना एक गतिविधि है; खरीदार का दायरा स्वीकार करना दूसरी घटना।
संपर्क या कंपनी का लाइफ़साइकल किसी व्यक्तिगत सौदे की प्रगति से अलग रखें। उदाहरण के लिए HubSpot संपर्कों और कंपनियों के लिए लाइफ़साइकल स्टेज तथा बिक्री योग्यता के अतिरिक्त विवरण के लिए लीड स्टेटस इस्तेमाल करता है। डिफ़ॉल्ट नाम को तैयारी का प्रमाण मानने के बजाय संगठन की सहमत परिभाषाएँ अपनाएँ।
मौजूदा स्थिति के साथ बदलाव भी जाँचें। Salesforce के Pipeline Inspection दस्तावेज़ अवधि से बाहर गए सौदों सहित पाइपलाइन की हलचल और पूर्वानुमान श्रेणियों के बदलाव अलग दिखाते हैं। व्यावहारिक सवाल है: किस रिकॉर्ड ने आँकड़ा बदला और क्यों?
- हर सक्रिय स्टेज में प्रवेश और निकास का नियम लिखें। साक्ष्य और उसे जाँचने वाला व्यक्ति तय करें। “अच्छा लग रहा है” जैसे नियम न रखें।
- हाल में स्टेज में आए रिकॉर्ड को उस साक्ष्य से मिलाएँ। पीछे गए, स्टेज छोड़कर आगे बढ़े और निर्णय के बाद भी खुले सौदे शामिल करें।
- एक ही प्रक्रिया के समान सौदों का स्टेज में बिताया समय तुलना करें। निष्क्रिय सौदे की सीमा तय करने से पहले असामान्य मामलों पर जिम्मेदार लोगों से बात करें; दिनों की कोई सार्वभौमिक सीमा न अपनाएँ।
- दो तारीख वाले स्नैपशॉट के बीच क्लोज़ डेट, राशि और पूर्वानुमान श्रेणी के बदलाव देखें। इतिहास न हो तो साफ लिखें कि आज के रिकॉर्ड जाँच सकते हैं, लेकिन पिछले बदलाव भरोसे से दोबारा नहीं बना सकते।
अंत में आपके पास क्या होना चाहिए
स्टेज परिभाषाओं की तालिका और रिकॉर्ड इतिहास से समर्थित अपवादों की सूची। गलत संकेत देने वाली पूर्वानुमान श्रेणी और गलत सेट किए बिक्री स्टेज को अलग रखें।
5. डेटा जाँचें और सिस्टम में उसका रास्ता देखें
उन फ़ील्ड से शुरू करें जो निर्णय या कार्रवाई चलाते हैं। जिम्मेदार व्यक्ति रूटिंग को, क्लोज़ डेट अवधि की रिपोर्टिंग को, ग्राहक और अनुबंध के संबंध नवीनीकरण के हस्तांतरण को प्रभावित करते हैं। इनकी गायब जानकारी किसी आसानी से भरे जा सकने वाले बेकार फ़ील्ड से अधिक महत्वपूर्ण है।
हर महत्वपूर्ण मान के लिए तय करें कि किस सिस्टम को आधिकारिक स्रोत माना जाएगा और कौन-से सिस्टम उसे बदल सकते हैं। फिर एक असली अपडेट का पूरा रास्ता देखें। जाँच के समय सही CRM रिकॉर्ड यह नहीं बताता कि कल का इम्पोर्ट सुधार मिटा देगा या नहीं।
- हर जाँच का नियम और पात्र रिकॉर्ड समूह तय करें: जैसे नए ग्राहकों के खुले सौदे जिन्हें बिक्री का जिम्मेदार व्यक्ति चाहिए। प्रभावित ID और पात्र ID अलग गिनें।
- गायब, अमान्य, विरोधाभासी और पुरानी जानकारी, संभावित डुप्लिकेट तथा गायब संबंध जाँचें। “लागू नहीं” और “पता नहीं” अलग रखें।
- प्रभावित रिकॉर्ड के बनने का स्रोत और बदलावों का इतिहास देखें। इम्पोर्ट बैच, फ़ॉर्म, इंटीग्रेशन और मैनुअल अपडेट की तुलना करके पैटर्न ढूँढें।
- CRM, जुड़े सिस्टम और संबंधित ऑटोमेशन में एक अपडेट का रास्ता देखें। मिलान की कुंजियाँ, दिशा, विफलता सँभालने का तरीका और कनेक्शन के जिम्मेदार व्यक्ति को दर्ज करें।
अंत में आपके पास क्या होना चाहिए
दोहराई जा सकने वाली कुछ डेटा जाँचें और उनके पीछे अपडेट के रास्तों का मानचित्र। विस्तार से मापने की प्रक्रिया के लिए अलग CRM डेटा गुणवत्ता मार्गदर्शिका देखें।
6. निर्णय लेने वाली रिपोर्टों का मिलान करें
राजस्व बैठक में वास्तव में इस्तेमाल होने वाली रिपोर्ट चुनें। कुल आँकड़ों पर बहस से पहले उनकी परिभाषाएँ साथ रखें। पाइपलाइन राशि, भारित पाइपलाइन, अनुबंध मूल्य और प्राप्त नकदी अलग सवालों का जवाब देते हैं। मुद्रा का चिह्न होने भर से उनके बराबर होने की अपेक्षा न करें।
उदाहरण के लिए जीत दर जाँचते समय समूह में उस अवधि में बंद हुए जीते और हारे दोनों सौदे लें। गणना करें: जीते ÷ (जीते + हारे)। बनने की तारीख पर आधारित समूह अलग सवाल का जवाब देता है और उसमें अधूरे सौदे हो सकते हैं। बिना बताए एक आँकड़े की जगह दूसरा न रखें।
- मीट्रिक की परिभाषा में ऑब्जेक्ट, रिकॉर्ड समूह, अंश, लागू होने पर हर, तारीख वाला फ़ील्ड, समय क्षेत्र, मुद्रा और बहिष्करण लिखें।
- दोनों रिपोर्टों में समान रिकॉर्ड ID की तुलना करें। जिम्मेदार व्यक्ति के फ़िल्टर, अनुमतियों, संबंधित रिकॉर्ड, तारीखों या गणना से पैदा अंतर ढूँढें।
- छोटे चयन की मूल रिकॉर्ड से दोबारा गणना करें। भारित पाइपलाइन में सेव की गई स्टेज संभावना और ऐतिहासिक डेटा से मापी रूपांतरण दर अलग रखें।
- परिभाषा का जिम्मेदार व्यक्ति तय करें और बचा अंतर लिखें। जरूरी पुराना स्नैपशॉट न हो तो सीमा दर्ज करें और अब उसे जुटाना शुरू करें; शुरुआती माप गढ़ें नहीं।
अंत में आपके पास क्या होना चाहिए
मीट्रिक शब्दकोश और मिलान नोट, जिसमें हर अंतर समझाने वाले सटीक फ़िल्टर या रिकॉर्ड हों।
7. अवलोकनों को जाँचे हुए निष्कर्षों में बदलें
मान लें काल्पनिक शुरुआती समूह में नए ग्राहकों के 200 खुले सौदे हैं। 48 में तारीख सहित अगली कार्रवाई नहीं है: 48 ÷ 200 = 24%। यह CRM के बारे में पुष्ट अवलोकन है। अभी इससे साबित नहीं होता कि 24% सौदे छोड़ दिए गए हैं।
उदाहरण के लिए आप उन 48 में से 12 उनके जिम्मेदार लोगों के साथ जाँचते हैं। सात का फ़ॉलो-अप कहीं और दर्ज है, तीन हारे लगते हैं पर स्टेज नहीं बदला, और दो की अगली कार्रवाई तय नहीं है। ये तीन अलग समस्याएँ हैं। जाँच के लिए चुने इस नमूने का अनुपात बचे 36 पर लागू न करें।
- निष्कर्ष को जाँचे जा सकने वाले कथन में लिखें: रिकॉर्ड समूह, नियम, गिनती, दर, माप की तारीख और साक्ष्य लिंक सहित।
- संभावित कारण लिखें, फिर रिकॉर्ड इतिहास और जिम्मेदार व्यक्ति से बात करके उनका अंतर समझें। हर कारण को पुष्ट, संभावित या अनसुलझा चिह्नित करें।
- वही परिणाम बताएँ जिसका साक्ष्य है: फ़ॉलो-अप की अस्पष्ट स्थिति, रुका आवंटन या असंगत रिपोर्ट। नुकसान का प्रमाण न हो तो सौदे की राशि को “खोया राजस्व” न कहें।
- कारण अज्ञात रहे तो अगली जाँच लिखें। निष्कर्ष को कार्यान्वयन टास्क बनाने से पहले प्रक्रिया के जिम्मेदार व्यक्ति को उस पर सवाल उठाने दें।
अंत में आपके पास क्या होना चाहिए
अवलोकन, कारण, परिणाम और विश्वास का स्तर अलग रखने वाला निष्कर्ष रजिस्टर। हर पंक्ति सामान्य धारणा के बजाय साक्ष्य से जुड़ी हो।
8. निष्कर्षों को उपयोगी क्रम दें
ऑडिट में 70 निष्कर्ष मिलना आसान है और मंगलवार को क्या करना है, फिर भी समझ न आए। पहले देखें कौन-सा काम बाधित है, फिर विश्वास, निर्भरताएँ और मेहनत देखें। अंक देना वैकल्पिक है; क्रम का ठोस कारण देना जरूरी है।
पुष्ट कारण से रुके हस्तांतरण को तुरंत सँभालना पड़ सकता है। विवादित मीट्रिक के लिए पहले परिभाषा तय करनी होगी। अप्रयुक्त सजावटी फ़ील्ड इंतजार कर सकता है। तात्कालिक व्यावसायिक असर को कारण के विश्वास से अलग रखें: महत्वपूर्ण अज्ञात के लिए तुरंत जाँच चाहिए, बिना परीक्षण का सामूहिक बदलाव नहीं।
- हर निष्कर्ष में प्रभावित वर्कफ़्लो, पैमाना, परिणाम, विश्वास और तात्कालिकता लिखें।
- मेहनत का अनुमान लगाने से पहले निर्भरताएँ ढूँढें। फ़ील्ड की जाँच और रिपोर्ट दोबारा बनाने से पहले उसकी परिभाषा तय होनी चाहिए।
- पहला ऐसा समूह चुनें जिसके जिम्मेदार लोग तय हों और जिसे साथ जाँचने पर भी समझ आए कि किस बदलाव ने परिणाम दिया।
| स्थिति | अगला निर्णय | पहले क्या होना चाहिए |
|---|---|---|
| नई पूछताछ किसी जिम्मेदार व्यक्ति तक नहीं पहुँचती | कतार सँभालें और रूटिंग जाँचें | कतार का अस्थायी जिम्मेदार व्यक्ति तय करें |
| दो पूर्वानुमान रिपोर्ट अलग रिकॉर्ड समूह लेती हैं | एक परिभाषा तय करें और रिकॉर्ड मिलाएँ | प्रायोजक परिभाषा का मतभेद सुलझाए |
| अगली कार्रवाई गायब होने के कई कारण हैं | इंटीग्रेशन, प्रक्रिया और फ़ॉलो-अप के सुधार अलग करें | और प्रभावित रिकॉर्ड जाँचें |
| पुराने लेबल असंगत हैं | वर्तमान उपयोग निर्भर हो तभी काम तय करें | फ़ील्ड का उपयोग करने वाला पता करें |
अंत में आपके पास क्या होना चाहिए
हर प्राथमिकता के कारण सहित क्रमबद्ध कार्यसूची। अनिश्चित कारणों के लिए जाँच के काम और पुष्ट कारणों के लिए प्रस्तावित सुधार हों।
9. सुधार तय करें, असर साबित करें और रखरखाव सौंपें
हर काम इतना छोटा रखें कि जाँच सकें। “CRM की गुणवत्ता सुधारें” को स्वीकार या अस्वीकार नहीं कर सकते। “अज्ञात क्षेत्र वाले रिकॉर्ड तय कतार में भेजें और उसके जिम्मेदार व्यक्ति को बताएँ” ज्ञात इनपुट से जाँचा जा सकता है।
पुराने लंबित और नए आने वाले रिकॉर्ड अलग दिखाएँ। समूह बढ़ने से दर गिरे तो पुराने रिकॉर्ड अब भी गलत हो सकते हैं। इसी तरह एक बैच ठीक होने से साबित नहीं होता कि स्रोत ने नई त्रुटियाँ बनाना बंद कर दिया।
- सेटिंग बदलने से पहले अपेक्षित व्यवहार, जिम्मेदार व्यक्ति, निर्भरताएँ, परीक्षण मामले और वापसी की योजना लिखें।
- उचित परीक्षण परिवेश में सामान्य रास्ता और अपवाद जाँचें: गायब इनपुट, जिम्मेदारी बदलना, दोहराई घटनाएँ और आगे की रिपोर्टिंग। अपेक्षित और वास्तविक परिणाम लिखें।
- मिलान और अपवाद के नियम तय होने के बाद ही पुराने रिकॉर्ड सुधारें। जाँचें कि मरम्मत ने सही मान नहीं मिटाए।
- मूल माप दोहराएँ, फिर नए रिकॉर्ड के तय समूह पर निगरानी रखें। समीक्षा का समय वर्कफ़्लो के अनुरूप चुनें और जाँच विफल होने पर प्रतिक्रिया देने वाला व्यक्ति तय करें।
- ब्रीफ़, हस्तांतरण मानचित्र, मीट्रिक परिभाषाएँ, निष्कर्ष रजिस्टर, क्रमबद्ध कार्यसूची और सत्यापन परिणाम के साथ ऑडिट पूरा करें। प्रायोजक से निर्णयों और जिम्मेदारियों की स्वीकृति लें।
अंत में आपके पास क्या होना चाहिए
लागू की जा सकने वाली सुधार योजना और नियमित समीक्षा का जिम्मेदार व्यक्ति। ऑडिट तब पूरा है जब टीम दिखा सके कि क्या मिला, क्या करेगी और कैसे जानेगी कि बदलाव सफल रहा।
स्रोत और आगे पढ़ने के लिए
तरीके को काम में लाएँ।
देखें कि Five Dots आपके रेवेन्यू सिस्टम को कैसे जोड़ता है.
Five Dots ↗ एक्सप्लोर करें