Agentforce लॉन्च चेकलिस्ट: T-90 दिनों से गो-लाइव तक

काउंटडाउन “कभी-न-कभी” वाली सूची से बेहतर क्यों है

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

T-90 दिन · दायरा और बेसलाइन

जो मापा नहीं, वह सुधारा नहीं जा सकता। किसी भी क्लीनअप से पहले तय करें कि एजेंट क्या पढ़ेगा और वह डेटा आज कितना स्कोर करता है।

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

T-60 दिन · सुधार

नतीजों पर सुविधा के नहीं, जोखिम के क्रम में काम करें। सबसे पहले PII — यही एकमात्र श्रेणी है जो रेगुलेटरी इंसिडेंट बन सकती है।

• एजेंट द्वारा पढ़ी जाने वाली टेक्स्ट फ़ील्ड्स से हर SSN और क्रेडिट-कार्ड फ़ाइंडिंग हटाएँ।
• जिन मुख्य फ़ील्ड्स पर एजेंट निर्भर है, उन्हें भरें — खाली Description अस्पष्ट जवाब पर मजबूर करती है।
• पिकलिस्ट और रेफ़रेंस वैल्यू को मानकीकृत करें ताकि “US”, “USA” और “United States” तीन अलग-अलग तथ्य न रहें।
• स्ट्रक्चर्ड फ़ील्ड्स (ईमेल, फ़ोन नंबर, ID) के अमान्य फ़ॉर्मेट ठीक करें — एजेंट उन्हें ज्यों-का-त्यों दोहराते हैं।
• एजेंट द्वारा पढ़े जाने वाले ऑब्जेक्ट्स पर डुप्लिकेट मर्ज करें ताकि एक ग्राहक का एक ही इतिहास हो।
• वे बासी रिकॉर्ड अपडेट या आर्काइव करें जो एजेंट को आत्मविश्वास भरे लेकिन पुराने जवाब दिलवाते।

T-30 दिन · सत्यापन

वही स्कैन दोबारा चलाएँ और बेसलाइन से तुलना करें। साइन-ऑफ़ आश्वासनों पर नहीं, सबूतों पर टिका होना चाहिए।

• बेसलाइन वाले ही ऑब्जेक्ट्स और फ़ील्ड्स पर पूरा स्कैन सूट दोबारा चलाएँ।
• सुनिश्चित करें कि हर एजेंट-पठित ऑब्जेक्ट पर आप लॉन्च थ्रेशोल्ड (नीचे की तालिका) पूरे करते हैं।
• PII एक्सपोज़र संख्याओं के आधार पर लिखित कंप्लायंस साइन-ऑफ़ लें।
• पहले/बाद के स्कोर दस्तावेज़ करें — यही सबूत है कि org लॉन्च के लिए तैयार था।

लॉन्च सप्ताह और उसके बाद

जिस पल यूज़र रिकॉर्ड डालते रहते हैं, डेटा क्वालिटी गिरने लगती है। रेडीनेस एक माइलस्टोन नहीं, एक नियमित ताल है।

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

गो-लाइव थ्रेशोल्ड एक नज़र में

सत्यापन फ़ेज़ के पास-मानदंड। हर संख्या के पीछे की पूरी वजह Salesforce डेटा क्वालिटी बेंचमार्क पेज पर है।

अगर आधी चेकलिस्ट फ़ेल हो जाए तो?

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