खुश ग्राहकों के लिए एक sysadmin के लिए क्या लेता है? [बन्द है]


14

उपयोगकर्ता निर्देशिकाओं का प्रतिदिन बैकअप लेना, 24X7 पासवर्ड रीसेट करना, ssh सिंगल साइन ऑन, स्पेस की उदार मात्रा, एक अच्छा परीक्षण वातावरण, नियंत्रित उन्नयन के लिए HA क्लस्टर, मैन पेजों तक अप करने के लिए सक्षम होना, और अभी भी मुझे शिकायतें मिलती हैं। तो अपने ग्राहकों को खुश, सक्षम और कुशल बनाने में क्या लगता है?

अंतिम 10 शिकायतें :

  • मॉड्यूल पीडीएफ क्यों नहीं है :: API2 सभी सर्वरों पर समान रूप से स्थापित और समान है?
  • मुझे अपने HP सर्वर पर LD_PRELOAD = का उपयोग क्यों करना है?
  • AIX चलाने वाली साइटों पर मेरा STL प्रोग्राम इतना धीमा क्यों चलता है?
  • मैं अगले तीन महीनों के लिए किसी भी प्रकार का आउटेज नहीं ले सकता।
  • मेरे स्थानीय मशीन पर कंपाइलर क्यों नहीं हो सकता है?
  • यह काम कल क्यों किया?
  • अपाचे से ताला लगा रहता है।
  • मैं उत्पादन में इसे डिबग क्यों नहीं कर सकता?
  • मैं सिर्फ इस खुले स्रोत की बात क्यों नहीं कर सकता, जिसकी मुझे आवश्यकता है?
  • गनज़िप कैसे भ्रष्ट हो गई?

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


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

जवाबों:


16

ऐसा लगता है कि आप मुख्य रूप से प्रोग्रामर को जवाब देते हैं, इसलिए मेरे उत्तर सीधे लागू नहीं हो सकते हैं क्योंकि वे एक नियमित Microsoft कार्यालय का उपयोग कर लेखाकार, विपणन या मानव संसाधन प्रतिनिधि का उपयोग करेंगे।

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

समझाएँ क्यों - यदि आप "नहीं" कहने जा रहे हैं, तो क्यों समझाएँ। यदि आप मदद करने में बहुत व्यस्त हैं, तो क्यों समझाएं। यदि उपयोगकर्ता का अनुरोध असंभव है या संभव नहीं है, तो बताएं कि क्यों। तानाशाह को कोई पसंद नहीं करता।

लोगों से बोलें - आईटी के लोग ई-मेल के जरिए बातचीत करना पसंद करते हैं। व्यक्ति से बात करना (अधिमानतः आमने-सामने) चीजों को बहुत अधिक कुशलता से किया जाता है और लोगों को लगता है कि आप उनकी समस्या की परवाह करते हैं।

सुनो और समझाओ - लोगों को मत काटो या मान लो कि तुम्हें पता है कि समस्या क्या है। सुनो कि उन्हें क्या कहना है, और समझाएं कि समस्या क्यों हुई और भविष्य में इसके बारे में क्या करना है।

तुरंत जवाब दें - जब आप हफ्तों (या अधिक) के उनके अनुरोधों का जवाब नहीं देते हैं तो लोग उचित रूप से परेशान हो जाते हैं। मैं SLAs का प्रशंसक नहीं हूं, लेकिन यहां तक ​​कि अगर प्रतिक्रिया है "मेरे पास अभी समय नहीं है," यह बिल्कुल भी प्रतिक्रिया से बेहतर है।

लचीला बनो - किसी के लिए कोई चीज मांगने पर हर बार अपने मुंह से कोई बात मत निकालो। आपका काम तकनीक को नियंत्रित करना नहीं है। यह बेहतर है कि लोग अपने काम कर सकें । अपने उपयोगकर्ताओं के साथ काम करें, उनके खिलाफ नहीं।

अनुवर्ती कार्रवाई - दरारों के माध्यम से अनुरोधों को फिसलने न दें। जब लोग अपना काम नहीं कर पाते हैं तो वे परेशान हो जाते हैं और महसूस करते हैं कि उनकी अनदेखी की जा रही है। हर अनुरोध को पूरा या हर बार जवाब दें , भले ही जवाब "यह संभव नहीं है।"

मिलनसार बनें - पीपुल्स क्यूबिकल्स उनके बारे में बहुत कुछ कहते हैं। यदि उनके पास साइकिल चलाने की तस्वीरें हैं, तो उनसे साइकिल चलाने के बारे में पूछें। यदि वे कलेक्टरों पर मुहर लगाते हैं, तो टिकटों के बारे में पूछें। अंत उपयोगकर्ता समर्थन 80% ग्राहक सेवा और 20% तकनीकी है (हालांकि यह अनुपात अंत उपयोगकर्ताओं के रूप में प्रोग्रामर के लिए अलग है)।

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

