कब स्वचालित करें और कब सौंपें: SLA डिज़ाइन

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

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

झूठी द्विभाजन (बाइनरी)

ज़्यादातर टीमें इसे या-तो/या वाले निर्णय के रूप में देखती हैं: कौन-सी प्रक्रियाएं स्वचालित हों, कौन-सी मैनुअल रहें। यह सोच दोनों दिशाओं में बुरे नतीजे देती है। ज़्यादा ऑटोमेट करने पर ग्राहक $400 की वारंटी क्लेम को लेकर बॉट से बहस में फंस जाते हैं जबकि आपका CSAT चुपचाप गिरता रहता है। कम ऑटोमेट करने पर आपकी टीम पासवर्ड रीसेट और ऑर्डर-स्टेटस जैसे सवालों को मैनुअली संभालती रहती है जिन्हें एक वर्कफ़्लो सेकंडों में हल कर सकता था, और ऐसे काम पर मानव-संसाधन खर्च करती है जिसमें किसी निर्णय-क्षमता की ज़रूरत नहीं होती।

बेहतर सवाल यह नहीं है कि “क्या इस प्रक्रिया को स्वचालित किया जाए” — बल्कि यह है कि “किन परिस्थितियों में इस विशिष्ट इंटरैक्शन को इंसान की ज़रूरत है, और फ्लैग होने के बाद उस इंसान को कितनी तेज़ी से प्रतिक्रिया देनी चाहिए?” यह एक SLA का सवाल है, ऑटोमेशन-रणनीति का नहीं, और इसका जवाब पूरे वर्कफ़्लो के स्तर पर नहीं, बल्कि व्यक्तिगत ट्रिगर्स के स्तर पर देना होगा।

तीन वेरिएबल जो सीमा तय करें

1. उलटाव-क्षमता (Reversibility)

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

2. विश्वास स्तर (Confidence)

एजेंट द्वारा की गई हर वर्गीकरण — इरादा, भावना, तात्कालिकता — के साथ एक कॉन्फिडेंस स्कोर आता है, भले ही आपका डैशबोर्ड उसे न दिखाए। SLA को सभी स्वचालित समाधानों के साथ एक जैसा व्यवहार नहीं करना चाहिए। 95% कॉन्फिडेंस और एक ज्ञात समाधान पथ के साथ “शिपिंग डिले” के रूप में वर्गीकृत टिकट स्वचालित रूप से हल हो सकता है। वही इरादा 60% कॉन्फिडेंस पर वर्गीकृत होने पर, या फ्री-टेक्स्ट फ़ील्ड में पहचानी गई नकारात्मक भावना के साथ आने पर, किसी व्यक्ति के पास जाना चाहिए — बाद में नहीं, बल्कि स्वचालित कार्रवाई शुरू होने से पहले।

3. दांव पर लगा जोखिम (Stakes)

ऑर्डर वैल्यू, कॉन्ट्रैक्ट टियर, और ग्राहक लाइफटाइम वैल्यू — ये सभी रूटिंग लॉजिक में शामिल होने चाहिए। पहली बार खरीदने वाले ग्राहक का $30 का रिटर्न और 60 दिनों में रिन्यूअल वाले एंटरप्राइज़ अकाउंट का $3,000 का ऑर्डर एक जैसा फैसला नहीं है, भले ही बताया गया कारण (“गलत साइज़,” “क्षतिग्रस्त पहुंचा”) समान हो। ट्रांज़ैक्शन डेटा को इंटरैक्शन के साथ रीयल-टाइम में जोड़ना — न कि इसे मैनुअली खोजना — यही है जो बड़े पैमाने पर दांव-आधारित रूटिंग को संभव बनाता है।

एक व्यावहारिक उदाहरण: टियर्ड SLA के साथ RMA ट्रायाज

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

इस वर्कफ़्लो के लिए ऑटोमेट/हैंडऑफ की सीमा को इस तरह टियर किया जा सकता है:

• टियर 1 — पूरी तरह स्वचालित, किसी SLA की ज़रूरत नहीं: रिटर्न का कारण एक परिभाषित डिफ़ेक्ट कोड है, आइटम की वैल्यू $75 से कम है, ग्राहक का कोई खुला विवाद नहीं है, और फ्री-टेक्स्ट फ़ील्ड पर भावना न्यूट्रल या पॉज़िटिव है। एजेंट रिटर्न को स्वीकृत करता है, शिपिंग लेबल बनाता है, और मामला बंद करता है — कोई इंसान इसे छूता नहीं।
• टियर 2 — तेज़-प्रतिक्रिया सुरक्षा जाल के साथ स्वचालित: आइटम की वैल्यू $75–$400 है, या रिटर्न का कारण “अन्य” है और इसमें निर्णय-क्षमता की ज़रूरत है, लेकिन भावना न्यूट्रल है। एजेंट एक समाधान का ड्राफ्ट तैयार करता है और उसे RMA रिकॉर्ड से जुड़े Conversation थ्रेड पर पोस्ट करता है, जिसमें उसके लागू होने से पहले किसी इंसान द्वारा स्वीकृत या ओवरराइड करने के लिए 4 बिज़नेस-आवर का SLA दिया जाता है। अगर समय पर कोई जवाब नहीं आता, तो ड्राफ्ट अपने आप स्वीकृत हो जाता है — यहां इंसान एक जांच है, बाधा नहीं।
• टियर 3 — तुरंत हैंडऑफ, कोई ऑटो-एक्ज़ीक्यूशन नहीं: आइटम की वैल्यू $400 से अधिक है, ग्राहक को बार-बार रिटर्न करने के जोखिम के रूप में फ्लैग किया गया है, या फ्री-टेक्स्ट विवरण पर सेंटीमेंट विश्लेषण निराशा या सार्वजनिक रिव्यू छोड़ने की धमकी दिखाता है। एजेंट समाधान करने से रुक जाता है और 1-घंटे के SLA के साथ एक Conversation थ्रेड बनाता है, नियुक्त प्रतिनिधि को टैग करता है और संदेश के साथ ग्राहक का पूरा ट्रांज़ैक्शन और व्यवहार इतिहास सामने लाता है।

