बचाव दल, आगे बढ़ो!

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



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



तो, DevExpress पर चिप और डेल कैसे काम करता है:

किसी को भुलाया नहीं जाता। कुछ भी नहीं भूला है

(कोई सवाल नहीं खोना चाहिए)

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



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



प्रत्येक समस्या में कई बाहरी और आंतरिक स्थितियां हो सकती हैं, जो प्रश्न के प्रकार पर निर्भर करता है (उदाहरण के लिए, बग को पुन: प्रस्तुत, फिक्स्ड या डिज़ाइन द्वारा) किया जा सकता है। लेकिन साथ ही, हम इस नियम का पालन करने की कोशिश करते हैं कि उपयोगकर्ता का कोई भी संदेश समस्या की स्थिति को सक्रिय करने के लिए बदल देता है। यहां तक ​​कि अगर एक व्यक्ति ने बस "धन्यवाद!" लिखा है, तो यह जवाब देने के लिए कभी नहीं होगा कि "कृपया!"

हम दिनों तक नहीं सोते

(24 घंटे के भीतर सवाल का जवाब)

हम समझते हैं कि प्रत्येक उपयोगकर्ता अपनी समस्या को जल्द से जल्द हल करना चाहता है। इसलिए, हमसे अपना प्रश्न पूछते हुए, वह यह सुनिश्चित करने के लिए जानता है कि उसे छुट्टियों (वीकेंड्स) को छोड़कर, 24 घंटे के भीतर (नवीनतम में) उत्तर मिल जाएगा।



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



लेकिन हमारे मामले में 24 घंटे की प्रतिक्रिया एक आवश्यक न्यूनतम है, जो इस तथ्य के कारण है कि हमारे उपयोगकर्ताओं को दुनिया भर में वितरित किया जाता है। इसके अलावा, विभिन्न समय क्षेत्रों के लिए सर्वश्रेष्ठ कवरेज प्रदान करने के लिए हमारी सहायता टीम कई पारियों में काम करती है।

तेज़! अधिक बार! फुलर!

(प्रश्न की अभिक्रियाओं की संख्या न्यूनतम होनी चाहिए)

यदि किसी व्यक्ति ने ग्राहक सहायता से संपर्क किया है, तो उसे वास्तव में सहायता की आवश्यकता है। इसलिए, हम मदद करने की कोशिश करते हैं, न कि "आने वाले अनुरोधों को संसाधित करें।" ऐसा करने के लिए, हम अपने उत्तरों को यथासंभव पूरा करते हैं। उदाहरण के लिए:



(बुरा जवाब):

"यह कैसे करना है इस दस्तावेज़ में लिखा है।"

(अच्छा जवाब):

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

चलते चलते

(हम उन सभी रेक को इकट्ठा करते हैं जो किसी ने पहले ही कदम रखा है)

हमने उपयोगकर्ताओं से अपने प्रश्न का उत्तर खोजने के लिए इसे संभव बनाने का निर्णय लिया, यहां तक ​​कि समर्थन से संपर्क किए बिना। यहां हम इस तथ्य से आगे बढ़े हैं कि यदि किसी ने कभी हमसे किसी समस्या के बारे में संपर्क किया है, तो यह जानकारी बर्बाद नहीं होनी चाहिए। ऐसा करने के लिए, हम यह करते हैं:

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

फोन को ना कहना

(हम टेलीफोन सहायता प्रदान नहीं करते हैं)

हमें अक्सर यह सवाल पूछा जाता है कि हमारे पास टेलीफोन सहायता सेवा क्यों नहीं है, क्योंकि कभी-कभी यह बहुत उपयोगी है - लाइव संचार के माध्यम से कई समस्याओं को हल किया जा सकता है।



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

मुझे बताओ क्यों

(सबसे महत्वपूर्ण बात यह समझना है कि उपयोगकर्ता यह क्यों चाहता है)

उपयोगकर्ता के प्रश्न पर विचार करते समय, सबसे पहले हम हमेशा उपयोगकर्ता की वास्तविक समस्या की पहचान करने के लिए विशेष ध्यान देने की कोशिश करते हैं, न कि वह जिस तरह से इस समस्या को हल करने की कोशिश कर रहा है वह काम नहीं करता है।



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

... वहाँ हमेशा दो तरीके हैं!

(यदि संभव हो तो हम हमेशा उपयोगकर्ता को एक समाधान प्रदान करने का प्रयास करते हैं)

भले ही समस्या उत्पाद की विशेषताओं से संबंधित हो (डिजाइन द्वारा), हम हमेशा ग्राहक को वैकल्पिक समाधान की पेशकश करने की कोशिश करते हैं। और यदि यह विधि मौजूद नहीं है, तो हम उपयोगकर्ता को बता देते हैं कि हम इस दिशा में क्या करने जा रहे हैं:

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

हम हमेशा आपके बारे में सोचते हैं।

(उपयोगकर्ता की समस्या पर काम चलता है, भले ही "गेंद उसकी तरफ हो")

एक और महत्वपूर्ण चाल है कि हमारी सहायता सेवा अपने काम में उपयोग करती है: अनुवर्ती ।

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



इसके अलावा, यह जानकारी न केवल इस विशेष उपयोगकर्ता के लिए उपयोगी हो सकती है, बल्कि बाकी सभी के लिए भी उपयोगी होगी, जो बाद में हमारे साथ पत्राचार पढ़ता है (यदि समस्या सार्वजनिक रूप से दर्ज की गई है), जिसका अर्थ है कि किसी भी ऐड-ऑन का मूल्य कई गुना बढ़ जाता है।

कोला और गर्म कुत्ते को ठीक कर सकते हैं

(उपयोगकर्ता द्वारा हल किए जाने पर ही समस्या का समाधान होता है)

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



उदाहरण के लिए, एक उपयोगकर्ता को उत्पाद में एक बग मिला, जिसके कारण काम करना जारी रखना असंभव है। अगर हम बस पुष्टि करते हैं कि यह एक बग है, और उपयोगकर्ता को सूचित करें: “हुर्रे! बग तय! अगले अद्यतन की प्रतीक्षा करें ... जो छह महीने में होगा, "वह इस समय दुखी रहेगा, और उसका असंतोष हर दिन बढ़ता जाएगा। इस तरह की समस्याओं से बचने के लिए, हमने अपने उत्पादों को अपडेट करने के लिए DevExpress पर काम का निर्माण किया है ताकि किसी भी समय किसी भी उपयोगकर्ता को उसकी समस्या के लिए एक नया निर्धारण मिल सके।

प्रोग्रामर - कैलिपर मित्र

(डेवलपर और कैलिपर्स एक टीम हैं। और उपयोगकर्ता के सबसे अच्छे दोस्त हैं)

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



इस स्थिति को ठीक करने के लिए, हम अपने काम में निम्नलिखित तकनीकों का उपयोग करते हैं:

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