मुख्य सामग्री पर जाएं
SaaS प्रोडक्ट टीमें

सॉफ्टवेयर और ऐप्स

कैसे एक SaaS टीम ने एक फीडबैक चैनल बनाया जो रोडमैप को फीड करता है और चर्न को कम करता है

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

यह क्या बचाता है

शांत निराशा को रोडमैप सिग्नल में बदलें

ड्राफ्ट प्रीव्यू
प्रति[email protected]
विषयइन-ऐप फ़ीडबैक: [क्षेत्र]

एक सब्सक्रिप्शन प्रोडक्ट रिन्यूअल पर जीता और मरता है, और जिन ग्राहकों को बनाए रखना सबसे कठिन होता है वे शांत ग्राहक होते हैं। वे कोई सपोर्ट टिकट नहीं खोलते। वे आपके NPS सर्वे का जवाब नहीं देते। वे एक कठिन किनारे से टकराते हैं — एक भ्रमित करने वाली स्क्रीन, एक गायब फीचर, एक छोटा सा बग जो दिन के पांच मिनट बर्बाद करता है — और वे इसे एक और कारण के रूप में दर्ज कर लेते हैं कि यह टूल पूरी तरह से लायक नहीं है। तीन महीने बाद वे रद्द कर देते हैं, और कारण बॉक्स कहता है 'अब आवश्यकता नहीं है'। वह फ़ीडबैक जो उस अकाउंट को बचा सकता था, मौजूद था। बस इसे कभी भी उपयोगकर्ता के दिमाग से बाहर और आप तक पहुंचने का आसान तरीका नहीं मिला। ## समस्या: उपयोगी फ़ीडबैक आप तक कभी नहीं पहुंचता ज़्यादातर SaaS टीमों के पास फ़ीडबैक चैनल होते हैं, और उनमें से ज़्यादातर लीक होते हैं। एक सपोर्ट ईमेल पता एक हेल्प पेज पर मौजूद होता है जिस पर कोई भी काम के बीच में विज़िट नहीं करता है। एक सप्ताह बाद ईमेल के ज़रिए एक सर्वे आता है, जब निराशाजनक क्षण बीत चुका होता है। एक कम्युनिटी फ़ोरम उपयोगकर्ताओं को एक और अकाउंट बनाने के लिए कहता है। इनमें से प्रत्येक ठीक गलत समय पर घर्षण जोड़ता है — जिस क्षण कोई उपयोगकर्ता नाराज़ और व्यस्त होता है, वह क्षण ऐसा होता है जब वह शिकायत करने के लिए सही जगह खोजने नहीं जाएगा। इसलिए आपको जो सिग्नल मिलता है वह तिरछा होता है। आप उन कम संख्या में पावर यूज़र्स से सुनते हैं जो आपके फ़ीडबैक फ़ॉर्म को ढूंढ निकालेंगे, और उन कुछ नाराज़ लोगों से जो ज़ोर-शोर से चर्न करते हैं। आप बड़े, शांत मध्य वर्ग को खो देते हैं: वे उपयोगकर्ता जो आपको बता सकते थे कि क्या गलत था अगर आपको बताने में पांच मिनट के बजाय पांच सेकंड लगते। ## समाधान: ऐप के अंदर एक 'फ़ीडबैक भेजें' बटन जहां काम होता है वहां एक **फ़ीडबैक भेजें** लिंक रखें — ऐप के हेडर में, हेल्प मेनू में, या एक छोटे से कॉर्नर विजेट में। यह उपयोगकर्ता के ईमेल ऐप को एक छोटे, स्ट्रक्चर्ड ड्राफ्ट के साथ खोलता है जो पहले से लिखा होता है, जो आपके प्रोडक्ट इनबॉक्स को संबोधित होता है। चूंकि यह बटन एक लॉग्ड-इन ऐप के अंदर रहता है, आप उस संदर्भ को स्वचालित रूप से अटैच कर सकते हैं जिसकी आपकी टीम को हमेशा आवश्यकता होती है। उपयोगकर्ता को आपको यह बताने की ज़रूरत कभी नहीं होती कि वे कौन हैं या वे किस प्लान पर हैं; आपका ऐप पहले से जानता है। ```html <a id="feedback" href="#">फ़ीडबैक भेजें</a> <script> const a = document.getElementById('feedback'); const body = 'Type: [bug / idea / question]\n\n' + 'What I was trying to do:\n' + 'What happened or what I would love instead:\n\n' + 'Plan: ' + window.CURRENT_PLAN + '\n' + 'Account: ' + window.CURRENT_ACCOUNT_ID + '\n' + 'Screen: ' + location.pathname; a.href = 'mailto:[email protected]' + '?subject=' + encodeURIComponent('In-app feedback: ' + document.title) + '&body=' + encodeURIComponent(body); </script> ``` इस साइट का जनरेटर एनकोड किया गया `mailto:` लिंक बनाता है; ऊपर दिया गया छोटा स्क्रिप्ट ड्राफ्ट खुलने से पहले बस लाइव अकाउंट डिटेल्स को स्वैप करता है। ## क्यों अटैच किया गया संदर्भ सब कुछ बदल देता है एक कच्चा 'यह भ्रामक है' संदेश सपोर्ट एजेंट को जासूस बनने पर मजबूर करता है: कौन सा अकाउंट, कौन सा प्लान, कौन सी स्क्रीन, क्या यह कोई बग है या कोई अनुरोध? एक पहले से भरा हुआ फ़ीडबैक ईमेल यह सब पढ़ने से पहले ही उनके जवाब दे देता है。 - **अकाउंट और प्लान** आपको बताते हैं कि क्या यह एक ट्रायल उपयोगकर्ता है, चर्न-रिस्क वाला एंटरप्राइज़ अकाउंट है, या एक फ्री टियर है — ताकि आप जवाब और सुधार को प्राथमिकता दे सकें। - **स्क्रीन और एक्शन** एक इंजीनियर को बग को जल्दी से रिप्रोड्यूस करने देते हैं। - **एक टाइप टैग** (बग, आइडिया, प्रश्न) एक साधारण इनबॉक्स रूल को संदेश को सही जगह पर रूट करने देता है: बग्स को ट्रैकर में, आइडियाज़ को रोडमैप बोर्ड में, प्रश्नों को सपोर्ट में। यह चैनल एक ब्लैक होल बनना बंद कर देता है और एक स्ट्रक्चर्ड इनपुट बनना शुरू कर देता है। एक तिमाही के दौरान, केवल सब्जेक्ट टैग्स आपको दिखाते हैं कि प्रोडक्ट के कौन से हिस्से सबसे अधिक घर्षण पैदा करते हैं। ## सेटअप 1. एक प्रोडक्ट इनबॉक्स या एलियास बनाएं, जैसे `product@` या `feedback@`, जिसे सपोर्ट और प्रोडक्ट दोनों देख सकें। 2. जनरेटर में बेस लिंक बनाएं: प्राप्तकर्ता, 'इन-ऐप फ़ीडबैक: [क्षेत्र]' जैसा सब्जेक्ट, और स्ट्रक्चर्ड बॉडी प्रॉम्प्ट。 3. छोटी स्क्रिप्ट जोड़ें ताकि प्लान, अकाउंट ID और स्क्रीन आपके ऐप के सेशन से अपने आप भर जाएं。 4. बटन को ऐसी जगह रखें जहां हमेशा पहुंचा जा सके — एक लगातार दिखने वाला हेडर आइटम दबे हुए सेटिंग्स पेज से बेहतर होता है。 5. सब्जेक्ट टैग या 'Type' लाइन के आधार पर रूल्स के साथ आने वाले मेल को रूट करें। कोई नई सर्विस खरीदने या कोई SDK इंस्टॉल करने की ज़रूरत नहीं है। यह चैनल एक `mailto:` लिंक और कुछ लाइनों का ग्लू कोड है, जिसका अर्थ है कि इसे एक दोपहर में शिप किया जा सकता है और यह वेब और एम्बेडेड वेबव्यू में समान रूप से काम करता है। ## यह क्या बचाता है सबसे बड़ी बचत **रिटेंशन** है। हर शांत निराशा जो एक संदेश में बदल जाती है, वह किसी समस्या को ठीक करने, व्यक्तिगत रूप से जवाब देने और एक ऐसे अकाउंट को बनाए रखने का मौका है जो अन्यथा चला गया होता। गणित को सही साबित करने के लिए आपको बहुत अधिक बचाने की आवश्यकता नहीं है: महीने में केवल एक या दो भुगतान करने वाले अकाउंट को बनाए रखना जो चर्न हो गए होते, बटन बनाने की लागत को काफी कम कर देता है, क्योंकि बटन की लागत लगभग शून्य है। एक **रोडमैप की बचत** भी है। फीचर अनुरोध जो पहले बिखरे हुए इनबॉक्स और हॉलवे वार्तालापों में रहते थे, अब एक जगह टैग किए गए और खोजने योग्य आते हैं। जब एक तिमाही की योजना बनाने का समय आता है, तो आपके पास अनुमान लगाने के बजाय वास्तविक मांग का संकेत होता है — और जब उनका विचार शिप होता है तो आप मूल अनुरोधकर्ताओं को जवाब दे सकते हैं, जो किसी प्रोडक्ट टीम के पास सबसे सस्ते लॉयल्टी कदमों में से एक है। और एक **सपोर्ट की बचत** भी है: पहले से भरा हुआ संदर्भ उस आगे-पीछे की बातचीत को हटा देता है जो ज़्यादातर टिकटों के पहले दो जवाबों को खा जाती है, ताकि आपकी टीम प्रति घंटे अधिक समाधान कर सके। ## इसे और भी बेहतर बनाएं - त्वरित वेरिएंट ऑफ़र करें — 'बग की रिपोर्ट करें', 'फ़ीचर का अनुरोध करें', 'प्रश्न पूछें' — प्रत्येक सब्जेक्ट को पहले से टैग करता है ताकि रूटिंग स्वचालित हो जाए। - बॉडी में ऐप का वर्शन शामिल करें ताकि आप बता सकें कि क्या नवीनतम रिलीज़ में बग पहले से ही ठीक हो गया है। - एंटरप्राइज़ प्लान्स के लिए, अकाउंट के सक्सेस मैनेजर को `cc` करें ताकि उच्च-मूल्य वाले फ़ीडबैक को तेज़, व्यक्तिगत जवाब मिल सके। - समान बटन का पुन: उपयोग करने वाले किसी भी सार्वजनिक मार्केटिंग पेज पर पते को छिपाकर रखें। ## मुख्य बातें - चर्न को रोकने वाला फ़ीडबैक आमतौर पर आप तक कभी नहीं पहुंचता, क्योंकि आपके चैनल सबसे खराब समय में घर्षण जोड़ते हैं। - इन-ऐप 'फ़ीडबैक भेजें' `mailto:` बटन अकाउंट और प्लान के संदर्भ के साथ एक क्लिक में बग्स और आइडियाज़ कैप्चर करता है। - स्ट्रक्चर्ड, टैग किया गया इनपुट इनबॉक्स में गायब होने के बजाय आपके ट्रैकर और रोडमैप को फीड करता है। - यह बिना किसी नए टूल के चर्न को कम करता है, रोडमैप को शार्प करता है, और सपोर्ट के आगे-पीछे की बातचीत को कम करता है। [जनरेटर](/#generator) में अपना खुद का फ़ीडबैक बटन बनाएं, या नीचे दिए गए सेटअप को कॉपी करें।