इस रूटिंग के लिए ट्रिगर डेटा ग्राहक की ID पर तीन सिग्नल प्रकारों को जोड़कर आता है: ट्रांज़ैक्शन रिकॉर्ड (ऑर्डर वैल्यू, रिटर्न इतिहास), वॉइस सिग्नल (RMA फ्री-टेक्स्ट फ़ील्ड से भावना और एंटिटी एक्सट्रैक्शन), और व्यवहारिक संदर्भ (क्या इस ग्राहक ने सबमिट करने से पहले के दिनों में बार-बार रिटर्न्स पॉलिसी पेज देखा है — एक Clickstream Publisher इवेंट जो असली खराबी के बजाय पूर्व-नियोजन का संकेत देता है)। इनमें से कोई भी अकेला सिग्नल यह नहीं बताता कि कौन-सा टियर लागू होता है; साथ जोड़ने पर ही यह पता चलता है।

SLA को इस तरह लिखें कि वह लागू करने योग्य हो, केवल आशा नहीं

एक ह्यूमन-इन-द-लूप SLA जो किसी ऐसे पॉलिसी दस्तावेज़ में पड़ा रहता है जिसे कोई नहीं पढ़ता, वह SLA नहीं है — वह एक उम्मीद है। इसे लागू करने योग्य बनाने के लिए तीन चीज़ें ज़रूरी हैं:

• एक ऐसी घड़ी जो अपने आप शुरू हो जाए। जिस पल कोई वर्कफ़्लो कंडीशन किसी इंटरैक्शन को इंसान के पास भेजती है, उसी क्षण थ्रेड के खिलाफ एक काउंटडाउन शुरू हो जाना चाहिए, न कि किसी शेयर्ड इनबॉक्स के खिलाफ जहां वह बिना खुले पड़ा रह सकता है।
• एक एस्केलेशन पथ। अगर नियुक्त व्यक्ति SLA विंडो के भीतर जवाब नहीं देता, तो थ्रेड को स्वतः रीअसाइन होना चाहिए या मैनेजर को सूचित करना चाहिए — जो थ्रेड अपनी विंडो से आगे खुला रह गया है, वह खुद एक सिग्नल है जिस पर कार्रवाई की जानी चाहिए।
• क्या हुआ इसका एक रिकॉर्ड। एजेंट ने कब हैंडऑफ किया, क्यों, किसने इसे संभाला, इसमें कितना समय लगा, क्या फैसला लिया गया। इसके बिना आप यह नहीं बता सकते कि आपकी टियरिंग सही ढंग से कैलिब्रेट हुई है या नहीं — कि क्या टियर 2 आइटम वाकई कम-जोखिम वाले हैं या आप ऐसी चीज़ों को ऑटो-अप्रूव कर रहे हैं जिन्हें एस्केलेट होना चाहिए था।

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

जहां एजेंट्स को कभी भी काम पूरा करने की कोशिश नहीं करनी चाहिए

कुछ श्रेणियां कॉन्फिडेंस स्कोर से स्वतंत्र, पूर्ण ऑटोमेशन के खिलाफ एक स्थायी नियम की हकदार हैं:

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

SurveyAnalytica कैसे मदद करता है

SurveyAnalytica का नो-कोड एजेंट बिल्डर ठीक इसी सीमा-समस्या को ध्यान में रखकर डिज़ाइन किया गया है। एजेंट्स मल्टी-टर्न बातचीत कर सकते हैं, कार्रवाइयां निष्पादित कर सकते हैं, और नॉलेज बेस से क्वेरी कर सकते हैं — लेकिन उन्हें स्पष्ट रूप से हैंडऑफ करने के लिए भी कॉन्फ़िगर किया जा सकता है, जिससे इंटरैक्शन को पूरे संदर्भ (लिंक्ड रिस्पॉन्स, ट्रांज़ैक्शन रिकॉर्ड, ग्राहक इतिहास) के साथ पहले से जुड़े हुए Conversation थ्रेड में रूट किया जाता है, बजाय इसके कि एक ट्रांसक्रिप्ट किसी प्रतिनिधि पर डाल दी जाए और उसे यह समझने के लिए छोड़ दिया जाए कि क्या हुआ था।

Flows इंजन ही वह चीज़ है जो RMA उदाहरण जैसी टियर्ड रूटिंग को सैद्धांतिक के बजाय व्यावहारिक बनाती है: क्लिकस्ट्रीम इवेंट्स, ट्रांज़ैक्शन डेटा, और फ्री-टेक्स्ट फ़ील्ड्स से भावना स्कोर — ये सभी एक ही ट्रिगर लॉजिक में फ़ीड हो सकते हैं, ताकि “ऑटोमेट करें, तेज़ी से जांचें, या तुरंत हैंडऑफ करें” का फैसला अलग-थलग किसी एक डेटा स्रोत से नहीं, बल्कि रीयल-टाइम में जुड़े हुए सिग्नलों से लिया जाए। थ्रेड लाइफ़साइकल स्टेट्स और एक्सपायरी टाइमस्टैम्प आपको वह लागू करने योग्य घड़ी देते हैं जिसकी एक SLA को ज़रूरत होती है, और Audit थ्रेड्स एक छेड़छाड़-प्रतिरोधी ट्रेल प्रदान करते हैं जब कोई पूछे कि कोई फैसला कैसे लिया गया।

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

निष्कर्ष

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