कस्टमर सक्सेस हेल्थ स्कोर: AI के बिना स्पष्ट सिग्नल

अस्पष्ट अकाउंट स्कोर समस्याएँ क्यों पैदा करते हैं

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

जब कोई स्कोर समझा नहीं सकता, तो कस्टमर सक्सेस मैनेजर उस पर भरोसा करना बंद कर देते हैं। वे लॉग-इन की अस्थायी समस्या वाले अकाउंट के पीछे लग सकते हैं और उस शांत ग्राहक को नज़रअंदाज़ कर सकते हैं जिसका साप्ताहिक उपयोग दो महीनों से घट रहा है। लेबल चेतावनी तो देता है, लेकिन आगे क्या करना है यह नहीं बताता।

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

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

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

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

ऐसे सिग्नल चुनें जिन्हें आपकी टीम समझा सके

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

तथ्यों और राय को अलग रखें। तथ्य यह हो सकता है कि इस महीने अकाउंट में तीन सक्रिय उपयोगकर्ता थे, दो सपोर्ट टिकट खोले गए या 45 दिनों में रिन्यूअल है। राय यह हो सकती है कि अकाउंट की रुचि कम लग रही है या नया संपर्क असंतुष्ट सुनाई देता है। राय उपयोगी हो सकती है, लेकिन उसके साथ ओनर, तारीख और कारण होना चाहिए।

ऐसे सिग्नल चुनें जिन्हें लोग नियमित रूप से दर्ज कर सकें

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

पारदर्शी अकाउंट हेल्थ सिग्नल में ये शामिल हो सकते हैं:

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

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

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

AppMaster टीमों को नो-कोड कस्टमर पोर्टल या इंटरनल टूल बनाने में मदद कर सकता है, जहाँ ये सिग्नल एक जगह रहें और हर रेटिंग के पीछे के नियम दिखाई दें।

प्रोडक्ट उपयोग को संदर्भ के साथ मापें

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

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

एक तय अवधि रखें, जैसे पिछले 30 दिन। पूरी की गई कार्रवाइयों और सक्रिय टीम सदस्यों की संख्या गिनें, फिर उसे अकाउंट के हाल के पैटर्न से तुलना करें। जो टीम आम तौर पर महीने में 400 वर्कफ़्लो पूरे करती है, लेकिन इस महीने 80 ही पूरे करती है, उस पर ध्यान देना चाहिए। जो छोटी टीम नियमित रूप से 20 वर्कफ़्लो पूरा करती है, वह स्वस्थ हो सकती है।

हर ग्राहक को एक ही सार्वभौमिक लक्ष्य से न आँकें। पाँच लाइसेंस वाले अकाउंट से 500 लाइसेंस वाले अकाउंट जितनी गतिविधि की उम्मीद नहीं होनी चाहिए। ग्राहक के लक्ष्य, रोलआउट का चरण और मौसमी काम, सामान्य उपयोग को प्रभावित करते हैं।

उपयोग सिग्नल को समझाना आसान रखें:

• पिछली 30 दिनों की तुलना में गतिविधि स्थिर या बढ़ रही है।
• दो रिव्यू अवधियों में गतिविधि स्पष्ट रूप से घटी है।
• सक्रिय उपयोगकर्ताओं की कमी रोलआउट, पहुँच या स्टाफिंग समस्या की ओर इशारा कर सकती है।
• मुख्य कार्रवाइयों का पूरा न होना सीधे अकाउंट जाँचने का कारण है।

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

ग्राहकों को दोष दिए बिना सपोर्ट गतिविधि जोड़ें

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

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

सपोर्ट इंटरैक्शन को एक समान तरीके से दर्ज करने के लिए छोटी साझा स्केल रखें:

• सकारात्मक: ग्राहक पुष्टि करता है कि जवाब काम कर गया या टीम को धन्यवाद देता है।
• तटस्थ: ग्राहक को जानकारी चाहिए और वह निराश नहीं दिखता।
• चिंताजनक: ग्राहक किसी रुके हुए काम, देरी या बार-बार की उलझन की सूचना देता है।
• अत्यावश्यक: काम रुक गया है, समय सीमा जोखिम में है या समस्या कई उपयोगकर्ताओं को प्रभावित कर रही है।

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

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

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

सपोर्ट गतिविधि को एक सरल सवाल का जवाब देना चाहिए: क्या ग्राहक आगे बढ़ सकता है? खुले अवरोध और अनसुलझे पैटर्न सिग्नल को नीचे ले जाने चाहिए। सोच-समझकर पूछे गए सवाल, सफल समाधान और सक्रिय सीखने से अक्सर उलटा संकेत मिलता है।

रिन्यूअल का समय और अकाउंट बदलाव ट्रैक करें

कॉन्ट्रैक्ट खत्म होने से काफी पहले रिन्यूअल की तारीख कार्रवाई का संकेत देनी चाहिए। अगर रिन्यूअल से सात दिन पहले स्कोर लाल होता है, तो टीम को चेतावनी बहुत देर से मिलेगी। तारीख से 120, 90, 60 और 30 दिन पहले रिन्यूअल सिग्नल सेट करें, ताकि अकाउंट ओनर उपयोगी बातचीत के लिए तैयार हो सके।

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

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

रिन्यूअल रिकॉर्ड में ये बातें हो सकती हैं:

• रिन्यूअल तारीख और नोटिस की अंतिम तारीख।
• मौजूदा प्लान, कॉन्ट्रैक्ट अवधि और समय को प्रभावित करने वाली शर्तें।
• ग्राहक और आपकी कंपनी, दोनों तरफ का नामित रिन्यूअल ओनर।
• ज्ञात जोखिम, जैसे बजट समीक्षा, विलय या नेतृत्व में बदलाव।
• अगली नियोजित बातचीत और उसकी तारीख।

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

