हर SaaS को सार्वजनिक चेंजलॉग की ज़रूरत क्यों है (और यह रिटेंशन कैसे सुधारता है)
आपने पिछली तिमाही में चालीस सुधार रिलीज़ किए। एक ग्राहक ईमेल करके पूछता है कि क्या उत्पाद पर अब भी काम हो रहा है।
यह कोई दुर्लभ विफलता नहीं है। यही डिफ़ॉल्ट परिणाम है। सॉफ़्टवेयर अदृश्य रूप से बेहतर होता है — आपने जो बग ठीक किया वह अब बस एक समस्या की अनुपस्थिति है, और जो सुविधा आपने जोड़ी वह एक मेन्यू आइटम है जिसे संयोग से किसी ने नहीं खोला। जब तक आप लोगों को न बताएँ कि क्या बदला, आपके उत्पाद के उपयोग का ईमानदार अनुभव यही है कि कभी कुछ नहीं बदलता।
चेंजलॉग इसका सबसे सस्ता समाधान है, और यह रिलीज़ की घोषणा से कहीं अधिक करता है।
चेंजलॉग वास्तव में आपको क्या देता है
यह साबित करता है कि उत्पाद जीवित है। आपका मूल्यांकन कर रहे किसी भी व्यक्ति के लिए, इस महीने की प्रविष्टियों वाला सार्वजनिक चेंजलॉग उस सवाल का जवाब दे देता है जो वे वैसे भी पूछने वाले थे। यह लैंडिंग पेज और सबूत के बीच का फ़र्क़ है।
यह फ़ीडबैक चक्र पूरा करता है। जिसने छह हफ़्ते पहले कुछ माँगा था उसे नहीं पता कि वह रिलीज़ हो गया। उन्हें बताना वह क्षण है जब वे सीखते हैं कि आपसे बात करने का नतीजा निकलता है — और यही उन्हें दोबारा ऐसा करने पर प्रेरित करता है।
यह उन लोगों को वापस जोड़ता है जो दूर चले गए। जिसने आपका उत्पाद उपयोग करना बंद किया उसने किसी कारण से किया। यदि कारण कोई ग़ायब सुविधा थी, तो यह बताने वाला संदेश कि वह सुविधा अब मौजूद है, वह सबसे प्रासंगिक संदेश है जो आप उन्हें कभी भेजेंगे। कोई न्यूज़लेटर नहीं। कोई वापसी अभियान नहीं। बस उस चीज़ के बारे में एक पंक्ति का तथ्य जो वे चाहते थे।
यह सपोर्ट घटाता है। हालिया बदलावों की एक दृश्य सूची "क्या यह टूट गया?" और "क्या यह नया है?" जैसे टिकटों का एक वास्तविक हिस्सा लिखे जाने से पहले ही सोख लेती है।
ऐसी प्रविष्टियाँ कैसे लिखें जिन्हें लोग पढ़ें
उससे शुरू करें जो उपयोगकर्ता अब कर सकता है। "एक्सपोर्ट पाइपलाइन को रीफ़ैक्टर किया" नहीं, बल्कि "एक्सपोर्ट में अब संग्रहीत आइटम शामिल हैं और वे मिनटों के बजाय सेकंडों में पूरे होते हैं।" आंतरिक सटीकता लक्ष्य नहीं है; पहचान योग्यता है। पाठक को चार शब्दों में यह बता पाना चाहिए कि यह प्रविष्टि उसके बारे में है या नहीं।
हर प्रविष्टि को लेबल करें। तीन श्रेणियाँ काफ़ी हैं: जो पहले नहीं था उसके लिए नया, जो बेहतर हुआ उसके लिए बेहतर, और जो टूटा हुआ था उसके लिए ठीक किया गया। पाठक उसी लेबल को स्कैन करते हैं जो उनके लिए मायने रखता है, और जिन्हें केवल बग की परवाह है वे बग ढूँढ़ सकते हैं।
प्रविष्टियाँ छोटी रखें और उन्हें बाँटें। प्रति बदलाव एक प्रविष्टि, तीन-तीन वाक्य की, सब कुछ समेटने वाली एक मासिक पोस्ट से बेहतर है। छोटी प्रविष्टियों को अलग-अलग लिंक किया जा सकता है, सपोर्ट उत्तर में उद्धृत किया जा सकता है, और सूत्र खोए बिना छोड़ा जा सकता है।
जब बात दृश्य की हो तो दिखाएँ। स्क्रीन से जुड़ी किसी भी चीज़ के लिए एक स्क्रीनशॉट या पाँच सेकंड का क्लिप एक पैराग्राफ़ से ज़्यादा काम करता है। बैकएंड काम में इसे छोड़ दें — कुछ न होने की तस्वीर, तस्वीर न होने से बुरी है।
उस व्यक्ति के लिए लिखें जिसने सुविधा इस्तेमाल नहीं की। मान लें कि कोई संदर्भ नहीं है। स्क्रीन का नाम लें। यदि सेटअप चाहिए, तो बताएँ कहाँ।
शर्म के मारे बैच न बनाएँ। छोटी प्रविष्टियाँ कमज़ोरी नहीं हैं। पिछले महीने ग्यारह मामूली आइटम वाला चेंजलॉग गति की तरह पढ़ा जाता है। प्रति तिमाही एक भारी-डिज़ाइन वाली पोस्ट ऐसी कंपनी की तरह पढ़ी जाती है जो तिमाही में एक बार रिलीज़ करती है।
इसे लोगों के सामने लाएँ
जिस चेंजलॉग पर कोई नहीं आता वह एक डायरी है। वितरण ही अधिकांश मूल्य है:
- ईमेल सदस्यता। लोगों को ऑप्ट इन करने दें और प्रकाशन पर भेजें। यही वह चैनल है जो निष्क्रिय उपयोगकर्ताओं तक पहुँचता है, क्योंकि इसके लिए उन्हें पहले आपका ऐप खोलने की ज़रूरत नहीं।
- RSS. देना सस्ता है, और डेवलपर दर्शक वाकई अब भी इसका उपयोग करते हैं।
- उत्पाद के भीतर। आपके नेविगेशन में एक लिंक या खाता मेन्यू पर एक अनाक्रामक बैज सक्रिय उपयोगकर्ताओं को ठीक उस क्षण पकड़ता है जब वे उस चीज़ को आज़मा सकते हैं।
- माँगने वालों को विशेष रूप से सूचित करें। सबसे मूल्यवान संदेश प्रसारण नहीं है — वह संदेश है जो उन ग्यारह लोगों को बताता है कि जिस चीज़ के लिए उन्होंने वोट किया था वह अब मौजूद है।
SupDesk कहाँ फ़िट होता है
SupDesk आपके पोर्टल पर एक चेंजलॉग मॉड्यूल देता है, और यदि आप चाहें तो आपके अपने डोमेन पर।
- हर प्रविष्टि पर नया / बेहतर / ठीक किया गया लेबल, ताकि पृष्ठ बढ़ने पर भी स्कैन करने योग्य बना रहे।
- ईमेल सदस्यता और RSS फ़ीड। प्रविष्टि प्रकाशित करने पर आपके ग्राहकों को ईमेल जाता है, और अनसब्सक्राइब आपके लिए संभाल लिया जाता है।
- माँगने वालों को स्वतः सूचना। किसी चेंजलॉग प्रविष्टि को उन फ़ीडबैक पोस्ट से जोड़ें जिन्हें वह हल करती है, और प्रकाशित करने पर उन पोस्ट पर वोट करने वाले सभी को बता दिया जाता है। यही वह चक्र है जो आपके कोई सूची रखे बिना पूरा हो जाता है।
- मशीन अनुवाद। प्रविष्टियों का Cloudflare Workers AI से आपकी समर्थित भाषाओं में अनुवाद किया जा सकता है, और अनुवाद लाइव होने से पहले समीक्षा और संपादन आपका है — मशीन की गति, अंतिम फ़ैसला इंसान का।
- दर्शक लक्ष्यीकरण। जब कोई बदलाव अभी सामान्य न हुआ हो, तो प्रविष्टि सबके लिए प्रकाशित करें, या केवल अपने बीटा प्रोग्राम के लिए।
दायरे के बारे में एक ईमानदार बात: प्रविष्टियाँ तब प्रकाशित होती हैं जब आप उन्हें प्रकाशित करते हैं। कोई शेड्यूल्ड-सेंड नहीं है, इसलिए सुबह 6 बजे जाने वाली रिलीज़ चेंजलॉग पर तब आती है जब आप बटन दबाते हैं, उससे पहले नहीं।
आदत ही कठिन हिस्सा है
चेंजलॉग की यांत्रिकी में एक दोपहर लगती है। हर बार डिप्लॉय करते समय तीन पंक्तियाँ लिखने का अनुशासन ही वास्तव में रिटेंशन प्रभाव पैदा करता है, और यही वह हिस्सा है जो सबसे पहले छूटता है।
इसे रिलीज़ के बाद का काम बनाने के बजाय रिलीज़ का हिस्सा बनाइए। प्रविष्टि तब लिखी जाती है जब आपको अब भी याद है कि बदलाव क्यों मायने रखता था, और तभी उसे लिखना सबसे आसान भी होता है।
अपना चेंजलॉग सेट करें, अपने पहले उपयोगकर्ताओं को सब्सक्राइब कराएँ, और अगली रिलीज़ को स्वयं अपनी घोषणा करने दें। supdesk.app पर शुरू करें