ग्राहक सहायता के ऑगियन अस्तबल से निपटना: हमारी सफलता की कहानी

एक बार, सोशल डिस्कवरी ग्रुप के बिजनेस सपोर्ट विभाग को चार वर्षों में जमा हुए 1500 टिकटों के बैकलॉग को खत्म करने की कठिन चुनौती का सामना करना पड़ा।

इतनी अधिक मात्रा में मुद्दों का प्रबंधन करना एक गंभीर उपक्रम था, और हमने खुद को KPI के साथ बनाए रखने के लिए लगातार संघर्ष करते हुए पाया।

हमारे सर्वोत्तम प्रयासों के बावजूद, टिकट एक स्प्रिंट से दूसरे स्प्रिंट में फेरबदल करते रहे, जिससे ग्राहक निराश हुए और हम अभिभूत महसूस कर रहे थे।

इस लेख में, हम हरक्यूलिस के प्रसिद्ध छठे श्रम की याद दिलाते हुए, इस असंभव प्रतीत होने वाले कार्य से निपटने के अपने अनुभव को साझा करना चाहेंगे।

हम आपको SDGroup टीम द्वारा सामना की गई चुनौतियों और हमारे विभाग की प्रक्रियाओं के पुनर्निर्माण के लिए उठाए गए कदमों के बारे में बताएंगे।

हमने STATIK दृष्टिकोण अपनाया, जो बैकलॉग को दूर करने और हमारी टीम को बहुत जरूरी राहत देने में हमारी मदद करने में अविश्वसनीय रूप से प्रभावी साबित हुआ।

इसलिए, यदि आप टिकटों के बैकलॉग से निपटने के लिए व्यावहारिक अंतर्दृष्टि की तलाश कर रहे हैं, तो पढ़ते रहें!

हम 1,500-टिकट कतार के साथ कैसे समाप्त हुए

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

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

सहकर्मी सभी प्रासंगिक जानकारी एकत्र करते हैं, जिसमें प्रजनन चरण और स्क्रीनशॉट जारी करना शामिल है, और जीरा में एक टिकट बनाते हैं, इसे हमारे विभाग को सौंपते हैं।

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

हमें रोजाना औसतन 20-30 टिकट मिलते थे। हमने समस्या को पुन: उत्पन्न करने में 2-3 घंटे बिताए, लेकिन जब भी हमें अन्य विभागों से सहायता की आवश्यकता होती है, जैसे मामले का विवरण, सेवा पुनरारंभ, डेटाबेस से डेटा या देव टीम से विश्लेषण, हमारे कार्य अटक जाते हैं।

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

परिणामस्वरूप, उच्च-प्राथमिकता वाले टिकट भी कुछ महीनों तक अनसुलझे रह सकते हैं, जबकि निम्न-प्राथमिकता वाले कार्य वर्षों तक बोर्ड पर बने रहे।

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

• जब उनकी समस्याओं का शीघ्र पर्याप्त समाधान नहीं हुआ तो ग्राहक तनावग्रस्त और निराश हो गए, और हम एक स्पष्ट समयरेखा प्रदान करने में असमर्थ थे।
  
  
• हमारी सहायता टीम निराश थी, क्योंकि ग्राहक लगभग हर दिन अनसुलझे मुद्दों के अपडेट की मांग करते थे।
  
  
• समर्थन टीम ने हमें लिखा और वही प्रतिक्रिया मिली: "समस्या अभी तक हल नहीं हुई है।"
  
  
• हमारी टीम ओवरलोडेड थी और पुराने कार्यों को लेने और उन्हें आवर्ती मामलों के रूप में लिंक करने में असमर्थ थी।
  
  
• जब हमने अपने बोर्ड पर 1,500 अनसुलझे कार्यों की कठिन संख्या को देखा तो हमें निराशा हुई। हम जानते थे कि कोई भी प्रगति करने के लिए हमें अपना दृष्टिकोण बदलने की आवश्यकता है।

उस दौर में टिकट की लाइफ साइकिल कुछ इस तरह दिखती थी।

आइए समस्याओं के बैकलॉग को प्रबंधित करते समय हमारे सामने आने वाली कुछ समस्याओं पर एक नज़र डालें:

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

इस खराब संगठित दृष्टिकोण के परिणामस्वरूप चार वर्षों में 1,500 अनसुलझे टिकटों का बैकलॉग हो गया।

स्टेटिक दृष्टिकोण और हरक्यूलिस का छठा श्रम