ज्ञात जोखिमों को अनुमान नहीं, तथ्य की तरह दर्ज करें। «ग्राहक ने कहा कि प्रोक्योरमेंट मई में बजट समीक्षा शुरू करेगा» फॉलो-अप का कारण देता है। «शायद रिन्यू न करे» कुछ नहीं समझाता और कस्टमर रिटेंशन ट्रैकिंग को बिगाड़ सकता है।

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

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

स्पष्ट नियमों के साथ अकाउंट नोट्स इस्तेमाल करें

मैनुअल नोट्स वह संदर्भ देते हैं जो प्रोडक्ट डेटा नहीं दे सकता। लॉग-इन में कमी चिंताजनक लग सकती है, लेकिन हाल की कॉल से पता चल सकता है कि ग्राहक की टीम नियोजित ऑफिस शिफ्ट के दौरान काम रोक रही है। नोट्स में नया लक्ष्य, स्पॉन्सर बदलाव या मीटिंग में उठी चिंता दर्ज की जा सकती है।

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

एक सरल फ़ॉर्मेट उपयोगी है:

• तारीख और अकाउंट ओनर।
• मीटिंग या संपर्क का कारण।
• ग्राहक का लक्ष्य, चिंता या बदलाव, सामान्य भाषा में।
• सहमत कार्रवाई, ओनर और ड्यू डेट।

उदाहरण: «12 मई, प्रिया। तिमाही समीक्षा। ऑपरेशंस लीड 1 जून से पहले अप्रूवल फ्लो शुरू करना चाहता है। उन्होंने बताया कि दो मैनेजरों को अभी भी पहुँच नहीं मिली है। प्रिया 14 मई तक एक्सेस सूची भेजेंगी।» अगला अकाउंट ओनर इस नोट पर कार्रवाई कर सकता है। AppMaster कस्टमर पोर्टल में टीम इस नोट को उपयोग, सपोर्ट और रिन्यूअल विवरण के साथ रख सकती है।

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

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

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

स्कोर चरण दर चरण बनाएँ

ऐसे स्कोर से शुरुआत करें जिसे लोग कागज़ पर भी निकाल सकें। 0 से 100 की सीमा परिचित है, लेकिन लिखित नियमों से कम महत्वपूर्ण है। हर सिग्नल को सीमित पॉइंट दें और दर्ज करें कि वे क्यों मिलते या घटते हैं।

प्रोडक्ट उपयोग 30 पॉइंट, सपोर्ट गतिविधि 20, रिन्यूअल का समय 25 और अकाउंट नोट्स 25 पॉइंट दे सकते हैं। मैनेजर अकाउंट खोलकर बदलाव देख सके, जैसे «21 दिनों से किसी साप्ताहिक सक्रिय उपयोगकर्ता ने लॉग-इन नहीं किया, इसलिए -10»। जब तक सिस्टम प्रमाण न दिखाए, «एंगेजमेंट जोखिम» जैसे लेबल से बचें।

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

हर स्कोर बैंड के साथ स्पष्ट कार्रवाई जोड़ें:

• 80-100: सामान्य सक्सेस प्लान जारी रखें और विस्तार के अवसर देखें।
• 60-79: अगली तय बातचीत में हाल की अकाउंट गतिविधि की समीक्षा करें।
• 40-59: पाँच कारोबारी दिनों के भीतर ग्राहक से संपर्क करने के लिए ओनर तय करें।
• 0-39: संपर्क से पहले आंतरिक समीक्षा करें और रिकवरी प्लान पर सहमति बनाएं।

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

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

हर नियम बदलाव का चेंज लॉग रखें। तारीख, पुराना नियम, नया नियम और कारण दर्ज करें। बाद में स्कोर बदलने पर टीम समझ सकेगी कि ग्राहक का व्यवहार बदला या स्कोरिंग तरीका।

उदाहरण: ऐसा अकाउंट जिसे चेक-इन चाहिए

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

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

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

एक स्कोर को विवरण छिपाने न दें, हर सिग्नल स्पष्ट रखें:

• उपयोग: कर्मचारी के जाने के बाद सप्ताह दर सप्ताह 40% कम।
• सपोर्ट: दो खुले टिकट, जिनमें एक नियमित प्रक्रिया को प्रभावित करता है।
• रिन्यूअल: 75 दिनों में, इसलिए कार्रवाई के लिए समय है।
• अकाउंट नोट: ग्राहक ने नए कर्मचारी के लिए ऑनबोर्डिंग सपोर्ट माँगा है।

इस अकाउंट को आपातकालीन प्रतिक्रिया नहीं, योजनाबद्ध फॉलो-अप चाहिए। कस्टमर सक्सेस मैनेजर को दो कारोबारी दिनों में एक्सपोर्ट टिकट की स्थिति पक्की करनी चाहिए और नए कर्मचारी के लिए 30 मिनट का ट्रेनिंग सेशन देना चाहिए।

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

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

स्कोरिंग की आम गलतियाँ

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

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

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

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

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

कार्रवाई से पहले डेटा की ताज़गी जाँचें

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

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

पारदर्शी स्कोर लोगों को उन अकाउंट पर ध्यान केंद्रित करने में मदद करता है जिनसे अभी संपर्क चाहिए। उसे अकाउंट ओनर के निर्णय की जगह कभी नहीं लेना चाहिए।

तेज़ रिव्यू चेकलिस्ट

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

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

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

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

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

स्कोर को रोज़ के काम में शामिल करें

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

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

एक सरल साप्ताहिक रूटीन रखें:

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

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

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

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