रखरखाव का संचार करें - यदि आप किसी ऐसी चीज़ में बदलाव कर रहे हैं जिसमें समस्या पैदा करने का मौका है, तो लोगों को बताएं । हर विभाग में हर समय सीमा को जानना असंभव है। यदि आपका रखरखाव किसी को अपनी समय सीमा याद आती है, तो वे परेशान होने वाले हैं। जब आप ऐसे बदलाव करते हैं जिनके बारे में कोई नहीं जानता है और वे चीजों को तोड़ देते हैं, तो आप लोगों को यह आभास दे रहे हैं कि आपको कोई परवाह नहीं है।

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

फॉलोअप को प्रोत्साहित करें - यदि समस्या पहली बार ठीक नहीं हुई थी तो उपयोगकर्ता को वापस बुलाने के लिए प्रोत्साहित करें।


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

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

2
गंभीरता से यह प्रतिभाशाली स्तर का काम है यहाँ ... मैं इसे बार-बार पढ़ता रहता हूँ।
ओब्लास्स

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

10

मुझे लगता है कि यदि आप चाहते हैं कि आपके ग्राहक आपसे खुश रहें, तो # 1 चीज संचार है।

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

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

दोस्ताना sysadmins ग्राहकों को खुश करने के लिए नेतृत्व करते हैं, IMHO।


जब लोगों को बहुत शिकायत होती है, तो यह बहुत मुश्किल नहीं है। मित्रता पर अच्छा संकेत।
ojblass

मैं पूरी तरह से सहमत हूं कि यह कठिन हो सकता है! मुझे लगता है कि वे शिकायत करने की संभावना कम कर रहे हैं, जब वे समझते हैं - इसलिए उन्हें अपनी समझ की सहायता के लिए सामान की व्याख्या करने के बारे में लंबा बिंदु। यदि संभव हो, तो आप कभी-कभी कठिन परिस्थितियों के लिए अपनी प्रतिक्रिया दे सकते हैं जब आप कम से कम निराशा से प्रभावित होते हैं; जैसे। जब आप अपनी सुबह की कॉफी खा रहे हों :)
mibus

3
मैंने पाया कि प्रश्न में सूची को पढ़ना कि अधिकांश "शिकायतें" प्रश्न हैं। मैंने पाया है कि ज्यादातर लोग जवाब चाहते हैं, भले ही वे उन्हें पसंद न करें।
जोसेफ

8

(आगे के विचार के बाद फिर से लिखा गया।)

यह सब संचार के लिए नीचे आता है

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

संचार के कुछ अन्य पहलुओं पर काम करना सुनिश्चित करें:

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

आपकी हाल की शिकायतों की सूची पढ़ने के बाद: आपके उपयोगकर्ता ज्यादातर डेवलपर्स की तरह आवाज करते हैं। मुझे इसके साथ बहुत अनुभव नहीं है (मेरा ज्यादातर वैज्ञानिक, व्यवस्थापक कर्मचारी, प्रबंधक हैं), लेकिन मुझे अभी भी लगता है कि बहुत सारे संचार क्रम में हैं। के बाद से वे डेवलपर्स, इसे और अधिक तकनीकी हो सकता है: जैसे यह स्थापित नहीं है, क्योंकि यह पर निर्भर है यह अन्य पैकेज।

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


2

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


आपको क्या खुशी होगी?
ओब्ब्लास

मैं अपनी नौकरी में खुश हूं, हालांकि मैं अपने ग्राहकों के लिए वाउच नहीं कर सकता!
PowerApp101

1
मैंने इसे "ज्यादातर बार आईटी के लिए अदृश्य है और केवल चीखते हुए कहा कि जब चीजें गलत होती हैं, तो यह सुनिश्चित करता है" के लिए मतदान किया - सुनिश्चित नहीं कि अगर इसका अर्थ था, लेकिन यह इस तरह से चीजें होना चाहिए।
मैक्सिमस मिनिमस

2

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

उन चीजों की मेरी छोटी सूची जो अच्छे बदलाव का प्रबंधन करती हैं:

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

जैसा कि दूसरों ने कहा है कि उपयोगकर्ता कभी भी पूरी तरह से खुश नहीं होंगे। हालाँकि वे सबसे ज्यादा खुश होते हैं जब चीजें समय के साथ समान रहती हैं।


