जब आपकी AI से बनी app को अपनी खुद की support टीम चाहिए (और इसके बजाय क्या करें)

आपने अपनी app एक weekend में Proyecta से बना डाली। यह चल रही है। लोग सचमुच इसके पैसे दे रहे हैं। और अब आप support emails में दबे हुए हैं।

यही वो मोड़ है जहां बहुत से indie builders सोचते हैं, “मुझे customer support के लिए किसी को hire करना चाहिए।” आख़िरकार यह सही हो सकता है। पर आमतौर पर तीन-चार चालें ऐसी होती हैं जो आप पहले चल सकते हैं, जो कहीं सस्ती और अक्सर बेहतर होती हैं।

“मैं इन सारी emails का जवाब नहीं दे पा रहा” के तीन दौर

दौर 1: आप अब भी हर email का जवाब दे रहे हैं, पर इसमें दिन के छह घंटे लग रहे हैं। आप थक चुके हैं।

दौर 2: आप सबसे ज़रूरी वालों का जवाब दे रहे हैं। कुछ लोग जवाब के लिए तीन दिन इंतज़ार करते हैं। आपको बुरा लगता है, पर साथ ही आप features भी शिप कर रहे हैं।

दौर 3: आपके inbox में 50 emails का बैकलॉग है और आपने उसे खोलना ही बंद कर दिया है। अपराधबोध घर कर जाता है।

ज़्यादातर builders बीच के रास्ते को टटोले बिना सीधे दौर 2 से “चलो एक support वाला इंसान hire कर लें” पर कूद जाते हैं।

सस्ती चालें (जो सचमुच काम करती हैं)

1. वो तीन सवाल ढूंढें जिनका आप सबसे ज़्यादा जवाब देते हैं

एक हफ़्ता हर email पढ़ने में लगाइए। वो सवाल लिख लीजिए जो एक से ज़्यादा बार आते हैं। मेरा दांव है कि आपको कुछ ऐसा मिलेगा:

• “मैं इसे Stripe से कैसे जोड़ूं?”
• “क्या मैं इसे अपनी टीम के लिए इस्तेमाल कर सकता हूं?”
• “अगर आप बंद हो गए तो क्या होगा?”

अपने top तीन लीजिए और उनका जवाब किसी पक्की जगह पर दीजिए — email में नहीं। अपनी website पर एक FAQ page। एक video। app में एक help doc। मकसद है सवाल को आपके inbox तक पहुंचने से पहले ही रोक लेना।

आपको किसी फ़ैंसी documentation software की ज़रूरत नहीं। साफ़ headers वाला एक Google Doc चल जाता है। या आपकी website पर एक आसान सा page। कसौटी यह है: कोई search करके इसे ढूंढ ले, उसका जवाब मिल जाए, और वो आपको email न करे।

ज़्यादातर indie builders इसे छोड़ देते हैं क्योंकि यह एक सुलझा हुआ मसला लगता है। FAQ तो सबके पास होती है। पर ज़्यादातर FAQs तब लिखी जाती हैं जब founder भूल चुका होता है कि उसे ख़ुद किस चीज़ ने उलझाया था। आप तो इसे तब लिख रहे हैं जब आप उन्हीं तीन सवालों से सक्रिय रूप से चिढ़े हुए हैं। अभी लिख डालिए।

2. एक आसान autoresponder इस्तेमाल करें

जब कोई email करता है, तो असल में वो छह दिन का इंतज़ार नहीं कर रहा होता। वो यह जानने का इंतज़ार कर रहा होता है कि आप कब जवाब देंगे।

एक autoresponder सेट कर लीजिए (Gmail में यह पहले से है, या Mailchimp, Zapier, कुछ भी इस्तेमाल कर लें) जो कुछ ऐसा कहे जो सच हो:

“मैं हर email पढ़ता हूं। आमतौर पर मैं 48 घंटों के भीतर जवाब दे पाता हूं। अगर यह ज़रूरी है, तो subject line में URGENT लिखकर जवाब दें और मैं उसे प्राथमिकता दूंगा।”

यह दो काम करता है:

