काम टूल से पहले क्यों आता है
ज़्यादातर नाकाम एजेंट प्रोजेक्ट तकनीक की वजह से नहीं, बल्कि काम की वजह से नाकाम होते हैं: वह बहुत व्यापक था („हमारी सेल्स टीम की मदद करना“), बहुत कम होने वाला था (साल में बारह मामले) या गलती होने पर बहुत महँगा था (बिना निगरानी के ग्राहक संवाद)। एक अच्छे पहले एजेंट के पास एक सीमित, बार-बार होने वाला काम होता है, जिसका नतीजा साफ़ हो और जिसे कोई इंसान कुछ सेकंड में जाँच सके।
यह प्लेबुक पाँच चरणों में चयन से लेकर चालू संचालन तक ले जाती है। यह न कोई बचत का वादा करती है, न कंप्लायंस मंज़ूरी का – दोनों आपकी प्रक्रिया, आपके डेटा और आपकी कानूनी स्थिति पर निर्भर हैं। यह वे सवाल देती है जिनके जवाब आपको पहले देने होंगे।
1. तीन समझदार पायलट
- CRM नोट्स को ड्राफ़्ट के रूप में व्यवस्थित करें
- इनपुट: बातचीत का नोट या ट्रांसक्रिप्ट। आउटपुट: ज़रूरी फ़ील्ड (मौक़ा, फ़ैसला लेने वाला, अगला कदम, तारीख, आपत्तियाँ) के लिए व्यवस्थित ड्राफ़्ट। इंसान जाँचता और सेव करता है। क्यों उपयुक्त: ज़्यादा वॉल्यूम, साफ़ लक्ष्य-संरचना, गलतियाँ दिखती हैं और सस्ती हैं।
- आने वाली पूछताछ को पहले छाँटना
- इनपुट: फ़ॉर्म या ईमेल से आई पूछताछ। आउटपुट: कैटेगरी का सुझाव (उपयुक्त / अस्पष्ट / अनुपयुक्त), छूटी जानकारियाँ और ज़िम्मेदार व्यक्ति – ड्राफ़्ट के रूप में, ग्राहक को जवाब के रूप में नहीं। क्यों उपयुक्त: नियम-आधारित, बाद की क्वालिफ़िकेशन से मापने योग्य, कोई बाहरी संपर्क नहीं।
- स्रोतों के साथ आंतरिक नॉलेज सर्च
- इनपुट: किसी कर्मचारी का सवाल। आउटपुट: जवाब का ड्राफ़्ट, उन खास आंतरिक दस्तावेज़ों के हवाले के साथ जिनसे वह आया है। स्रोत नहीं, तो जवाब नहीं। क्यों उपयुक्त: हर सवाल पर फ़ायदा, स्रोत जाँचकर गलती पहचानी जा सकती है, दस्तावेज़ सही चुने जाएँ तो ग्राहक डेटा की ज़रूरत नहीं।
2. चयन ग्रिड
हर उम्मीदवार को चार आयामों पर आँकें। पायलट को पहले तीन में ऊँचे और चौथे में कम अंक चाहिए।
| मानदंड | प्रश्न | अच्छा पायलट |
|---|---|---|
| वॉल्यूम | यह मामला हर हफ़्ते कितनी बार आता है? | इतना बार-बार कि सेटअप और संचालन फ़ायदेमंद हों |
| नियम-आधारितता | क्या वाक्यों में बताया जा सकता है कि अच्छा नतीजा क्या है? | हाँ, कुछ अपवादों के साथ |
| डेटा गुणवत्ता | क्या इनपुट पूरा, व्यवस्थित और उपलब्ध है? | ज़्यादातर हाँ; कमियाँ पता हैं |
| गलती की लागत | अगर नतीजा गलत हो और किसी को पता न चले, तो क्या होगा? | कम: आंतरिक, सुधारने योग्य, बाहर कोई असर नहीं |
3. प्रोसेस रिकॉर्ड करने से लेकर संचालन तक का क्रम
प्रोसेस रिकॉर्ड करना
आज की प्रक्रिया को इनपुट, आउटपुट, अवधि और ज़िम्मेदार व्यक्ति के साथ चरणों में लिखें। नोट करें कि किन चरणों में विवेक चाहिए। एजेंट नियम-आधारित चरण संभालता है; विवेक इंसान के पास रहता है।
अधिकार और न्यूनतम पहुँच
एजेंट को ठीक उतनी ही पहुँच मिलती है जितनी काम को चाहिए – जहाँ पढ़ना काफ़ी है वहाँ सिर्फ़ पढ़ने की, और सबसे छोटे सार्थक डेटा पर। शुरुआत से पहले तय करें कि कौन-सा डेटा प्रोसेस होगा, कहाँ प्रोसेस होगा और इसकी ज़िम्मेदारी किसकी है। आपके मामले में यह डेटा सुरक्षा या कंप्लायंस के अनुरूप है या नहीं, यह यह प्लेबुक तय नहीं करती, बल्कि संबंधित ज़िम्मेदार लोगों के साथ आपकी जाँच तय करती है।
टेस्ट सेट
पहली बार चलाने से पहले असली, गुमनाम किए गए या दोबारा बनाए गए मामलों से एक टेस्ट सेट तैयार करें: सामान्य मामले (रोज़मर्रा), सीमांत मामले (अधूरे, अस्पष्ट, असामान्य रूप से लंबे) और गलती वाले मामले (गलत भाषा, खाली इनपुट, विरोधाभासी जानकारियाँ)। हर मामले के लिए तय करें कि सही नतीजा क्या है – एजेंट का नतीजा देखने से पहले।
इंसानी मंज़ूरी
पायलट में एजेंट ड्राफ़्ट बनाता है। एक इंसान मंज़ूर करता है, सुधारता है या रद्द करता है। हर सुधार गिना जाता है और प्रकार के हिसाब से समूहित होता है। यह सूची यह तय करने का आपका सबसे अहम डेटा स्रोत है कि एजेंट रहेगा या नहीं।
मॉनिटरिंग
- हर हफ़्ते मामलों की संख्या और बिना सुधार वाले मामलों का हिस्सा।
- सुधारों का प्रकार और आवृत्ति।
- हर मामले पर लगने वाला समय पहले और बाद में (मापा हुआ, अनुमान नहीं)।
- विफलताएँ, टाइमआउट, खाली नतीजे।
4. शुरुआत से पहले संचालन लागत निकालें
एक एजेंट की लागत तीन हिस्सों में होती है: एक बार का सेटअप (प्रोसेस रिकॉर्ड करना, सेटअप, टेस्ट सेट), चालू संचालन (उपयोग शुल्क, मेंटेनेंस, लोगों का मंज़ूरी का समय) और गलती की लागत (सुधार, दोबारा काम)। शुरू करने से पहले तीनों का हिसाब लगाएँ – और मंज़ूरी का समय ईमानदारी से जोड़ें: जिस एजेंट के 40 % ड्राफ़्ट सुधारने पड़ें, वह कम बचत करता है।
फ़ैसले के लिए एक आसान गणना काफ़ी है: हर महीने के मामले × (पहले के मिनट − बाद के मिनट) ÷ 60 से घंटों में खाली हुई क्षमता मिलती है। इसे एक अनुमानित घंटे की दर से गुणा करने पर एक गणना-आधारित फ़ायदा मिलता है; उसमें से मासिक संचालन लागत घटाई जाती है। जब यह नेट वैल्यू पॉज़िटिव हो, तभी एक बार का सेटअप महीनों में वसूल हो सकता है। „बाद के“ मिनट में इंसान का मंज़ूरी का समय भी शामिल है – सिर्फ़ एजेंट के चलने का समय नहीं।
- पायलट शुरू होने से पहले कम से कम दस असली मामलों पर पहले के मिनट मापें।
- उपयोग शुल्क वैसे दर्ज करें जैसे वे अपेक्षित वॉल्यूम पर लगेंगे, टेस्ट वॉल्यूम पर नहीं।
- घंटे की दर को एक धारणा के रूप में दर्ज करें और किसी नतीजे को बचाने के लिए बाद में उसे न बदलें।
5. रोकने के मापदंड
शुरुआत से पहले तय करें कि पायलट कब खत्म होगा – दोनों दिशाओं में। जो मापदंड चार हफ़्ते बाद लिखता है, वह नतीजे को डेटा के बजाय मूड के हिसाब से आँकता है।
- रोकना
- चार हफ़्तों के बाद सुधार दर पहले से तय सीमा से ऊपर; बाहर असर डालने वाली एक गलती; संचालन लागत नियोजित दायरे से ऊपर; टीम एजेंट का इस्तेमाल करने के बजाय उससे बचकर काम करती है।
- संचालन में सौंपना
- कम से कम चार हफ़्तों तक सुधार दर लगातार लक्ष्य से नीचे; काम का समय मापने योग्य रूप से घटा; चालू संचालन के लिए ज़िम्मेदार व्यक्ति तय; अधिकार और डेटा फ़्लो दस्तावेज़ित।
- विस्तार
- तभी, जब पहला एजेंट संचालन में हो। दूसरा पायलट पहले के साथ-साथ शुरू नहीं होता।
नीचे दिया ऑटोमेशन प्रोफ़ाइल इस प्लेबुक की सभी बातें एक पेज पर समेटता है: काम, मापदंड, अधिकार, टेस्ट सेट, मंज़ूरी, मॉनिटरिंग, लागत और रोकने के मापदंड। पहला टूल चुनने से पहले इसे भरें।
डाउनलोड
साथ ले जाने के लिए
Markdown किसी भी टेक्स्ट एडिटर या नोट टूल में खुलता है। CSV फ़ाइलें सेमीकोलन से अलग होती हैं और सीधे Excel, Numbers या LibreOffice में खुलती हैं।
