Castro Podcasts: ग्राहक सहायता से रिश्ते बनाने की कोशिश क्यों चूक गई

 (uncommonapps.nyc)
1 पॉइंट द्वारा GN⁺ 9 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Castro के अधिग्रहण के बाद, टीम ने रोज़ाना product इस्तेमाल करने और हर email का जवाब देने वाली people-centered support को अलग पहचान बनाने की कोशिश की, लेकिन यह उम्मीद के मुताबिक customer loyalty या goodwill में नहीं बदला
  • जहां तुरंत सटीक समाधान दिया जा सकता था, वहां satisfaction ऊंचा था, लेकिन ज़्यादातर thoughtful replies user expectations से मेल नहीं खाए और कभी-कभी नाराज़गी बढ़ा दी
  • subscription pricing, मुश्किल से reproduce होने वाले bugs, और feature requests जैसी queries product improvement के signals हो सकती हैं, लेकिन सिर्फ जवाब देने भर से customers के लिए पर्याप्त समाधान बनना मुश्किल था
  • App Store account·subscription जैसे complex issues, जहां human intervention से समस्या सुलझ सकती थी, पर अच्छा response मिला, लेकिन ऐसी emails कुल support emails की 1% से भी कम थीं
  • Castro team के लिए लंबी explanations देने के बजाय emails पढ़कर product improvement पर focus करने वाला संचालन बेहतर रहा, और positive experience support conversations से ज़्यादा वास्तविक product improvements से बना

Castro ने जिस support तरीके की उम्मीद की थी

  • Castro को acquire करते समय, वास्तविक user experience पर आधारित people-centered support को आसान differentiation factor माना गया
  • रोज़मर्रा में इस्तेमाल की जाने वाली services के customer support से शायद ही उपयोगी जवाब मिलते थे, इसलिए उम्मीद थी कि product को रोज़ खुद इस्तेमाल करके और हर email पढ़कर ईमानदारी से जवाब देने पर customers इसे बहुत सराहेंगे
  • जब emails संभालना मुश्किल होने लगा, तो product को अच्छी तरह जानने और अक्सर emails भेजने वाले एक user को भुगतान करके support replies का काम दिया गया
    • इस user ने खासकर users की समस्याएं सीधे हल करने में अच्छा प्रदर्शन किया
  • परिणाम उम्मीद से अलग रहा
    • जब तुरंत जवाब देकर सटीक समाधान दिया जा सकता था, तो customers को impress किया जा सकता था
    • लेकिन ज़्यादातर sincere replies ने customers को गहरी satisfaction नहीं दी, और कभी-कभी उन्हें और चिढ़ा दिया

Subscription और pricing queries

  • subscription और pricing से जुड़ी emails ने relationship building में लगभग कोई मदद नहीं की
  • Castro ने pricing और subscription model पर पहले ही बहुत विचार किया था, और किसी एक email से policy बदलने वाली नहीं थी
  • यह समझाया जा सकता था कि एक essential app के लिए भुगतान करना क्यों worthwhile है या software subscription model के लिए क्यों suitable है, लेकिन users आम तौर पर उस जवाब से संतुष्ट नहीं हुए
  • दो साल में शायद एक ही customer ऐसा था जिसने हैरानी के साथ स्वीकार किया कि software में पैसे लगते हैं और उस पर रोज़ काम होता है, इसलिए subscription उचित है
  • 99% मामलों में, कितनी भी सावधानी और विनम्रता से समझाने पर भी reply पहले email से ज़्यादा negative होकर लौटा
  • request करने वालों को अतिरिक्त 30-day trial देने की कोशिश भी की गई, लेकिन emails का tone नहीं बदला, और उस trial का conversion rate सामान्य free trial से काफी कम था

