सेवा डेस्क सिस्टम और उनका एकीकरण। ठेकेदारों और निर्माताओं के साथ काम करने की प्रक्रिया को स्वचालित कैसे करें?

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

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

विक्रेताओं और ठेकेदारों के साथ बातचीत की योजनाएँ

वर्तमान में, बिक्री के बाद सेवा और सेवा समर्थन के क्षेत्र में विक्रेता, भागीदारों और ग्राहकों की बातचीत को दो योजनाओं में विभाजित किया जा सकता है, केवल उस मॉडल को छोड़कर, जिसमें ग्राहक और ठेकेदार के बीच कोई अतिरिक्त संबंध नहीं हैं।

योजना 1. भागीदारों के साथ विक्रेता का समर्थन


योजना का उपयोग ग्राहकों के भौगोलिक रूप से वितरित नेटवर्क के मामले में किया जाता है। इस मामले में, क्लाइंट सीधे डेवलपर / निर्माता की तकनीकी सहायता या सेवा डेस्क से संपर्क करता है। विक्रेता अपने स्तर पर प्रश्नों का हिस्सा "बंद" करता है, लेकिन ऐसी स्थिति में जहां "भौतिक" उपस्थिति की आवश्यकता होती है, क्लाइंट एप्लिकेशन को हल करने के लिए भागीदारों को आकर्षित करता है।

विक्रेता न केवल उन मामलों में भागीदारों के साथ योजना का उपयोग करते हैं जहां "भौतिक" उपस्थिति आवश्यक है। बाजार पर ऐसी कंपनियां हैं जिनके कार्य मॉडल विशेष रूप से विक्रेता सहायता प्रदान करते हैं, जबकि कंपनी के पास अपने पूर्णकालिक विशेषज्ञ नहीं हैं। उन साझेदारों को खोजना सस्ता / आसान है जो अंतिम ग्राहक के निर्णय निर्माताओं के साथ सीधे संपर्क के बिना यह समर्थन प्रदान करेंगे। इसके अलावा, आमतौर पर किए गए काम की गुणवत्ता को नियंत्रित करने के लिए, आवेदन विक्रेता कंपनी को वापस कर दिया जाता है, या तो पहले से ही तय किया जाता है, या उच्च स्तर पर अंतिम रूप दिया जाता है।

योजना 2. एक विक्रेता के साथ भागीदारों का नेटवर्क


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

जटिल योजना। कुछ मुद्दों को हल करने के लिए ठेकेदारों को आकर्षित करना


तकनीकी और सेवा समर्थन के दोनों उपरोक्त मॉडल (एक बड़ी हद तक - उनमें से दूसरा) उपमहाद्वीपों, उप-भागीदारों के कई स्तरों द्वारा व्यवहार में "जटिल" हैं (हम उप-साझेदारियों के 3 या 4 स्तरों के साथ कहानियों के बारे में जानते हैं), आदि, ऐसा होता है, उदाहरण के लिए। , एक संघीय ग्राहक कंपनी के मामले में कई क्षेत्रों या उन स्थितियों में उपस्थिति की आवश्यकता होती है जहां संबद्ध नेटवर्क मूल रूप से क्षेत्र में विशिष्टता के मॉडल के अनुसार बनाया गया था।

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

मौजूदा मॉडल का नुकसान

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

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

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

अभ्यास से पता चलता है कि तकनीकी सहायता के मॉडल की परवाह किए बिना, अंतिम ग्राहक के लिए निर्माता लगभग हमेशा "दोष" देता है।

ऑटोमेशन से गुणा करना या सर्विस डेस्क सिस्टम कहां है

वास्तविकता में, दोनों मॉडलों में जो समस्याएं उत्पन्न होती हैं, वे बहुत अधिक जटिल हो जाती हैं, जब अजीब तरह से पर्याप्त, तकनीकी समर्थन को स्वचालित करने का मुद्दा और ये बहुत ही संचार जुड़े होते हैं। तथ्य यह है कि दोनों सेवा कंपनियों और विक्रेताओं के विशाल बहुमत "ईमेल" या "तत्काल दूत" के अलावा किसी भी स्वचालन प्रणाली (हेल्प डेस्क या सर्विस डेस्क) का उपयोग नहीं करते हैं (हमारे आँकड़ों के अनुसार, 10,000+ सेवा कंपनियों के साथ संचार पर आधारित है, जैसे ~ 90 %)। और जो पंजीकरण, लेखांकन और प्रसंस्करण अनुप्रयोगों के लिए कुछ स्वचालन समाधानों का उपयोग करते हैं, वे एक दूसरे के साथ एकीकृत नहीं होते हैं।

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

ऐतिहासिक रूप से स्थापित कार्य योजनाओं का परिणाम और दोनों सहयोग योजनाओं में वर्णित समस्याओं का एकल समाधान, कंपनियों को अनिवार्य रूप से कई लागतों का सामना करना पड़ता है, उदाहरण के लिए:

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

स्थिति से बाहर का रास्ता

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

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


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

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

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

और बड़ी कंपनियों के सर्विस डेस्क सिस्टम के साथ एकीकरण के बारे में क्या?

ओकेडेस्क सिस्टम के बीच तैयार एकीकरण, ज़ाहिर है, अच्छा है। लेकिन क्या होगा यदि ग्राहक एक बड़ी कंपनी है (सशर्त Sberbank, X5 रिटेल ग्रुप, आदि)? इस स्थिति में, आपको ग्राहक के सिस्टम पर बहुत सीमित मोड में काम करने या ईमेल द्वारा टिकट भेजने के लिए मजबूर किया जाता है।

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

सिद्धांत से लेकर वास्तविक जीवन के परिदृश्य और अभ्यास तक

फिलहाल, एक समान मॉडल का उपयोग कई उद्योगों ("विक्रेता" - "भागीदार" संस्करण में और "ग्राहक" - "ठेकेदार" संस्करण) में किया जाता है: HORECA, कैश रजिस्टर उपकरण का रखरखाव, आईटी आउटसोर्सिंग। उपयोगकर्ता प्रतिक्रियाओं के विश्लेषण से पता चलता है कि औसतन, एकीकृत समाधानों से अनुप्रयोगों को हल करने में लगने वाले समय को 40% तक कम किया जा सकता है, और ग्राहकों की नकारात्मक समीक्षाओं की संख्या लगभग 20% बढ़ जाती है।

और यहाँ है कि यह कैसे काम करता है:


और विभिन्न सर्विस डेस्क सिस्टम का उपयोग करते समय आप ठेकेदारों, ग्राहकों और भागीदारों के साथ कैसे बातचीत करते हैं?