• यह उन्हें भरोसा दिलाता है कि आप उन्हें नज़रअंदाज़ नहीं कर रहे।
• यह आपको panic में जवाब देने के बजाय सोचने का वक़्त देता है।

URGENT वाला संकेत आपको झटपट triage करने देता है। कुछ लोग इसका दुरुपयोग करेंगे, पर ज़्यादातर नहीं करेंगे — वो बस बेचैन होते हैं, और यह जान लेना कि आप उन्हें कब जवाब देंगे, इसी को दूर कर देता है।

3. एक public status page बनाएं (भले ही वो बस एक tweet हो)

अगर कुछ ख़राब है, तो users आपका status देखने से पहले इसके बारे में आपको email कर देंगे।

एक आसान सा page बनाइए (Statuspage.io 29 डॉलर/महीना है, पर एक GitHub gist या Slack status भी चल जाता है) जो कहे:

• “सभी systems चल रहे हैं”
• या, अगर कुछ बंद है: “Dashboard अभी धीमा है (जांच रहे हैं)”

इसे अपने footer या email signature में लिंक कीजिए। जब आपको “क्या आपकी चीज़ ख़राब है?” वाली email मिले, तो जवाब लिखने के बजाय आप एक लिंक के साथ जवाब देते हैं: “हमारा status page देखिए।”

यह छोटा सा लगता है। पर अगर आपकी app के 100 users हैं और कुछ ख़राब है, तो status page आपको उसी एक समस्या के बारे में 15+ emails लिखने से बचा लेता है।

4. एक “Changelog पहले” वाली आदत बनाएं

जब भी आप कोई bug ठीक करें या कोई feature शिप करें, अपने users को इसके बारे में बताएं इससे पहले कि उनका ध्यान जाए। यह support emails की एक पूरी श्रेणी को रोक देता है।

एक 60-सेकंड का video रिकॉर्ड करने के लिए Loom इस्तेमाल करें, उसे किसी “what’s new” Slack या Discord में पोस्ट करें (अगर आपके पास हो), या active users को एक email के रूप में भेजें। मकसद फ़ैंसी होना नहीं है — मकसद तेज़ और ईमानदार होना है।

“वो bug ठीक कर दिया जहां imports कभी-कभी अटक जाते थे। उसके लिए माफ़ी। साथ ही इस हफ़्ते dark mode भी जोड़ा।”

यह दो काम करता है:

• यह users को बताता है कि क्या बदला, ताकि वो उलझें नहीं।
• इससे उन्हें लगता है कि आप product पर सक्रिय रूप से काम कर रहे हैं।

जब आपको सचमुच मदद चाहिए होती है

अगर इन चार चालों के बाद भी आप डूब रहे हैं, तो हां, शायद आपको एक इंसान की ज़रूरत है।

उस वक़्त, किसी को part-time hire कीजिए ताकि वो:

• आम सवालों के जवाब दे (आपकी FAQ और templates इस्तेमाल करके)।
• मुश्किल वालों को संक्षेप में लिखकर आपके पास फ़ैसलों के लिए भेजे।
• क्या उलझाने वाला है, इसमें पैटर्न पकड़े और आपको बताए कि किसके लिए बेहतर docs चाहिए।

दूसरा हिस्सा सबसे अहम है: एक support वाला इंसान सिर्फ़ email का जवाब देने वाला रोबोट नहीं है। वो आपका early warning system है — कि आपके product, आपकी pricing, या आपके docs में क्या ख़राब है।

पर ज़्यादातर indie apps एक अरसे तक वहां तक नहीं पहुंचतीं। तब तक, वो चार चालें आपको “मैं डूब रहा हूं” से “मैं संभाल रहा हूं” तक ले जा सकती हैं।

मूल बात: support एक product feature है, कोई admin वाला काम नहीं। product को साफ़ बनाने में निवेश कीजिए, उसे समझाने के लिए लोग hire करने में नहीं। एक अच्छी FAQ 50% emails का जवाब दे देती है। एक अच्छी onboarding और 30% को रोक देती है। बचते हैं वो 20% जिनमें सचमुच इंसानी सोच की ज़रूरत होती है।

यह एक सुलझने वाली समस्या है। अभी किसी को hire करने की ज़रूरत नहीं।