दुर्भाग्य से मैं केवल परिवर्तन प्रबंधन प्रक्रियाओं पर सलाह देता हूं; हालाँकि, मैं पूरी तरह से सहमत हूँ।
ojblass

1

आपको क्या शिकायतें मिलती हैं? हमारे ग्राहक तब खुश होते हैं जब उनके मुद्दों को संबोधित किया जाता है। हम उनके लिए दुनिया का सबसे अच्छा वातावरण प्रदान कर सकते हैं, लेकिन अगर हम नहीं जानते कि उनके ई-मेल क्यों खो जाते हैं, या उनके मुद्दों का तुरंत जवाब नहीं देते हैं, तो वे परेशान होंगे।


आम शिकायतें जोड़ दीं।
ओब्ब्लास

1

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

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

उन्हें बताएं कि आप कौन हैं। आप सामने वाले का सामना नहीं कर रहे हैं, वे आपसे सीधे संपर्क नहीं कर रहे हैं, लेकिन जहां संभव हो, उनके साथ हाथ मिलाएं और अपनी नौकरी पर एक मानवीय चेहरा रखें। एक दिन में 8 घंटे के लिए अपने कालकोठरी में गायब होने से यह कटौती नहीं करता है।

समझें कि आप विश्वास की स्थिति में हैं। आपके ग्राहकों को यह जानना होगा कि वे आप पर भरोसा कर सकते हैं, और आपको उन्हें प्रदर्शित करने की आवश्यकता है।

ग्राहकों की आवश्यकताओं को समझने के लिए काम करें। एक सुझाव बॉक्स खोलें, हेल्पडेस्क कर्मचारियों से प्रतिक्रिया प्राप्त करें, जो भी इसे लेता है। यदि आप नहीं जानते कि आपके ग्राहकों के लिए क्या दुःख का कारण है, तो आप इसे कभी भी हल नहीं कर पाएंगे।

उनके साथ ईमानदार रहें। उन्हें बैल मत दो। अगर कुछ नहीं किया जा सकता है तो उन्हें इसका कारण बताएं। और इसे गैर-तकनीकी शब्दों में करना सीखें। आप एक बेईमान "हाँ" की तुलना में एक ईमानदार "नहीं" के लिए अधिक सम्मान अर्जित करेंगे।

वे हमेशा सही नहीं होते हैं - मेरे अगले पैरा देखें - लेकिन ऐसे मामलों में जहां वे हैं, इसे स्वीकार करना सुनिश्चित करें। अगर कुछ उन्हें दुःख पहुंचाता है, और इसका कोई अच्छा कारण नहीं है, तो इसे स्वीकार करें, और उन्हें बताएं कि वे सही हैं।

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

वह आखिरी आपकी सफलता का एक पैमाना है - क्या आपके ग्राहक सुबह उठकर अपना सामान ले सकते हैं? और क्या वे इसे बिना परेशानी के कर सकते हैं? यदि आप उनमें से 90% के लिए प्रबंधन कर सकते हैं, तो आप बहुत अच्छा कर रहे हैं, मुझे लगता है।


1

मानकीकृत
करें अपने सर्वर सॉफ़्टवेयर को संगत रखें

सामान्य प्रश्न
'अक्सर पूछे जाने वाले प्रश्न' पृष्ठ शुरू करें। इसे अपडेट रखें और सुनिश्चित करें कि यह आसानी से सुलभ (और दृश्यमान) है

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


मानकीकरण पर टिप्पणी करें। यह निश्चित रूप से सबसे अच्छा विचार है; हालाँकि, मैं आपको चुनौती देता हूं कि एक महीने से भी कम समय में एक हजार से अधिक मशीनों को रोल आउट कर दें।
ojblass

मानक एक दोधारी तलवार हैं। कभी-कभी वे अनम्य इन्फ्रास्ट्रक्चर और वेंडर लॉक इन का नेतृत्व करते हैं। एफएक्यू को एक अच्छी तरह से रिकॉर्ड की गई आवाज के रूप में देखा जाता है। लोगों को उन्हें पढ़ना मुश्किल है।
ojblass

1

ग्राहक को देते हैं कि जब वे चाहते हैं तो वे क्या चाहते हैं।

एक बड़ी समस्या यह पता लगाना है कि ग्राहक क्या चाहता है। कभी-कभी वे नहीं जानते, या यह कहते हैं कि वे एक्स चाहते हैं लेकिन वास्तव में वाई चाहते हैं। आपको यह पता लगाने के लिए उनके साथ बहुत संवाद करने की आवश्यकता है।

लेकिन याद रखें कि आप उन सभी को खुश नहीं कर सकते ...

90 के दशक के अंत से एक सच्ची कहानी:

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

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.