हमने महसूस किया कि हमारा विभाग क्लाइंट के मुद्दों को हल करने के मुख्य उद्देश्य को संबोधित करने के बजाय टिकट प्रसंस्करण पर केंद्रित था: सोशल डिस्कवरी ग्रुप उत्पादों के प्रति अपनी वफादारी में सुधार करना और हमारी सेवाओं और वेबसाइटों में कमजोरियों का पता लगाना।

आप सोच सकते हैं, "यदि आप काम का बोझ नहीं संभाल सकते तो अधिक कर्मचारियों को क्यों नहीं रखा जाए?" हालाँकि, अनुभव ने दिखाया है कि कुशल प्रक्रियाओं को स्थापित करके, हम अतिरिक्त संसाधनों के बिना जा सकते हैं।

इसी तरह, हरक्यूलिस ने नदी के प्रवाह को ऑगियन अस्तबल की ओर पुनर्निर्देशित करके अकेले अपना श्रम पूरा किया, जिसने उन्हें केवल एक दिन में साफ कर दिया।

हमारे टिकट बोर्ड को सुव्यवस्थित करने के लिए, हमने माइक बरोज़ की पुस्तक "कानबन फ्रॉम द इनसाइड" का उल्लेख किया और कानबन पद्धति को क्रियान्वित करने के लिए एक व्यवस्थित रणनीति, STATIK दृष्टिकोण को लागू किया।

स्टेटिक दृष्टिकोण को लागू करते समय, हमने इन पांच चरणों का पालन किया:

1. हमने अपने व्यवसाय सहायता विभाग से ग्राहकों की अपेक्षाओं की पहचान की और निष्कर्ष निकाला कि ग्राहकों को प्रदान की गई सहायता से संतुष्ट होने की आवश्यकता है। इसे पूरा करने के लिए, हमें निम्नलिखित सुनिश्चित करने की आवश्यकता है:

• कार्य पर हमारे काम में पारदर्शिता ग्राहकों को यह समझने में सक्षम बनाती है कि किसी भी समय उनके अनुरोधों के साथ क्या हो रहा है।
  
  
• कार्यों पर हमारे काम की मुस्तैदी, मुद्दे की किसी भी स्थिति में प्रतिक्रिया के लिए एक निश्चित समय प्रदान करना।

2. हमने असंतोष के आंतरिक और बाहरी दोनों स्रोतों को परिभाषित किया। आंतरिक स्रोत वह है जो हमें बाधित करता है और हमारे अपने काम में निराशा पैदा करता है।

बाहरी स्रोत वह है जो हमारे ग्राहकों के लिए निराशा का कारण बना और उनके अनुभव में बाधा उत्पन्न करता है।

3. हमने अपने कार्यभार के स्रोतों और प्रकृति का विश्लेषण किया। हमने अपने विभाग को जमा किए गए टिकटों की जांच की और उन्हें उन विभागों द्वारा वर्गीकृत किया, जिनसे वे आए थे, उनकी आवृत्ति, और प्रतिक्रिया समय और समाधान के संबंध में ग्राहकों की अपेक्षाएँ।

4. हमने अपनी मौजूदा क्षमताओं का मूल्यांकन किया। इस स्तर पर, हमने मूल्यांकन किया कि हम टिकटों को कितनी कुशलता से संभाल रहे थे और यह निर्धारित किया कि हम एक सप्ताह में कितने कार्यों को वास्तविक रूप से प्रबंधित कर सकते हैं।

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

5. हमने टिकट के जीवन चक्र को फिर से बनाया और एक नई प्रक्रिया बनाई।

हमारा प्रारंभिक टिकट जीवन चक्र

प्राप्त अंतर्दृष्टि का उपयोग करते हुए, हमने एक नया कार्य जीवन चक्र विकसित किया है।

अगला, हमने पहले उल्लिखित सभी समस्याओं को हल करने के लिए एक व्यापक दृष्टिकोण लागू किया। हमने निम्नलिखित कदम उठाए:

• प्रारंभिक स्तर पर कार्यों को फ़िल्टर करने के लिए हमने अपनी सहायता टीम के लिए स्क्रिप्ट बनाई।
  
  
• हमने उन कार्यों के लिए एक अस्थायी "बैक टू रिपोर्टर" स्थिति प्रस्तुत की, जिसमें समस्या की जांच के लिए ग्राहक इनपुट की आवश्यकता थी। यदि तीन दिनों के भीतर आवश्यक जानकारी प्रदान नहीं की गई, तो कार्य स्वतः बंद हो जाएगा।
  
  
• हमने "बढ़ाए गए" स्थिति को हटा दिया और इसे एक अधिक विशिष्ट "समस्या की पुष्टि" स्थिति से बदल दिया।
  
  
• हमने डुप्लिकेट कार्यों की समीक्षा करने और उन्हें बंद करने में दो महीने से अधिक समय बिताया, जिसके साथ हमने 1,500 में से केवल 800 अद्वितीय टिकटों के साथ शुरुआत की थी।
  
  
• हमने सर्विस लेवल एग्रीमेंट्स (SLAs) लागू किए और प्रत्येक स्थिति के लिए टाइमर सेट किए। "समस्या की पुष्टि" स्थिति में 7 दिनों का टाइमर था, जबकि "विकास" स्थिति में 30 दिनों का टाइमर था।
  
  
• "समस्या की पुष्टि" स्थिति में कार्य होने से हमें प्रतिक्रिया के लिए अपने सहयोगियों को पिंग करने के लिए प्रेरित किया। हमने जीरा में टिप्पणी करने के बजाय निजी संदेशों या स्लैक थ्रेड्स का उपयोग करते हुए अपने संचार दृष्टिकोण को बदल दिया। इसने प्रतिक्रिया समय को घटाकर एक दिन कर दिया, जबकि इससे पहले सप्ताह लग गए थे।
  
  
• हालांकि हमने "सुधार की प्रतीक्षा" स्थिति पर टाइमर नहीं लगाया, हमने ग्राहक संचार और चर्चा के लिए अधिक समय आवंटित किया। यदि किसी कार्य को अव्यावहारिक समझा जाता था, तो हमने ग्राहक को सूचित किया और अधिक महत्वपूर्ण कार्यों को प्राथमिकता दी। इससे ऑन-होल्ड कार्यों में 50% की कमी आई। इसके अतिरिक्त, हमने बैठकें आयोजित करना शुरू किया जहां ग्राहक कार्य के महत्व को समझा सकते थे, जिससे हमें अपने कार्यभार को बेहतर ढंग से प्राथमिकता देने में मदद मिली।
  
  
• "विकास" स्थिति के लिए, हम 30 दिनों का टाइमर सेट करते हैं और इस स्थिति में कार्यों की संख्या को चार तक सीमित कर देते हैं। इससे हमें निर्धारित समय सीमा के भीतर बग को ठीक करने पर ध्यान केंद्रित करने और बोर्ड पर "विकास" स्थिति में 20-40 कार्यों के अनावश्यक दृश्य शोर से अभिभूत होने से बचने में मदद मिली।
  
  
• यह सुनिश्चित करने के लिए कि हमारी प्रथाएं टिकाऊ हैं, हम 90वें प्रतिशतक सिद्धांत को लेकर आए, जिसका अर्थ था कि 90% कार्यों को समय पर पूरा किया जाना था, जैसा कि प्रत्येक स्थिति के लिए टाइमर द्वारा निर्धारित किया गया था। हमने 90वें पर्सेंटाइल के निर्माण के लिए जीरा के कंट्रोल चार्ट और जीरा-हेल्पर प्लगइन का उपयोग करके इसकी निगरानी की।
  
  
• अंत में, हमने टीम के लिए अतिरिक्त प्रेरणा का परिचय दिया, अगर 90 वें प्रतिशतक सिद्धांत का पालन किया गया तो बोनस का वादा किया गया, जैसे ऑगेस ने हरक्यूलिस को बोनस के रूप में अपने घोड़ों का दसवां हिस्सा देने का वादा किया था।

इस नए दृष्टिकोण को लागू करने और हमारे विभाग की प्रक्रियाओं के पुनर्निर्माण के द्वारा, हम आखिरकार उस समस्या से निपटने में सक्षम हो गए, जिसने हमें चार वर्षों तक परेशान किया था।

समाधान के लिए किसी अतिरिक्त समय, प्रयास, या बजट की आवश्यकता नहीं थी, फिर भी हमने जमा होने वाले कार्यों की संख्या को काफी कम कर दिया। केवल पांच महीनों में, केवल दो बुद्धिमान कर्मचारियों की एक टीम के साथ, हम कतार को 1,500 टिकटों से घटाकर मात्र 150 करने में कामयाब रहे।

इस अनुभव ने हमें समस्या के मूल कारण की पहचान करने के महत्व को प्रभावी ढंग से संबोधित करने के लिए सिखाया है।

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

डिमिट्री एंड्रयूज द्वारा लिखित, सोशल डिस्कवरी ग्रुप में सॉफ्टवेयर टेस्टिंग इंजीनियर