Bug queries से मिलने वाले signals और उनकी सीमाएं

  • bug emails प्राप्त करने वाली टीम के लिए वास्तव में उपयोगी होती हैं
    • users को रोज़ जिन समस्याओं का सामना करना पड़ता है, उन्हें समझा जा सकता है
    • अगर bug पहले से known हो और fix हो रहा हो, या पहले ही fix कर दिया गया हो, तो customer को satisfying जवाब दिया जा सकता है
    • App Store distribution process के कारण ऐसा भी अक्सर होता है कि bug fix हो चुका है लेकिन अभी release नहीं हुआ
  • समस्या यह है कि कई bugs इन ideal cases में नहीं आते
    • कुछ bugs ऐसे होते हैं जिनके बारे में पहले सुना है, लेकिन उन्हें खुद verify या reproduce नहीं कर पाते
      • user को extra work करना पड़ता है या उन्हें समाधान नहीं मिलता, जिससे दोनों पक्षों के लिए खराब experience बनता है
      • बहुत कभी-कभार reproducible steps या meaningful conditions वाली detailed report मिलती है
    • कुछ bugs पहली बार सुनाई देते हैं
      • user details दे सकता है, लेकिन अगर यह दूसरे users में नहीं दिखता, तो priority कम होने की संभावना अधिक होती है
    • कुछ emails में बस “काम नहीं कर रहा” लिखा होता है
      • अगर user अतिरिक्त जानकारी नहीं देता, तो करने के लिए लगभग कुछ नहीं होता
    • कुछ issues पहले से known होते हैं, लेकिन fix बड़ा होता है, impact छोटा होता है, या देखने वाले users कम होते हैं, इसलिए priority कम होती है
  • इस तरह की replies ने meaningful closeness नहीं बनाई
  • ईमानदारी से “हम आज समस्या हल नहीं कर सकते और कोशिश भी नहीं करेंगे” के करीब जवाब देना user के लिए बहुत खराब experience हो सकता है
  • support emails problem signals के रूप में उपयोगी हैं, लेकिन Castro को आम तौर पर telemetry और crash logs से बेहतर data मिला

जहां human intervention सच में मदद करती है, ऐसे दुर्लभ मामले

  • App Store process, store issues, specific region, या बहुत specific podcast issue जैसे complex questions कभी-कभी आते हैं
  • एक user के पास दो अलग-अलग accounts पर अलग-अलग समय में Castro subscriptions थे, और वह एक subscription expire करते हुए पहले से paid period की guarantee चाहता था
  • Castro ने इस समस्या को जल्दी हल किया, और इस तरह की responsiveness की users ने सच में सराहना की
  • हालांकि ऐसी queries कुल support emails की 1% से भी कम थीं, इसलिए support को differentiation strategy बनाने के लिए इनका हिस्सा बहुत छोटा था

Confused customers और दोहराता बोझ

  • customers कभी-कभी podcast कैसे काम करता है, App Store कैसे काम करता है, Mac का इस्तेमाल, या अन्य peripheral issues को लेकर confused होकर email भेजते हैं
  • यह category expected customer relationship building के सबसे करीब थी, लेकिन परिणाम सबसे खराब रहे
  • वही user बार-बार query करता, और जब उसे पता चल जाता कि Castro जवाब देता है, तो requests और frequent व burdensome होने लगती थीं
  • relationship और loyalty बनाने के लक्ष्य के उलट, वास्तव में सबसे ज़्यादा मांग करने वाले लोगों पर बहुत समय खर्च होने लगा
    • उनकी subscription fee अधिक नहीं होती
    • वे शायद ही कभी संतुष्ट होते
    • नतीजतन exploited होने जैसा महसूस होने लगता

Feature requests और product direction

  • feature requests और general feedback theory में अच्छे और कभी-कभी उपयोगी होते हैं, लेकिन अक्सर मजबूत opinions रखने वाले छोटे और कम representative user segment से बार-बार आते हैं
  • email-based suggestions implement करने पर जल्द ही आपको पूरा product roadmap मिलने की संभावना होती है
  • Castro स्पष्ट direction वाला app है, और क्या बनाना है व आगे क्या करना है, इस पर पहले ही बहुत विचार किया जा चुका था
  • feature requests के सच में implement होने की संभावना कम होती है
  • demanding power users के हिसाब से ज़्यादा ढलने पर, app के काम करने का तरीका अच्छी तरह न समझने वाले new users को दूर करने का जोखिम होता है
    • power users अपेक्षाकृत ऐसे users हैं जिन्हें छोड़कर जाना कठिन होता है
    • new users को दूर करना product के लिए घातक है
  • user के नजरिए से “अभी तुरंत बनाएंगे” से अलग जवाब आम तौर पर lukewarm या negative लगता है
  • यह ईमानदार जवाब कि past में इस पर सोचा या कोशिश की थी लेकिन अच्छा नहीं हुआ, loyalty या closeness बनाने में ज्यादा मददगार नहीं रहा

