21 अगस्त 2026
कोई आपका डॉक्यूमेंटेशन नहीं पढ़ता — और आपका ऐक्टिवेशन रेट इसका सबूत है
आपके डॉक्स खराब नहीं हैं। वे गलत जगह पर हैं, गलत स्तर से लिखे गए हैं, और गलत पल में पढ़े जाते हैं। यह रही इस फ़ासले की पूरी पड़ताल — और वे चार आदतें, जो इसे पाट देती हैं।
हर SaaS कंपनी डॉक्यूमेंटेशन लिखती है। लगभग हर SaaS कंपनी फिर भी यूज़र्स को अटकते देखती है। ये दोनों बातें हर तिमाही रिव्यू में साथ-साथ बैठी होती हैं, और नतीजा लगभग हमेशा एक ही निकलता है: हमें बेहतर डॉक्स चाहिए। यह गलत नतीजा है। डॉक्स आम तौर पर ठीक होते हैं। समस्या यह है कि डॉक्यूमेंटेशन यूज़र से कहता है कि वह प्रोडक्ट छोड़े, अपनी स्थिति को एक सर्च क्वेरी में बदले, एक आम जवाब पढ़े, और फिर उसे वापस खास क्लिक्स में बदले — ठीक उस पल, जब वह इनमें से कुछ भी करने को सबसे कम तैयार होता है।
यह लेख उसी फ़ासले के बारे में है: वह कहाँ खुलता है, उसकी कीमत क्या है, चैट विजेट उसे क्यों नहीं पाट पाए, और असल में उसे क्या पाटता है।
डॉक्यूमेंटेशन का विरोधाभास
डॉक्यूमेंटेशन में एक ढाँचागत समस्या है, जिसे लेखन की कोई भी गुणवत्ता ठीक नहीं कर सकती। उसे वे लोग बनाते हैं जो प्रोडक्ट को पूरी तरह समझते हैं, उन लोगों के लिए जो उसे ज़रा भी नहीं समझते, और उसे एक ऐसे ब्राउज़र टैब में पढ़ा जाता है, जो प्रोडक्ट नहीं है।
इन तीनों में से हर बात एक खास नाकामी की वजह बनती है।
एक्सपर्ट का लिखा। गाइड लिखने वाला जानता है कि “अपना वर्कस्पेस कनेक्ट करें” का मतलब है अवतार पर क्लिक, फिर सेटिंग्स, फिर इंटीग्रेशन, फिर तीसरा कार्ड। वह “अपना वर्कस्पेस कनेक्ट करें” लिखता है, क्योंकि उसके लिए निर्देश यही है। यूज़र इसे पढ़ता है, चालीस इंटरैक्टिव एलिमेंट वाली स्क्रीन देखता है, और उसे कहीं भी “अपना वर्कस्पेस कनेक्ट करें” लिखा नहीं दिखता।
आम पाठक के लिए लिखा। डॉक्स प्रोडक्ट का वर्णन करते हैं, यूज़र के अकाउंट का नहीं। वे यह नहीं कह सकते कि “आप पहले ही दो सीट जोड़ चुके हैं, इसलिए जो बटन आप चाहते हैं, वह अपग्रेड करने तक ग्रे रहेगा।” वे एक ऐसे यूज़र के लिए सब कुछ ठीक-ठाक चलने वाला रास्ता बताते हैं, जो मौजूद ही नहीं: न अभी कोई डेटा, न कोई अधूरी कॉन्फ़िगरेशन, न प्लान से जुड़ी कोई पाबंदी।
कहीं और पढ़ा जाता है। जैसे ही यूज़र डॉक्यूमेंटेशन का टैब खोलता है, वह उस वर्कफ़्लो से बाहर निकल चुका होता है जिसे वह पूरा करना चाहता था। उसे लिखी हुई बातें पढ़ते हुए अपना इरादा दिमाग में संभालकर रखना पड़ता है। ज़्यादातर लोग ऐसा नहीं कर पाते, इसलिए वे सरसरी नज़र डालते हैं, अंदाज़ा लगाते हैं, और आधा-अधूरा याद रहा निर्देश लेकर प्रोडक्ट में लौट आते हैं।
कोई ऐसा वर्कफ़्लो लें, जिसे आपकी टीम अच्छी तरह डॉक्यूमेंटेड मानती है। किसी नए यूज़र को दूसरे मॉनिटर पर डॉक खोलकर उसे आज़माते देखें। गिनें कि वह कितनी बार विंडो बदलता है। यही गिनती आपके डॉक्यूमेंटेशन की असली कीमत है, और यह आपके ऐनालिटिक्स में कहीं दर्ज नहीं है।
ऐक्टिवेशन असल में कहाँ रिसता है
ऑनबोर्डिंग फ़नल आम तौर पर गलत बारीकी पर ट्रैक किए जाते हैं। टीमें साइन अप → ऐक्टिवेटेड मापती हैं, गिरावट देखती हैं, और नतीजा निकालती हैं कि प्रोडक्ट बहुत जटिल है। पर यह गिरावट कोई एक घटना नहीं है। ये तीन अलग-अलग पल हैं, और तीनों अलग-अलग वजहों से नाकाम होते हैं।
1. पहला सेटअप
यूज़र के पास इरादा है — उसने अभी-अभी साइन अप किया है, वह जोश में है, वह चीज़ को काम करते देखना चाहता है। कमी है दिशा की। उसे नहीं पता कि स्क्रीन पर मौजूद आठ चीज़ों में से पहला स्टेप कौन-सा है। यही इकलौता पल है, जहाँ ज़्यादातर प्रोडक्ट थोड़ी-बहुत मदद करते हैं, आम तौर पर एक प्रोडक्ट टूर से: टूलटिप्स का एक सिलसिला, जो तय क्रम में एलिमेंट्स को हाइलाइट करता है।
टूर तब काम करते हैं, जब यूज़र की स्थिति टूर लिखने वाले की धारणाओं से मेल खाती है। वे उसी पल टूट जाते हैं, जब यूज़र कहीं अनपेक्षित जगह क्लिक कर दे, पहले से इंपोर्ट किए गए डेटा के साथ आए, या ऐसे प्लान पर हो जहाँ चौथा स्टेप डिसेबल है।
2. दूसरा वर्कफ़्लो
यही असली खामोश कातिल है। यूज़र सेटअप पार कर गया, थोड़ी वैल्यू देखी, और अब वह असली काम करना चाहता है जिसके लिए उसने साइन अप किया था — कई स्टेप वाला, शर्तों पर चलने वाला, सच में जटिल वर्कफ़्लो, जिसे मुमकिन बनाने के लिए ही आपका प्रोडक्ट बना है।
दूसरे वर्कफ़्लो का टूर कोई नहीं बनाता। वह स्क्रिप्ट करने के लिए बहुत विविध है, और छोड़ देने के लिए बहुत अहम। इसलिए यूज़र को डॉक्यूमेंटेशन के हवाले कर दिया जाता है, और ऊपर वाला विरोधाभास हावी हो जाता है।
3. वह फ़ीचर, जो उन्हें कभी मिलता ही नहीं
सबसे महँगा रिसाव रिसाव जैसा दिखता ही नहीं, क्योंकि यूज़र कभी कोई सवाल नहीं पूछता। उसे बस वह क्षमता कभी पता ही नहीं चलती, जो उसे पावर यूज़र बना देती, और वह सबसे निचले टियर पर रिन्यू करता है — या बिल्कुल रिन्यू नहीं करता, क्योंकि वह कभी इतना आगे पहुँचा ही नहीं कि देख सके कि प्रोडक्ट अपने पैसे के लायक क्यों है।
यह सेहतमंद इस्तेमाल जैसा दिखता है। अकाउंट लॉग इन करता है, दो फ़ीचर इस्तेमाल करता है, और ग्यारह महीने बाद चर्न हो जाता है — न कोई सपोर्ट टिकट, न कोई शिकायत। आपके डैशबोर्ड में कुछ भी कभी लाल नहीं होता, क्योंकि “यूज़र को वह चीज़ कभी मिली ही नहीं जो उसे रोक लेती” कोई ऐसा इवेंट नहीं है, जिसे आप ट्रैक कर सकें।
चैट विजेट ने इसे ठीक क्यों नहीं किया
पिछले दस साल से इंडस्ट्री का जवाब रहा है: कोने में एक चैट विजेट लगा दो। पहले उसे इंसान चलाते थे, फिर बॉट, और अब LLM, जिनके पास आपके डॉक्स एक वेक्टर स्टोर में रखे हैं। इससे मदद मिली — जो यूज़र प्रोडक्ट के अंदर सवाल पूछ सकता है, वह उस यूज़र से बेहतर हालत में है जो नहीं पूछ सकता। पर इससे फ़ासला नहीं पटा, और इसकी वजह बिल्कुल साफ़ है।
चैटबॉट एक बबल में जवाब देता है। काम इंटरफ़ेस में होता है।
किसी अच्छे डॉक्यूमेंटेशन बॉट से पूछें, “SSO कैसे सेट अप करूँ?”, और आपको छह स्टेप का सही, अच्छी तरह लिखा जवाब मिलेगा। अब यूज़र को वह अनुवाद खुद करना है, जो बॉट ने छोड़ दिया:
1. पहला स्टेप पढ़ें और उसे याद रखें।
2. इंटरफ़ेस में ऐसी चीज़ ढूँढें, जो पहले स्टेप के शब्दों से मेल खाती हो।
3. अंदाज़ा लगाएँ कि एक जैसे दिखने वाले दो बटनों में से कौन-सा मतलब का है।
4. क्लिक करें, और देखें कि आने वाली स्क्रीन वैसी दिखती है या नहीं, जैसी दूसरे स्टेप में बताई गई है।
5. अगर नहीं, तो तय करें कि जवाब गलत पढ़ा गया या जवाब ही पुराना पड़ चुका है।
6. बाकी हर स्टेप के लिए यही दोहराएँ, और हर बार थोड़ा और भरोसा खोएँ।
यही अनुवाद टैक्स है, और यह चैट विजेट के हर जवाब पर वसूला जाता है। बॉट डॉक्यूमेंटेशन को तो प्रोडक्ट के अंदर ले आया, पर काम को प्रोडक्ट के अंदर नहीं लाया।
चैटबॉट एक बबल में समझाता है। कस्टमर सक्सेस मैनेजर काम पूरा करवा देता है — और असली बात न कभी समझाना थी, न बबल।
— Barkan बनाते हुए हमने यह सीखा
एक दूसरी, ज़्यादा बारीक नाकामी भी है। आपके डॉक्स पढ़ने वाला चैटबॉट जानता है कि प्रोडक्ट आम तौर पर क्या करता है। उसे यह नहीं पता कि इस वक्त यूज़र की स्क्रीन पर क्या है: वह किस प्लान पर है, कौन-से फ़ील्ड पहले ही भर चुका है, कौन-सा बटन डिसेबल है और क्यों। इसलिए उसके जवाब ठीक उन्हीं पलों में पूरे भरोसे के साथ आम-से होते हैं, जब यूज़र्स को कुछ खास चाहिए।
---
कस्टमर सक्सेस मैनेजर अलग क्या करता है
हर SaaS कंपनी इसका हल पहले से जानती है, क्योंकि वह इसे पहले से इस्तेमाल करती है — अपने सबसे बड़े क्लाइंट के लिए। किसी ग्राहक को एक तय इंसान दे दें, जो प्रोडक्ट जानता हो, उसके इस्तेमाल पर नज़र रखे, और मुश्किल हिस्सों में कॉल पर साथ बैठकर रास्ता दिखाए, तो वह ग्राहक ऐक्टिवेट होता है, अपना इस्तेमाल बढ़ाता है, और टिका रहता है।
किसी ने कभी यह नहीं कहा कि यह मॉडल काम नहीं करता। दलील हमेशा यही रही है कि यह स्केल नहीं होता: $99/महीने वाले अकाउंट पर इंसानी कस्टमर सक्सेस मैनेजर लगाकर आप टिक नहीं सकते।
तो सवाल यह नहीं कि कस्टमर सक्सेस मैनेजर वाला मॉडल काम करता है या नहीं। सवाल यह है कि उसकी कौन-सी आदतें सॉफ़्टवेयर में लाई जा सकती हैं। ऐसी चार आदतें हैं।
जानता है
“डॉक्स पढ़ चुका है” नहीं — लाइव, रेंडर हुआ इंटरफ़ेस जानता है। इस यूज़र के लिए, इस अकाउंट में, इस प्लान पर, ठीक इस वक्त स्क्रीन पर असल में क्या है। मौजूदा DOM पर टिका जवाब उस तरह गलत नहीं हो सकता, जैसे डॉक्स पर ट्रेन हुआ बॉट अपने आम-से जवाबों में हो जाता है, क्योंकि वह उसी चीज़ का वर्णन कर रहा है, जिसे वह देख सकता है।
दिखाता है
कोई कंट्रोल कहाँ है, यह बताने के बजाय उसकी ओर इशारा करें। एक कर्सर, जो असली पेज पर असली एलिमेंट तक जाता है, और इंतज़ार करता है। यही वह कदम है जो अनुवाद टैक्स को मिटा देता है: अनुवाद करने को कुछ बचता ही नहीं, क्योंकि निर्देश और इंटरफ़ेस एक ही चीज़ हैं।
खुद करता है
जो वर्कफ़्लो अच्छी तरह समझे हुए और सुरक्षित हैं, उनमें काम खुद कर दें। फ़ील्ड भरें, पूरा क्रम क्लिक करते हुए निपटाएँ, पेजों पर आगे बढ़ें। यूज़र अपने शब्दों में बताता है कि उसे क्या चाहिए, और उसे होते हुए देखता है — जो खुद करना सिखाए जाने से बुनियादी तौर पर अलग अनुभव है।
भरोसा भी यहीं जीता या खोया जाता है, इसीलिए कुछ भी मिटाने वाला या महँगा काम होने से पहले रुककर पूछना चाहिए, बाद में नहीं।
नज़र रखता है
वह आदत, जो कस्टमर सक्सेस मैनेजर को हेल्प डेस्क से अलग करती है: किसी को पूछना नहीं पड़ा। एक अच्छा CSM देख लेता है कि ग्राहक ने सेटअप तो पूरा किया, पर वह फ़ीचर कभी चालू नहीं किया जिस पर उसका यूज़ केस टिका है, और खुद संपर्क करता है। यह इस्तेमाल के संकेतों से चलने वाली एक प्रोएक्टिव पहल है, और यही वह पहल है जो टाले गए टिकटों के बजाय एक्सपैंशन रेवेन्यू लाती है।
– लाइव इंटरफ़ेस को जानता है, सिर्फ़ डॉक्यूमेंटेशन को नहीं।
– शब्दों में वर्णन करने के बजाय कर्सर से रास्ता दिखाता है।
– जाँचे-परखे वर्कफ़्लो खुद करता है, और कुछ भी मिटाने वाले काम से पहले रुकता है।
– इस्तेमाल पर नज़र रखता है, और यूज़र के अटकने या चर्न होने से पहले खुद बोलता है।
डॉक्स, चैटबॉट, कस्टमर सक्सेस मैनेजर
इन तीनों तरीकों की तुलना अक्सर ऐसे की जाती है, मानो वे एक ही सवाल के अलग-अलग दावेदार जवाब हों। ऐसा नहीं है — वे अलग-अलग सवालों के जवाब देते हैं, और इनमें से सिर्फ़ एक उस सवाल का जवाब देता है, जो अटका हुआ यूज़र असल में पूछ रहा है।
· डॉक्यूमेंटेशन · चैट विजेट · कस्टमर सक्सेस मैनेजर
कहाँ रहता है · दूसरे टैब में · प्रोडक्ट के अंदर · प्रोडक्ट के अंदर
क्या जानता है · प्रोडक्ट, आम तौर पर · प्रोडक्ट, आम तौर पर · इस यूज़र की लाइव स्क्रीन
क्या देता है · टेक्स्ट, जिसका अनुवाद खुद करना पड़े · टेक्स्ट, जिसका अनुवाद खुद करना पड़े · पूरा हुआ वर्कफ़्लो
दूसरा वर्कफ़्लो संभालता है · ठीक से नहीं · कभी-कभी · हाँ
बिना पूछा सवाल भाँप लेता है · कभी नहीं · कभी नहीं · हाँ
सबसे अहम पंक्ति आखिरी वाली है। डॉक्यूमेंटेशन और चैट विजेट, दोनों रिएक्टिव हैं: उन्हें ऐसा यूज़र चाहिए जो जानता हो कि वह अटका है, पूछने को तैयार हो, और सवाल को शब्दों में ढाल सके। जो भी यूज़र चुपचाप हार मान लेता है, वह दोनों में से किसी को दिखता ही नहीं।
अपना प्रोडक्ट दोबारा बनाए बिना यह सब करना
इस मोड़ पर एक जायज़ आपत्ति यह है कि ऊपर का सब कुछ पूरे प्रोडक्ट को दोबारा लिखने जैसा लगता है। ऐसा नहीं है, और होना भी नहीं चाहिए — जिस गाइडेंस लेयर के लिए आपको अपना ऐप्लिकेशन नए सिरे से ढालना पड़े, उसे कोई नहीं अपनाएगा।
इंस्टॉल बस एक स्क्रिप्ट टैग है, उसी लेआउट में जिसे आप हर रूट पर पहले से रेंडर करते हैं:
<script async src="https://trybarkan.com/widget.js" data-barkan-site="site_your_key"></script>पूरा इंटीग्रेशन बस इतना ही है। न कोई कंपोनेंट रैपर, न रूट एनोटेशन, न टूर स्क्रिप्ट, जिन्हें हर बार UI बदलने पर लिखना और दोबारा रिकॉर्ड करना पड़े। विजेट अलग-थलग स्टाइल के साथ अपना रूट माउंट करता है, रेंडर हुआ इंटरफ़ेस पढ़ता है, और जवाब देना शुरू कर देता है।
1 स्क्रिप्ट टैग — इंस्टॉल करने के लिए, उसी लेआउट में जो आपके पास पहले से है
$1.50 — प्रति पूरी हुई ऑनबोर्डिंग; अधूरी छोड़ी गई ऑनबोर्डिंग मुफ़्त
$25 — शुरुआती क्रेडिट, कार्ड की ज़रूरत नहीं
वह वर्कफ़्लो चुनें, जिससे सबसे ज़्यादा “यह कैसे करें” वाले टिकट आते हैं — सबसे चमकदार नहीं, सबसे खिझाने वाला। वहीं आपके डॉक्यूमेंटेशन और इंटरफ़ेस के बीच का फ़ासला सबसे चौड़ा है, और वहीं गाइडेंस लेयर तिमाहियों में नहीं, दिनों में अपनी कीमत दिखा देती है।
वे मेट्रिक, जो सच में हिलते हैं
अगर आप इसे लगाते हैं और जानना चाहते हैं कि यह काम आया या नहीं, तो मुख्य मेट्रिक “जवाब दिए गए सवाल” नहीं है। वह आँकड़ा तुरंत बढ़ता है और उसका मतलब बहुत कम होता है। इसके बजाय इन पर नज़र रखें:
– पहले सार्थक ऐक्शन तक का समय। साइनअप से लॉगिन तक नहीं; साइनअप से उस काम तक, जिसके लिए आपका प्रोडक्ट बना है।
– दूसरे वर्कफ़्लो का कम्प्लीशन रेट। उन यूज़र्स का प्रतिशत, जो अपने पहले सफल वर्कफ़्लो के बाद कोई जटिल वर्कफ़्लो पूरा करते हैं। यही वह आँकड़ा है, जिसे डॉक्यूमेंटेशन कभी नहीं हिला पाता।
– “कैसे करें” टिकटों का हिस्सा। कुल टिकट नहीं — आपकी क्यू का वह हिस्सा जो “मैं यह कैसे करूँ” वाला है, बग और बिलिंग के मुकाबले। गाइडेंस लेयर से पहली श्रेणी सिमट जानी चाहिए, और बाकी जस की तस रहनी चाहिए।
– हर अकाउंट में फ़ीचर की खोज। कोई अकाउंट अपने पहले 30 दिनों में कितनी अलग-अलग क्षमताओं को छूता है। यही एक्सपैंशन का शुरुआती संकेत है।
अगर पहले तीन हिलते हैं और चौथा नहीं, तो आपने एक बेहतर हेल्प डेस्क बनाया है। चौथे का हिलना ही बताता है कि कस्टमर सक्सेस मैनेजर वाली आदत — नज़र रखना — असल में काम कर रही है।
---
डॉक्यूमेंटेशन कहीं नहीं जा रहा, और जाना भी नहीं चाहिए। यह रेफ़रेंस की लेयर है, और रेफ़रेंस की लेयर उन लोगों के लिए कीमती है जो उसे चाहते हैं: आपका API इंटीग्रेट करते डेवलपर, रोलआउट की योजना बनाते एडमिन, और कभी-कभार वह यूज़र, जिसे सच में पढ़ना ही पसंद है।
पर उस यूज़र के लिए, जो शाम 4 बजे आधे-अधूरे वर्कफ़्लो और सिर पर डेडलाइन के साथ अटका है, जवाब कभी बेहतर आर्टिकल नहीं था। जवाब था कोई ऐसा, जो प्रोडक्ट जानता हो, उसकी स्क्रीन देख सके, और उसे रास्ता दिखा दे — या काम ही कर दे।
एक स्क्रिप्ट टैग से अपने प्रोडक्ट में AI कस्टमर सक्सेस मैनेजर लाएँ। न कुछ दोबारा बनाना, न कार्ड की ज़रूरत।
“ज़्यादातर यूज़र्स एक और जवाब नहीं चाहते। वे चाहते हैं कि कोई रास्ता दिखा दे, या काम ही कर दे। पूरा प्रोडक्ट बस इतना ही है।”
Gabriel Lancelot
को-फ़ाउंडर, Barkan