फ़ीडबैक भेजें (टेस्ट)

एक सब्सक्रिप्शन प्रोडक्ट रिन्यूअल पर जीता और मरता है, और जिन ग्राहकों को बनाए रखना सबसे कठिन होता है वे शांत ग्राहक होते हैं। वे कोई सपोर्ट टिकट नहीं खोलते। वे आपके NPS सर्वे का जवाब नहीं देते। वे एक कठिन किनारे से टकराते हैं — एक भ्रमित करने वाली स्क्रीन, एक गायब फीचर, एक छोटा सा बग जो दिन के पांच मिनट बर्बाद करता है — और वे इसे एक और कारण के रूप में दर्ज कर लेते हैं कि यह टूल पूरी तरह से लायक नहीं है। तीन महीने बाद वे रद्द कर देते हैं, और कारण बॉक्स कहता है 'अब आवश्यकता नहीं है'।

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

समस्या: उपयोगी फ़ीडबैक आप तक कभी नहीं पहुंचता

ज़्यादातर SaaS टीमों के पास फ़ीडबैक चैनल होते हैं, और उनमें से ज़्यादातर लीक होते हैं।

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

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

समाधान: ऐप के अंदर एक 'फ़ीडबैक भेजें' बटन

जहां काम होता है वहां एक फ़ीडबैक भेजें लिंक रखें — ऐप के हेडर में, हेल्प मेनू में, या एक छोटे से कॉर्नर विजेट में। यह उपयोगकर्ता के ईमेल ऐप को एक छोटे, स्ट्रक्चर्ड ड्राफ्ट के साथ खोलता है जो पहले से लिखा होता है, जो आपके प्रोडक्ट इनबॉक्स को संबोधित होता है।

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