Castro ने जो support operation style चुना

  • Castro के लिए support पर बहुत अधिक time खर्च करने वाला तरीका differentiation factor नहीं था, और अक्सर उल्टा असर करता था
  • subscription fee देने वाले लेकिन email से कुछ free में न मांगने वाले customers भी उतनी ही अच्छी app के हकदार हैं जितने हर हफ्ते email भेजने वाले customers
  • किसी specific issue के लिए clear solution या fix हो तो actively solve करना अच्छा है
  • वरना संक्षेप में यह जवाब देना कि email के लिए धन्यवाद, उसे पढ़ा जा रहा है, और issue सुधारने के लिए product पर लगातार काम हो रहा है—बेहतर परिणाम देता है
  • explanations और details से बचने पर आम तौर पर neutral response मिलता है, और कोई भी लंबी बातचीत में नहीं फंसता या जरूरत से ज्यादा समय खर्च नहीं करता
  • Castro के लिए वही तरीका सबसे बेहतर रहा जो अधिकांश companies अपनाती हैं
  • जिस क्षण user frustrated हो और कुछ काम न कर रहा हो, उस समय loyalty या closeness बनाना मुश्किल था; वास्तविक positive experience तब हुआ जब product बेहतर हुआ

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 9 시간 전
Hacker News की राय

  • जिन सेवाओं का मैं इस्तेमाल करता/करती हूँ, उनके customer support से उपयोगी जवाब मुझे बहुत कम मिले हैं। इसलिए मैंने सोचा था कि अगर मैं अपना product रोज़ इस्तेमाल करूँ, हर email पढ़ूँ और ईमानदारी से जवाब दूँ, तो लोग आभारी होंगे और कुछ हद तक loyalty और goodwill बनेगी।
    मैं 16,000 users वाली app चलाता/चलाती हूँ, हफ्ते में 2–5 support tickets मिलते हैं, और मैं सब पढ़ता/पढ़ती हूँ।
    app का करीब 20% users के सुझावों के आधार पर बना है, लोग आम तौर पर विनम्र हैं और कई platforms पर मुफ्त में app का प्रचार कर देते हैं। marketing budget नहीं है।
    users हमेशा शब्दों में धन्यवाद नहीं कहते, लेकिन bug reproduce करने के steps साफ़-साफ़ भेजते हैं, screenshots या videos देते हैं, और follow-up सवालों का जल्दी जवाब देकर problem solve करने में सक्रिय मदद करते हैं। Reddit या YouTube comments में मेरी app recommend करते लोग भी अक्सर दिख जाते हैं, जिससे मैं हैरान रह जाता/जाती हूँ।
    अगर आप users को अच्छी तरह support कर रहे हैं, तो काफी संभावना है कि वे भी अपने तरीके से पहले ही लौटाकर दे रहे हैं।

    • यह app की किस्म और user base क्या है, इस पर बहुत ज़्यादा निर्भर कर सकता है।
    • हफ्ते में 5 tickets पढ़ना उतना बड़ा brag नहीं लगता जितना सोचा जा रहा है। फिर भी अगर हर ticket का जवाब डाक के पत्र से दिया होता, तो impressive होता।

  • यह कोई बहुत दिलचस्प comment नहीं है, लेकिन negative reactions ज़्यादा दिख रहे हैं, इसलिए balance जोड़ना चाहता/चाहती हूँ।
    experiment करके देखने वाली बात interesting है, और results share करने के लिए धन्यवाद। थोड़ा depressing है, फिर भी कुल मिलाकर reasonable लगता है।

    • कई लोग author को ऐसे पढ़ रहे हैं जैसे वह “likes” पाना चाहता था, लेकिन लगता है article को बहुत कठोरता से पढ़ा गया है।
      सालाना millions of dollars तक खर्च करने वाले enterprise customers को support करना और हर penny पर नज़र रखने वाले end users को support करना expectations, technical capability, professionalism आदि के लिहाज़ से पूरी तरह अलग खेल है।
      मुझे लगता है यह article इस बात को अच्छी तरह summarize करता है कि आप हमेशा हर user की मदद नहीं कर सकते। tech support में यह सीखना मुश्किल lesson है; हर कोई customer की problem solve करने वाला चमकदार hero बनना चाहता है, लेकिन सही तरीके से “नहीं” कहना uncommon skill है।
      author पर हमला करने वालों से कहना चाहूँगा/चाहूँगी कि लोगों को पैसे देकर software इस्तेमाल करवाओ, फिर भी शिकायत और गाली देने वाले लोग बहुत बड़ी संख्या में मिलेंगे। customer interests, time pressure, individual mental health आदि को balance करना लगभग ज्यों का त्यों tech support का काम है।
    • मेरा भी यही विचार था। original author को इस article के लिए काफी criticism झेलना पड़ेगा, लेकिन यह mass-market product से जुड़े मेरे अनुभव से बहुत मेल खाने वाला सचमुच बढ़िया लेख है।
      यह पीछे मुड़कर देखने लायक record है, इसलिए मैंने इसे तुरंत कुछ early founders को भेजा जो undesirable customers पर हैरान कर देने जितना समय जला रहे हैं।
    • HN पर मौजूद हर व्यक्ति को ऐसा लगता है कि वह original author से उसका business बेहतर चला सकता है, और customers या potential customers के 100% को 100% satisfy कर सकता है।
      idealism reality से टकराते ही ज़्यादा देर टिकता नहीं।
    • मैं भी सहमत हूँ। लगता है हर software owner अंदर ही अंदर ऐसा सोचता है, लेकिन backlash के डर से कोई मानना नहीं चाहता।

  • लेख का core यह है: “दूसरे शब्दों में, हमारे लिए सबसे अच्छा तरीका वही है जो ज़्यादातर कंपनियाँ करती हैं।”
    हर inexperienced founder यह वादा करते हुए शुरू करता है कि वह Google, Comcast जैसी बड़ी कंपनियों जैसा खराब support नहीं देगा, और मानता है कि यही success का रास्ता बनेगा।
    लेकिन अंततः उसे सीखना पड़ता है कि अपने market की दूसरी companies जितना support देती हैं, उसे भी उसी level का support देना होगा। support सचमुच बेहतर हो तो भी कोई ठीक से notice नहीं करता, और उसका बहुत बड़ा मतलब नहीं बनता।
    inexperienced founders ज़िद्दी होते हैं, और यह एक strength भी है। इसलिए आम तौर पर वे यह lesson खुद भुगतने के बाद ही सीखते हैं।

    • podcast player launch करने वाले business के लिए यह बिल्कुल सही बात लगती है।
      लेकिन big-company style support अनिवार्य तभी है जब company को scale करना ही हो। कई markets में higher margins और premium product/support के साथ भी आराम से survive किया जा सकता है।

  • customer support को “differentiator” या revenue कमाने के तरीके के रूप में देखना depressing है। बस customer के लिए जो सबसे अच्छा हो, वही करने की कोशिश करनी चाहिए।
    अभी मिल रहा feedback सोने जैसा है, और सही तरीके से handle करें तो इसे ignore करने के बजाय use किया जा सकता है। pricing model का विरोध करने वालों को business न समझने वाला मान लेना भी बहुत कुछ दिखाता है।
    अपने pricing model को कुछ लोगों, खासकर subscription fatigue झेल रहे लोगों के लिए खराब मानें, और तय करें कि उनका पैसा खोना या शुरू से न मिलना आपको मंज़ूर है या नहीं।
    support strategy में उन users के लिए पूछने का रास्ता missing है जिनके बहुत questions हैं, और असल में अपनी structure की कमी का दोष customers पर डाला जा रहा है। power users एक-दूसरे की मदद कर सकें और developer कभी-कभी आकर मदद करे या pain points दर्ज करे, ऐसा forum बनाना तो आसान है।
    इसके अलावा development और QA process भी साफ़ तौर पर check करनी चाहिए। bug reports “सबके समय की बर्बादी” जैसे इसलिए लगते होंगे क्योंकि app में proper error logging या telemetry नहीं है। users की manual bug reports का इंतज़ार करना अपने आप में पहले से failure है।
    product को अपनी इच्छा के अनुसार define करना और feature requests reject करना पूरी तरह ठीक है, लेकिन बाकी लोगों की distributed thinking की तुलना में अकेले कुर्सी पर बैठकर सभी problems खुद सोच लेने का दावा करना काफी arrogant है।

    • कुछ subscription situations में दोनों sides के लिए suitable pricing दी जा सकती है।
      PhotoSync नाम की app premium option $1/month या lifetime $24 में देती है। शायद उन्होंने average subscription duration देखा होगा और वह 2 साल के आसपास रहा होगा। money की time value और per-transaction processing cost अलग बात है।
      personally, 24 महीने बाद भी मैं वह app इस्तेमाल करूँगा/करूँगी या नहीं यह clear न होने पर भी one-time purchase मुझे कहीं बेहतर लगा। यह मेरे थोड़े messy money management तरीके से बेहतर match करता है।
    • “अकेले कुर्सी पर बैठकर सभी problems खुद सोच लेने का दावा करना काफी arrogant है” वाला हिस्सा इस comment पर ही apply करें तो अजीब तरह से ironic है।
    • सही भी है और नहीं भी।
      जब update 2% users को roll out किया जाए, तो बाकी 98% को भेजने से पहले कुछ बहुत गलत हुआ है या नहीं जानने लायक logging और telemetry चाहिए।
      दूसरी ओर, शायद आप इतनी telemetry नहीं चाहेंगे कि customer Jim Smith के Firefox और Cloudflare Warp में split tunnel on होने और बिना mic के call join करने पर WebRTC issue होता है, यह भी detect हो जाए।
    • इसलिए HN का anti-telemetry attitude justify करना मुश्किल है।
    • आपने blog post कैसे पढ़ा, पता नहीं, लेकिन वह interpretation कम से कम charitable नहीं लगती।
      author ने लिखा था कि उनके पास पहले से sufficiently good telemetry है, और customer को email में “हमें issue की जानकारी है और report के लिए धन्यवाद” जैसे general reply के अलावा कहने को खास कुछ नहीं होता, इसलिए वह customers के लिए भी और उनके लिए भी useful नहीं है।

  • कॉलेज के समय मैं एक बेकरी में काम करता था, और दुकान पर आने वाले ग्राहकों से बात करते-करते सच में कुछ लंबे समय तक टिकने वाले दोस्त बन गए थे
    बाद में उसी अनुभव के आधार पर मुझे ईमेल support का काम मिला, जहाँ मैं users के software plugin से जुड़े सवालों के जवाब देता था। भले ही कोई customer महीने में एक बार ईमेल भेजता हो, वहाँ मैंने कभी लंबे समय तक चलने वाली दोस्ती नहीं बनाई
    फर्क यह है कि ईमेल/online support में इंसानी खाली समय नहीं होता। बेकरी में ऑर्डर की चीज़ गरम या bake होने तक इंतज़ार करते हुए बातचीत स्वाभाविक रूप से शुरू हो जाती थी। कम से कम 10 साल पहले, जब मोबाइल फोन आज जितने हर जगह मौजूद नहीं थे, तब ऐसा था
    सोचता हूँ कि software context में मासिक Zoom “open office hours” जैसी चीज़ से क्या इस एहसास को कुछ हद तक दोहराया जा सकता है। शायद नहीं, लेकिन ईमेल का जवाब देने से बेहतर हो सकता है

    • ईमेल/online support में रिकॉर्ड बच जाने वाली बात भी है। मैं किसी की ज़िंदगी के बारे में पूछने का लिखित रिकॉर्ड नहीं छोड़ना चाहूँगा। बाद में audit हो तो समस्या हो सकती है

  • “चाहे कितनी भी सावधानी और विनम्रता से समझाएँ, 99% मामलों में जवाब पहले ईमेल से भी ज्यादा नकारात्मक होता है” वाली बात से सहमत हूँ
    product leader की भूमिका में रहते हुए मुझे customer support का कुछ हिस्सा खुद करना पसंद था, और यह आम अनुभव है। गुस्से में ईमेल लिखने वाले customer को आपके कारणों में रुचि नहीं होती। उन्हें सस्ता plan, कोई खास feature, discount, free benefit जैसी कोई चीज़ चाहिए होती है और बाकी की परवाह नहीं होती
    यह “मुझे manager से बात करनी है” टाइप customer का digital version है, जो सोचता है कि अगर बदतमीज़ी से दबाव डालने पर भी मनचाही चीज़ मिलने की 10% संभावना है, तो अंत तक दबाव बनाना worth it है
    कभी-कभी किसी ऐसे व्यक्ति से छोटी-सी संतुष्टि मिलती थी जिसे यह एहसास हो जाता था कि ईमेल address के दूसरी तरफ कोई परवाह करने वाला इंसान है, और तब यह काम valuable लगता था
    लेकिन ज्यादातर यह एक transactional game खेलने जैसा होता है, जिसमें लोग सोचते हैं कि अगर वे काफी जोर से शिकायत करें तो company पर किसी तरह की power चला सकते हैं
    इसमें cultural differences भी बहुत बड़े हैं। जिस एक देश में हम service देते थे, वहाँ से आने वाले customer contacts बेकाबू हद तक खराब थे। कभी-कभी हल्की हिंसा की धमकियाँ भी होती थीं, और उनमें से 90% एक ही देश से आती थीं—नाम नहीं बताऊँगा, लेकिन उसे मैंने अपने दिमाग की “जहाँ नहीं जाना” वाली list में जोड़ लिया। यह इतना consistent था कि अजीब लगता था

    • ऐसे लोगों को तुरंत बाहर कर देना चाहिए। वे सिर्फ खुद खराब customers नहीं होते, बल्कि अच्छे customers को भी दूर भगा देते हैं
    • लगभग 20 साल तक product और technical support के बीच काम करते हुए, मैंने कुछ देशों के customers के साथ support interactions में दिलचस्प common patterns भी देखे
      सब नकारात्मक नहीं थे, बस अलग थे। कोई देश पहले लंबी तारीफ करता है और फिर indirect तरीके से discount मांगता है। कोई देश genuine issue या bug लेकर संपर्क करता है, और समाधान के बाद असुविधा के बदले compensation की उम्मीद करता है। यहाँ तक कि जब कारण उन्होंने खुद पैदा किया हो, तब भी ऐसा था
      कुछ जगहों पर बातचीत खत्म हो जानी चाहिए, फिर भी वे हर बार ticket फिर से खोलकर लंबा-चौड़ा धन्यवाद और आभार लिखते थे
      इससे मुझे यह फिर से सोचने पर मजबूर होना पड़ा कि customer या client के रूप में interact करते समय मेरा अपना रवैया कैसा होता है, और दूसरे देशों के लोग मेरे देश को कैसे देखते होंगे

  • असफलता की कहानियाँ बहुत मूल्यवान होती हैं, और मुझे वे सफलता की कहानियों से ज्यादा उपयोगी लगती हैं। सफलता की कहानियाँ अक्सर बाद की rationalization होती हैं
    दुख होता है कि इस thread के armchair geniuses ऐसे व्यवहार कर रहे हैं जैसे वे कहीं ज्यादा smart हैं और कभी fail नहीं होंगे, या कम से कम failure स्वीकार नहीं करेंगे

  • लेख में कई valuable observations हैं, लेकिन framing थोड़ी भटकी हुई लगती है। यह transactional और numbers-driven लगती है
    यह काफी अच्छी तरह known है कि तेज आवाज़ वाले users जरूरी नहीं कि representative हों। ज्यादातर संतुष्ट users support से संपर्क नहीं करते, लेकिन product सुधारने के लिए वे सबसे महत्वपूर्ण users भी होते हैं जिनसे बात करनी चाहिए
    user requests को interpret करने के लिए, आपको खुद यह model बनाना होगा कि आपके users कौन हैं। मतलब यह तय करना होगा कि यह support request signal है या noise
    अगर request target market में आने वाले किसी व्यक्ति से आई है और वह pain point व्यक्त कर रही है, तो वह महत्वपूर्ण signal हो सकती है। मौजूदा कीमत का सिर्फ 20% लेने की request तभी उपयोगी है जब आप offering structure को फिर से सोचने के लिए तैयार हों। अगर ऐसे बहुत से ईमेल आ रहे हैं, तो यह किसी खास feature-set वाले low-cost product का अवसर भी हो सकता है। नहीं तो “ईमेल के लिए धन्यवाद। फिलहाल pricing बदलने की कोई योजना नहीं है” कहकर आगे बढ़ सकते हैं
    लेकिन App Store के जरिए बेचने वाले developer के लिए ऐसी बातचीत संभव है, यह impressive है। मुझे हमेशा लगा कि Apple के बीच में आ जाने से customer relationship बनाए रखने की क्षमता खत्म हो जाती है। मैंने खुद कभी Mac App Store पर कुछ नहीं डाला

    • आखिरकार यह काम आप और आपके employees की रोज़ी-रोटी के लिए है, कोई charity activity नहीं जिसे खुशी-खुशी खाली समय में किया जा रहा हो; ऐसे में transactional और numbers-driven frame से बचना सचमुच मुश्किल है
      संतुष्ट users से बात करके product सुधारना सही है, लेकिन उसे customer support नहीं, market research कहते हैं

  • लेखक ने technical knowledge वाले व्यक्ति को hire किया, लेकिन सिर्फ इतना काफी नहीं है
    Technical knowledge और लोगों से व्यवहार करने की क्षमता अलग चीज़ें हैं
    अगर कोई खास तौर पर contact कर रहा है, तो बहुत संभव है कि आपके बारे में उसका first impression पहले से खराब हो। अगर जवाब “customer education” पर focused हो, या business की fairness को लेकर बहुत ज्यादा चिंतित हो, तो अच्छा impression बनाना मुश्किल है
    बेहतरीन customer support ऐसा होना चाहिए जिसे customer अपने दोस्तों या social media पर share करना चाहे। इस लेख में बताया गया support वैसा बनता नहीं दिखता

    • इस business में एक कदम आगे जाने का उदाहरण दें तो, Uncommon Apps को subscription business model न अपनाने वाली competing podcast apps के बारे में निष्पक्ष और उपयोगी जानकारी वाला PDF document बनाकर maintain करना चाहिए
      जब कोई Uncommon Apps से subscription model की शिकायत करे, और अगर आप उसका मन नहीं बदल सकते—जो आम तौर पर होगा—तो उसे alternatives की list भेज सकते हैं
      तब Castro support ticket उपयोगी तरीके से खत्म हो सकता है। Uncommon Apps वह sale तो वैसे भी खो देगा, लेकिन कम से कम reputation में फायदा होगा
    • बिल्कुल उल्टा। अगर first impression खराब हो, तो लोग company से संपर्क करने की जगह alternative ढूँढते हैं

  • CEO या founder का first-line support संभालना उतनी गर्व की बात नहीं हो सकती जितनी ऊपर से दिखती है
    user के नजरिए से, अगर CEO या founder मेरे सवाल का जवाब दे, तो सच कहूँ तो मुझे शक होगा कि यह कोई one-person temporary operation तो नहीं जो अगले हफ्ते गायब हो जाए
    साथ ही, संतोषजनक support experience जरूरी नहीं कि सबसे तेज experience हो। अगर मैंने कुछ मांगा और first-line support ने “नहीं” कहा, फिर sales team तक escalate किया, sales team ने भी “नहीं” कहा, फिर founder तक escalate हुआ और founder ने “हाँ” कहा, तो user को ज्यादा “सुना गया” महसूस हो सकता है और उपलब्धि का अहसास भी अधिक हो सकता है
    नतीजा वही है, लेकिन एक तरफ उसे लगता है कि उसने खुद हासिल किया