क्यों समर्थन स्वचालन व्यापार को नुकसान पहुंचाता है

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



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

1. प्राधिकरण प्रक्रिया को ठीक करें - सामान्य रूप से स्क्रीन डिज़ाइन करें और उपयोगकर्ताओं की पीड़ा को समाप्त करें। यह एनएनएन रूबल से खर्च होगा।
2. स्वचालित समर्थन - एक आभासी सहायक को कनेक्ट करें जो ग्राहकों को एप्लिकेशन का उपयोग करने का तरीका सिखाएगा। यह एनएन रूबल से खर्च होगा।

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

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

प्रकरण। बैंक चाहता था कि हमारे आभासी सहायक ग्राहकों के साथ कार्ड के वितरण का समन्वय करें। स्क्रिप्ट स्वचालन के दौरान, यह पता चला कि प्रक्रिया स्वयं गलत तरीके से बनाई गई थी: उपयोगकर्ता पहले एक क्षेत्र का चयन करता है, फिर मानचित्र को वांछित शहर में लाया जाता है और उसके बाद ही वितरण पते पर सहमति होती है।

यह दृष्टिकोण उन लोगों के साथ समस्याओं का एक समूह की ओर जाता है जिन्होंने शहर के बारे में आइटम पर ध्यान नहीं दिया - यह "मॉस्को" के रूप में पूर्वनिर्मित है और कई बस इसे नोटिस नहीं करते हैं। नतीजतन, रोबोट क्लाइंट को कॉल करता है और कहता है: "हेलो, मॉस्को में आपका कार्ड, कब डिलीवर करना सुविधाजनक है?", और क्लाइंट जवाब देता है: "ब्ल **, मैं नोवोसिबिर्स्क में हूं, आप कैसे कर रहे हैं?"

ऐसी प्रक्रिया को ठीक करना मुश्किल नहीं है: आपको आवेदन में स्पष्ट रूप से पूछना होगा कि कार्ड कहां लेना है। लेकिन हमें संयुक्त को सही ढंग से प्रतिक्रिया देने और अन्य क्षेत्रों में कार्ड भेजने के लिए रोबोट को सिखाना था।

नतीजतन, बैंक ने डिलीवरी पर पैसा खो दिया और समर्थन की मदद से बग को बंद कर दिया, हालांकि यह आवेदन प्रक्रिया को पूरा करने के लायक था - कोई समस्या नहीं होगी।

यह एक अलग मामला नहीं है। हमने 6 मिलियन उपयोगकर्ताओं के अनुरोधों का विश्लेषण किया और देखा कि सबसे आम दर्द उत्पाद में केले जाम है।

यदि आप व्यावसायिक प्रक्रियाओं को संशोधित करते हैं या UX डिज़ाइन बदलते हैं, तो 10 सबसे उच्च आवृत्ति परिदृश्यों में से 5 (फिनटेक, रिटेल, टेलीकॉम में) बंद हो सकते हैं।

लेकिन सवाल यह है कि उत्पाद टीम कैसे जानती है कि सुधार करने की क्या जरूरत है?

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



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

और सहायक आंशिक रूप से दोषी हैं।

भूल गया कार्य: संचार

एक रोबोट के साथ उत्पाद में सभी छेदों को बंद करने की कोशिश करना एकमात्र समस्या नहीं है जो वर्चुअल असिस्टेंट एक व्यवसाय के लिए बनाते हैं।

समर्थन की पहली पंक्तियों पर स्वचालन के आगमन के साथ, हर कोई कंपनी के लिए सिस्टम विफलताओं और उपयोगकर्ता के दर्द के बारे में जानकारी लाना भूल गया। हमने सबसे अधिक सेवा समर्थन पर ध्यान केंद्रित किया, लेकिन उत्पाद प्रबंधकों के साथ संचार स्थापित करने के तरीके के बारे में नहीं सोचा।

इसलिए, एक दिन यूक्रेन से हमारे सहयोगी इस स्थिति में भाग गए: उन्होंने एक बड़े बैंक में एक सहायक को लॉन्च किया और ऑपरेटर को स्विच करने के लिए एल्गोरिथ्म को सही ढंग से कॉन्फ़िगर नहीं किया। जब बुनियादी भुगतान की कार्यक्षमता विफल हो गई, और ग्राहकों से अनुरोध गिर गया, तो रोबोट को गूंगा किया गया, प्रश्न को सुधारने के लिए कहा गया, या ओटमीज़वत्स्य: "हाँ, हाँ, इसे जल्द ही ठीक करें।"

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

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

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

कैसे हमने सहायकों को समस्याओं के बारे में बात करना सिखाया

सबसे पहले, हमें यह समझने की जरूरत है कि उत्पादों को किस बारे में सूचित किया जाना चाहिए - दूसरे शब्दों में, एक घटना को क्या माना जाता है और क्या नहीं है।

रोबोट के लिए अनुरोधों की मात्रा के मापदंडों को समझने और छोटे से बड़े पैमाने पर त्रुटियों को अलग करने के लिए सीखने के लिए, हमने इसे कई मानदंडों द्वारा घटना को निर्धारित करने के लिए प्रशिक्षित किया:

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

क्लस्टरिंग एल्गोरिदम समान कॉल के समूहों की पहचान करता है, भले ही वे मार्कअप में हों या नहीं। यदि उपयोगकर्ता बड़े पैमाने पर समर्थन से संपर्क करते हैं और संदेशों की गतिशीलता पिछले कुछ मिनटों / घंटों / दिनों से बढ़ रही है - यह एक घटना है।

अभी तक सही नहीं है, लेकिन हमने सीखा है कि कंपनी के कर्मचारियों के साथ संचार की समस्या को कैसे हल किया जाए। यदि सहायक समझता है कि कोई समस्या आ गई है, तो वह इस एल्गोरिथम के अनुसार कार्य करता है:

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

जब सहायक ने बड़े पैमाने पर विफलताओं की रिपोर्ट करना शुरू किया, तो हमने देखा कि कई त्रुटियां तकनीकी समस्याओं से संबंधित थीं। और हमने सीखा कि कैसे जल्दी से उन्हें जवाब देना है।

उदाहरण के लिए, जब बजट भुगतान का तर्क हमारे सामने आया और उपयोगकर्ता करों का भुगतान नहीं कर सके, तो रोबोट ने एक घंटे में एक त्रुटि रिपोर्ट भेजी। टीम ने जल्दी से संस्करण को वापस ले लिया और जल्दी से इस मुद्दे को हल किया।

यह लिखने से बहुत बेहतर है: "हाँ, हाँ, जल्द ही सबकुछ ठीक हो जाएगा । " और उपयोगकर्ताओं के संबंध में अधिक ईमानदार।

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

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

अन्यथा, समर्थन व्यवसाय के लिए एक स्थायी बैसाखी बन जाता है: यह समस्याओं को हल करने के बजाय, छेद और ओटमाज्वैट्स को अंतिम रूप से बंद कर देता है।