<a id="feedback" href="#">फ़ीडबैक भेजें</a>
<script>
  const a = document.getElementById('feedback');
  const body =
    'Type: [bug / idea / question]\n\n' +
    'What I was trying to do:\n' +
    'What happened or what I would love instead:\n\n' +
    'Plan: ' + window.CURRENT_PLAN + '\n' +
    'Account: ' + window.CURRENT_ACCOUNT_ID + '\n' +
    'Screen: ' + location.pathname;
  a.href = 'mailto:[email protected]'
    + '?subject=' + encodeURIComponent('In-app feedback: ' + document.title)
    + '&body=' + encodeURIComponent(body);
</script>

इस साइट का जनरेटर एनकोड किया गया mailto: लिंक बनाता है; ऊपर दिया गया छोटा स्क्रिप्ट ड्राफ्ट खुलने से पहले बस लाइव अकाउंट डिटेल्स को स्वैप करता है।

क्यों अटैच किया गया संदर्भ सब कुछ बदल देता है

एक कच्चा 'यह भ्रामक है' संदेश सपोर्ट एजेंट को जासूस बनने पर मजबूर करता है: कौन सा अकाउंट, कौन सा प्लान, कौन सी स्क्रीन, क्या यह कोई बग है या कोई अनुरोध? एक पहले से भरा हुआ फ़ीडबैक ईमेल यह सब पढ़ने से पहले ही उनके जवाब दे देता है。

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

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

सेटअप

  1. एक प्रोडक्ट इनबॉक्स या एलियास बनाएं, जैसे product@ या feedback@, जिसे सपोर्ट और प्रोडक्ट दोनों देख सकें।
  2. जनरेटर में बेस लिंक बनाएं: प्राप्तकर्ता, 'इन-ऐप फ़ीडबैक: [क्षेत्र]' जैसा सब्जेक्ट, और स्ट्रक्चर्ड बॉडी प्रॉम्प्ट。
  3. छोटी स्क्रिप्ट जोड़ें ताकि प्लान, अकाउंट ID और स्क्रीन आपके ऐप के सेशन से अपने आप भर जाएं。
  4. बटन को ऐसी जगह रखें जहां हमेशा पहुंचा जा सके — एक लगातार दिखने वाला हेडर आइटम दबे हुए सेटिंग्स पेज से बेहतर होता है。
  5. सब्जेक्ट टैग या 'Type' लाइन के आधार पर रूल्स के साथ आने वाले मेल को रूट करें।

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

यह क्या बचाता है

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

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

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

इसे और भी बेहतर बनाएं

  • त्वरित वेरिएंट ऑफ़र करें — 'बग की रिपोर्ट करें', 'फ़ीचर का अनुरोध करें', 'प्रश्न पूछें' — प्रत्येक सब्जेक्ट को पहले से टैग करता है ताकि रूटिंग स्वचालित हो जाए।
  • बॉडी में ऐप का वर्शन शामिल करें ताकि आप बता सकें कि क्या नवीनतम रिलीज़ में बग पहले से ही ठीक हो गया है।
  • एंटरप्राइज़ प्लान्स के लिए, अकाउंट के सक्सेस मैनेजर को cc करें ताकि उच्च-मूल्य वाले फ़ीडबैक को तेज़, व्यक्तिगत जवाब मिल सके।
  • समान बटन का पुन: उपयोग करने वाले किसी भी सार्वजनिक मार्केटिंग पेज पर पते को छिपाकर रखें।

मुख्य बातें

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

जनरेटर में अपना खुद का फ़ीडबैक बटन बनाएं, या नीचे दिए गए सेटअप को कॉपी करें।