फीचर्स बेचना बंद करें, स्विच बेचें

सारांश

आपके क्लाइंट की SaaS वेबसाइट इसलिए असफल नहीं हो रही है क्योंकि वह खराब दिखती है। यह इसलिए असफल है क्योंकि यह उस एक सवाल का कभी जवाब नहीं देती जो सबसे अहम है: मुझे स्विच क्यों करना चाहिए? एजेंसी के काम के लिए, आप हर उत्पाद के लिए अनोखा अनुनय मॉडल नहीं बना सकते। इसके बजाय, किसी भी SaaS के लिए स्विचिंग ट्रिगर खोजने के लिए समान पाँच-प्रश्न ऑडिट का उपयोग करें। फिर उस ट्रिगर को हर पेज पर लागू करें: फीचर्स प्रमाण बनते हैं, प्राइसिंग स्पष्टता बनती है, FAQ आपत्तियों को कुचलता है, और API दस्तावेज़ डेवलपर की पहली जीत बनते हैं। यह ढाँचा एक बार के रीडिज़ाइन को दोहराने योग्य प्रक्रिया में बदल देता है। परिणाम: तेज़ डिलीवरी, कम संशोधन, और पेज जो वास्तव में कन्वर्ट करते हैं।

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

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

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

यह रहा ढाँचा: स्विच को परिभाषित करें। फिर हर पेज को उसके लिए तर्क देने के लिए मजबूर करें।

आपत्ति	यह वास्तव में किसकी रक्षा कर रहा है	इसके बजाय क्या करें
'हर क्लाइंट अलग है।'	टेम्पलेट्स का आपका डर	पाँच-प्रश्न ऑडिट के साथ स्विच ट्रिगर खोजें
'हमें और स्क्रीनशॉट चाहिए।'	खाली सेक्शनों का डर	उत्पाद शॉट्स को प्रमाण से बदलें
'प्राइसिंग पवित्र है।'	CFO की चिंता	स्टिकर शॉक कम करने के लिए स्पष्टता का उपयोग करें
'API दस्तावेज़ एक डेवलपर समस्या है।'	डेवलपर टीम की गेटकीपिंग	दस्तावेज़ों को एक प्रेरक माध्यम के रूप में देखें
'FAQ उबाऊ है।'	सपोर्ट का अभिभूत इनबॉक्स	अंतिम क्षण के संदेह दूर करने के लिए FAQ का उपयोग करें
'हमारे पास कस्टमाइज़ करने का समय नहीं है।'	डिलीवरी पर पूर्णतावाद	स्नोफ्लेक नहीं, एक कंकाल बनाएं

इस तालिका को पहली मीटिंग में एक चेकलिस्ट के रूप में उपयोग करें। इस पर कोई भी आपत्ति वास्तविक बाधा नहीं है। यह एक अलग ढाँचे के लिए अनुरोध है।

'हर क्लाइंट अलग है' सच है — और अप्रासंगिक

यह रहा बदलाव: उत्पाद अलग है, बाज़ार अलग है, खरीदार का व्यवहार नहीं है। खरीदार तीन चीज़ें चाहते हैं: 'क्या मैं इसे समझता हूँ?' 'क्या मैं इस पर भरोसा कर सकता हूँ?' 'क्या स्विच करना रुकने से सस्ता है?' यह सार्वभौमिक है। इसलिए डिज़ाइन को मानकीकृत न करें। पूछताछ को मानकीकृत करें।

पाँच-प्रश्न ऑडिट से शुरू करें। इसे पहली डिस्कवरी कॉल में चलाएँ। इसमें बीस मिनट लगते हैं और यह किसी भी SaaS के लिए काम करता है।

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

दो क्लाइंटों के उदाहरण देखें कि यह कैसे काम करता है।

पहला, एक प्रोजेक्ट मैनेजमेंट टूल। उपयोगकर्ता एक टीम लीड है, खरीदार भी टीम लीड है। यह मौजूदा टूल के समान ही काम करता है। दर्द? कोई नहीं जानता कि अगला कार्य किसका है। डर? सैकड़ों प्रोजेक्ट माइग्रेट करना और सारी स्थिति खो देना। तेज़ जीत? एक डैशबोर्ड जो एक नज़र में कार्य स्वामित्व दिखाता है। ट्रिगर: 'फिर कभी कार्य स्वामी का पीछा न करें।' यही हेडलाइन है।

दूसरा, एक रियल एस्टेट लीड ट्रैकर। उपयोगकर्ता एक एजेंट है, खरीदार एक ब्रोकर है। दर्द? डुप्लीकेट लीड तीन जगहों पर दिखाई देते हैं और अच्छे लीड ठंडे पड़ जाते हैं। डर? एजेंट डेटा लॉग नहीं करेंगे। तेज़ जीत? MLS लिस्टिंग से ऑटो-एनरिचमेंट ताकि एजेंट दो क्लिक में काम पूरा करें। ट्रिगर: 'लीड दोबारा कभी न खोएँ।'

वही पाँच प्रश्न। दो अलग-अलग उत्पाद। अब आपके पास होमपेज के लिए केंद्रीय संदेश, फीचर सेक्शन का पहला पैराग्राफ, और ईमेल अनुक्रम के लिए विषय पंक्ति है। स्विच ट्रिगर एक नवीकरणीय संसाधन है: हर पेज, हर सेक्शन, हर सबहेड इसके लिए तर्क दे सकता है। यह आपकी शुरुआती लाइन है।

वही ट्रिगर आपको साइट मैप भी देता है। ट्रिगर समझाने वाला पेज होमपेज है। ट्रिगर साबित करने वाला पेज फीचर सेक्शन है। डर दूर करने वाला पेज FAQ है। स्विच की लागत दिखाने वाला पेज प्राइसिंग पेज है। अचानक पूरी साइट में पेज-दर-पेज समिति के बजाय एक कथा होती है।

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

क्या होगा अगर उत्पाद दर्द-निवारक नहीं, बल्कि अच्छा-होना है? तब स्विच ट्रिगर बड़ा है: बचाया गया पैसा, टाला गया जोखिम, या प्राप्त स्थिति। एक अनुपालन टूल के लिए, ट्रिगर 'जुर्माने से बचें' है। एक सुरक्षा टूल के लिए, ट्रिगर 'ऑडिट पास करें' है। एक सोशल मीडिया शेड्यूलर के लिए, ट्रिगर 'हर हफ्ते दो घंटे वापस पाएँ' है। ऑडिट इसे अभी भी ढूँढ लेता है। कुछ ट्रिगर बस कम भावनात्मक होते हैं।

स्क्रीनशॉट पेज पर सबसे कम मूल्य वाले प्रमाण हैं

अपने क्लाइंट की फीचर तालिका में सबसे अकेली पंक्ति लें: 'OAuth 2.0 समर्थन।' यह कौन सी भावना ट्रिगर करती है? कोई नहीं। यह एक डेवलपर के लिए एक चेकलिस्ट आइटम है जो खरीदार नहीं है। फिर भी जब आप क्लाइंट से उनका फीचर पेज माँगते हैं, तो वे आपको इनकी दीवार सौंप देते हैं। पेज को स्क्रीनशॉट से भरना और आप कुछ और भी सामान्य कर रहे हैं: परिणाम के बजाय उत्पाद दिखाना।

स्क्रीनशॉट की अपनी जगह है। काम करते उत्पाद का एक अच्छा GIF सबूत है। लेकिन अधिकांश स्क्रीनशॉट उत्पाद के चित्र हैं। खरीदारों को पहले-और-बाद की कहानी चाहिए। इसे बताने के लिए फीचर सेक्शन सबसे अच्छी जगह है। फीचर-लाभ-प्रमाण (FBP) सूत्र का उपयोग करें। फीचर का नाम बताएं, इसे एक लाभ से जोड़ें, फिर इसे एक तथ्य, एक प्रक्रिया, या एक छोटे डेमो से साबित करें। कोई काल्पनिक संख्या नहीं — 'Google Workspace के साथ काम करता है' या 'एक मिनट से भी कम समय में सेटअप' जैसे देखने योग्य परिणामों का उपयोग करें।

क्लाइंट से मूल ब्लॉक:

• OAuth 2.0 समर्थन
• भूमिका-आधारित अभिगम नियंत्रण (RBAC)
• SCIM प्रावधान

विक्रेता शब्दजाल के तीन बुलेट। अब प्रत्येक को FBP से चलाएँ।

फीचर: OAuth 2.0 समर्थन।
लाभ: पूरी टीम के लिए एक लॉगिन। अब और आईटी टिकट नहीं।
प्रमाण: Google Workspace और Microsoft Entra के साथ काम करता है।

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

फीचर: SCIM प्रावधान।
लाभ: अपने HR सिस्टम से स्वचालित रूप से उपयोगकर्ताओं को जोड़ें और हटाएँ।
प्रमाण: Okta और Rippling के साथ सिंक होता है।

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

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

तकनीकी विशिष्टताओं को एक संक्षेपणीय अनुभाग या डेवलपर संसाधन टैब में रखें। उपयोगकर्ता लाभ देखता है; डेवलपर खोद सकता है। इससे पेज साफ रहता है और लेखापरीक्षक खुश रहता है।

किसी भी फीचर दावे के लिए एक अच्छा परीक्षण: क्या कोई खरीदार इसे अपने बॉस को दोहराएगा? 'एक लॉगिन' दोहराने योग्य है। 'OAuth 2.0 समर्थन' नहीं है। यदि आपके क्लाइंट का फीचर पेज वाटर-कूलर परीक्षण पास नहीं कर सकता है, तो यह अभी तक प्रेरक नहीं है।

प्राइसिंग पेज एक खदान हैं। यही कारण है कि आपको उन्हें छूना चाहिए

आप सुनेंगे, 'प्राइसिंग को मत छुओ। यह वर्षों से ऐसा ही है।' वे वास्तव में कह रहे हैं 'हम डरे हुए हैं।' भ्रमित करने वाला प्राइसिंग पेज राजस्व की रक्षा नहीं करता; यह इसे लीक करता है। आपका काम पेज को लागत वार्ता से स्पष्टता कथन में बदलना है।

अपनी बिक्री टीम हर हफ्ते जिन सवालों का जवाब देती है, उन्हें सूचीबद्ध करके शुरू करें। उन्हें शब्दशः लिखें। 'क्या आप प्रति उपयोगकर्ता शुल्क लेते हैं?' 'अगर मैं डाउनग्रेड करूँ तो क्या होगा?' 'क्या कोई सेटअप शुल्क है?' 'क्या मैं बिना क्रेडिट कार्ड के इसे आज़मा सकता हूँ?' 'आपकी रिफंड नीति क्या है?' उन्हें पेज पर रखें। एक खरीदार को यह जानने के लिए कॉल बुक नहीं करनी चाहिए कि क्या आपको परीक्षण के लिए क्रेडिट कार्ड की आवश्यकता है।

अगला, क्लाइंट की तीन योजनाएँ लें: बेसिक, प्रो, एंटरप्राइज़। ग्राहक की स्थिति के अनुसार उनका नाम बदलें। प्रत्येक योजना वास्तव में किसी के लिए क्या करती है? सोलो, टीम, संगठन। या निर्माता, स्टूडियो, एंटरप्राइज़। नाम सजावट नहीं है; यह स्पष्टता का पहला क्षण है।

पुरानी योजना	नई योजना	वादा
बेसिक	सोलो	एक व्यक्ति के लिए जिसे सरल वर्कफ़्लो चाहिए
प्रो	टीम	एक टीम के लिए जिसे सहयोग और डैशबोर्ड चाहिए
एंटरप्राइज़	संगठन	एक कंपनी के लिए जिसे सुरक्षा, SSO और समर्थन चाहिए

फिर तुलना तालिका बनाएँ। हर पंक्ति में हर फीचर डालने के पैटर्न को तोड़ें। प्रत्येक पंक्ति की शुरुआत उस उपयोगकर्ता प्रश्न से करें जिसका वह उत्तर देती है। 'कितने उपयोगकर्ता?' 'हम किसे आमंत्रित कर सकते हैं?' 'हमें कौन सी सुरक्षा सुविधाएँ मिलती हैं?' खरीदार 'क्या मैं फिट हूँ' खोजने के लिए तालिका पढ़ता है। उस खोज को आसान बनाएँ।

अंत में, एक प्राइसिंग FAQ जोड़ें। बदसूरत सवाल का जवाब दें: 'अगर मैं जाता हूँ तो मेरे डेटा का क्या होगा?' उत्तर को इंसान की तरह लिखें: 'अपनी सदस्यता समाप्त होने से पहले एक क्लिक में सब कुछ निर्यात करें। कोई शुल्क नहीं, कोई बंधन नहीं।' यह स्विच-ट्रस्ट तोड़ने वाला है। अधिकांश क्लाइंट इसे नहीं लिखेंगे क्योंकि यह छोड़ने का निमंत्रण जैसा लगता है। ऐसा नहीं है। यह बिना डर के खरीदने की अनुमति है।

आपकी एजेंसी के पास यहाँ एक अंतर्निहित लाभ है: आप पहले ही पाँच-प्रश्न ऑडिट पूछ चुके हैं, इसलिए आप डर जानते हैं। डर को FAQ में डालें। यदि आपको शुरू करने के लिए एक टेम्पलेट की आवश्यकता है, तो प्राइसिंग पेज कन्वर्ज़न गाइड ही टेम्पलेट है।

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

जब आप प्राइसिंग FAQ लिखते हैं, तो विक्रेता भाषा का उपयोग न करें। 'आप' और 'आपका डेटा' कहें। एक प्राइसिंग पेज जो हर समय 'हम पेशकश करते हैं, हम प्रदान करते हैं' का उपयोग करता है, वह कंपनी ब्रोशर जैसा लगता है। इसे 'आप कर सकते हैं, आपकी टीम' में बदलें। व्याकरण में स्विच हो रहा है।

आप प्राइसिंग FAQ का परीक्षण उसी तरह कर सकते हैं जैसे आप किसी और चीज़ का करते हैं: इसे ज़ोर से पढ़ें। यदि डेस्क के दूसरी ओर एक अजनबी आराम करेगा, तो यह अच्छा है। यदि वे बिक्रीकर्मी के लिए हाथ उठाएँगे, तो आपने घर्षण जोड़ा है।

जिन दस्तावेज़ों को आप अनदेखा करते हैं वे डील बंद कर रहे हैं (या मार रहे हैं)

यह रहा एक डेवलपर लैपटॉप पर। वह आपके क्लाइंट के API का मूल्यांकन कर रही है। उसके बॉस ने पूछा, 'क्या हम इसके साथ एकीकृत कर सकते हैं?' वह एक चीज़ चाहती है: सबूत कि उसकी टीम एक हफ्ता बर्बाद नहीं करेगी। वह संदर्भ दस्तावेज़ों से शुरू नहीं करती। वह क्विक स्टार्ट से शुरू करती है।

Stripe, GitHub और Twilio जैसी कंपनियाँ API दस्तावेज़ों के लिए मानक स्थापित करती हैं। रहस्य यह नहीं है कि वे हर एंडपॉइंट को खूबसूरती से दस्तावेज़ित करते हैं। यह है कि वे पहली बार चलाने में पाँच मिनट लगाते हैं। वे एक छोटा परिणाम दिखाते हैं जो सफलता जैसा दिखता है। यह डेवलपर के लिए स्विच ट्रिगर है: तत्काल, ठोस प्रगति।

आपके क्लाइंट के API दस्तावेज़ पहला पेज हैं जो होमपेज के बाद एक तकनीकी खरीदार पढ़ता है। यदि यह एक टेलीफोन बुक की तरह पढ़ता है, तो डील चुपचाप मर जाती है। दस्तावेज़ एक विपणन संपत्ति हैं, तकनीकी काम नहीं। इसलिए ऐसा करें:

क्विक स्टार्ट को बाकी सब से पहले रखें। उदाहरण का समय। आपका क्लाइंट एक दस्तावेज़ स्वचालन API बनाता है। संदर्भ एक सघन विषय-सूची है जो हजारों पंक्तियों तक जाती है। एक डेवलपर आता है, 'प्रमाणीकरण' देखता है, और हतोत्साहित हो जाता है।

1. सादे अंग्रेज़ी में तीन-वाक्य का विवरण लिखें। 'एक अनुबंध भेजें, एक निष्पादित प्रति वापस पाएँ। यह API टेम्पलेट्स और डेटा को हस्ताक्षरित PDF में बदल देता है।'
2. एक कॉपी-पेस्ट कोड नमूना चिपकाएँ जो सैंडबॉक्स एंडपॉइंट कॉल करता है। सफलता साबित करने वाला पहला प्रतिक्रिया JSON दिखाएँ।
3. एक उपयोग-मामला जोड़ें, 'इनवॉइस जो स्वयं-असेंबल होते हैं,' और इसमें शामिल विशिष्ट एंडपॉइंट्स से लिंक करें।

पूरे संदर्भ को नीचे ले जाएँ। पहला स्निपेट कॉपी करने वाला डेवलपर एक आंतरिक चैंपियन बन जाता है। चैंपियन सुरक्षा समीक्षा का अनुरोध करता है, अस्वीकृति नहीं। आपका क्लाइंट बिक्री कॉल से पहले ही उतर जाता है। API दस्तावेज़ गाइड उसी प्रक्रिया से गुजरता है।

एक उपयोग-मामला मार्ग के साथ एक वादा है। दस्तावेज़ स्वचालन क्लाइंट के लिए, लिखें 'इनवॉइस जो स्वयं-असेंबल होते हैं: एक PO नंबर भेजें और एक कॉल में स्वरूपित इनवॉइस, लाइन आइटम और एक PDF वापस पाएँ।' यह एक दस्तावेज़ पेज नहीं है; यह एक बिक्री पेज है जिसमें संयोग से कोड होता है।

सैंडबॉक्स के लिए एक एम्बेडेड API कुंजी शामिल करें। जिस क्षण एक डेवलपर पेस्ट करके सफलता देख सकता है, स्विच वास्तविक हो जाता है। किसी बिक्री कॉल की आवश्यकता नहीं।

दस्तावेज़ पेज SEO को भी फ़ीड करता है। डेवलपर सटीक त्रुटि संदेशों और एकीकरण नामों की खोज करते हैं। उन प्रश्नों के लिए पेज लिखें: प्रत्येक त्रुटि कोड के लिए एक पैराग्राफ, प्रत्येक एकीकरण के लिए एक पेज। इस तरह दस्तावेज़ एक चैनल बन जाते हैं।

'अभी आज़माएँ' बटन के साथ एक स्थायी साइडबार का उपयोग करें। एक खोज बार जोड़ें जो कोड उदाहरणों को अनुक्रमित करता है। खोज जितनी सहज होगी, कंपनी उतनी ही सक्षम दिखेगी। और 90 सेकंड से कम का एक छोटा वीडियो न भूलें जो एक काम करने वाला उदाहरण दिखाता है, कंपनी अवलोकन नहीं।

FAQ समर्थन सामग्री नहीं है। यह अंतिम बाधा रूपांतरण है

'कोई FAQ नहीं पढ़ता' — यह वही है जो आप सुनेंगे जब तक आपको याद नहीं आता कि कौन पढ़ता है: एक शांत कमरे में एक खरीदार, सवाल पूछने में झिझक रहा है। FAQ वह पेज है जहाँ डील निजी तौर पर बंद होती हैं। इसे ऐसे ही मानें।

HubSpot, Slack और Zendesk इसे सही करते हैं। उनके FAQ और सहायता अनुभाग संगठित, खोज योग्य और संक्षिप्त हैं। वह संरचना ही बात है। यह क्षमता का संकेत देती है। एक खोज योग्य FAQ खरीदार को सोचने पर मजबूर करता है: इन लोगों ने मेरी समस्या के बारे में सोचा है।

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

चलिए स्विचिंग बाल्टी करते हैं। 'माइग्रेशन कितना कठिन है?' का वर्तमान उत्तर कहता है: 'हमारा आयात टूल CSV और API का समर्थन करता है।' यह एक फीचर सूची है। इसे एक वादा और एक चरण सूची के रूप में फिर से लिखें:

'हम आपके लिए आपका डेटा आयात करेंगे। एक CSV भेजें, हम एक ड्राई रन चलाते हैं, आप एक नमूना सत्यापित करते हैं, और हम 30 मिनट की अवधि में कटओवर करते हैं। अगर कुछ गलत लगता है, तो हम तुरंत रोलबैक करते हैं।'

अब दोनों उत्तरों की तुलना करें। कौन सा डील बंद करता है? पहला एक तंत्र का वर्णन करता है; दूसरा एक सुरक्षित प्रक्रिया का वर्णन करता है। यह फीचर पेज के समान संरचना है: लाभ और प्रमाण।

और आगे बढ़ें: हर सवाल को खींचें जिसका सपोर्ट सप्ताह में दो बार जवाब देता है और टिकट होने से पहले उत्तर लिखें। यह लैंडिंग सामग्री का एक कभी न समाप्त होने वाला स्रोत है। एक बार जब FAQ डंपिंग ग्राउंड नहीं रह जाता है और अनुनय उपकरण बन जाता है, तो पूरी कहानी एकीकृत रहती है। यह इनसाइड-आउट दृष्टिकोण का हिस्सा है जिसे आप बाकी सब के लिए उपयोग करते हैं।

खोज को ध्यान में रखकर व्यवस्थित करें। एक खोज योग्य FAQ जो एक कीस्ट्रोक में उत्तर ढूँढता है, एक उत्पाद सुविधा जैसा लगता है। यह ठीक वही क्षमता संकेत है जो आप चाहते हैं।

खरीदारों को एक अलग सहायता केंद्र न खोलने दें। FAQ को उस पेज पर रखें जिसने प्रश्न ट्रिगर किया। यदि मूल्य निर्धारण प्रश्न प्राइसिंग पेज पर दिखाई देता है, तो वहीं उत्तर दें। यदि सुरक्षा प्रश्न प्राइसिंग पेज पर दिखाई देता है, तो वहीं भी उत्तर दें। उत्तर संदेह के बिंदु पर होता है।

सुरक्षा बाल्टी वह जगह है जहाँ IT टूल को ब्लॉक करने का निर्णय लेता है। 'डेटा कहाँ संग्रहीत है?' जैसे प्रश्नों का विशिष्ट उत्तर दें। यदि आप 'EU में' कहते हैं, तो क्षेत्र बताएं। यदि आप 'आराम से एन्क्रिप्टेड' कहते हैं, तो मानक का नाम बताएं। एक संक्षिप्त उत्तर एक श्वेतपत्र लिंक से अधिक मजबूत है।

प्रत्येक FAQ उत्तर यथासंभव छोटा होना चाहिए और अगले चरण के साथ समाप्त होना चाहिए: 'सैंडबॉक्स खाते के साथ साइन अप करें' या 'समर्थन से बात करें।' अगले चरण के बिना उत्तर एक मृत अंत है।

समय नहीं? एक कंकाल बनाएं, स्नोफ्लेक नहीं

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

स्विच मेमो — एक पेज, छह पंक्तियाँ:

1. उपयोगकर्ता / खरीदार विभाजन: कौन आता है, कौन भुगतान करता है।
2. वर्तमान व्यवहार: वे आज इसके बजाय क्या करते हैं।
3. एकमात्र दर्द: एक वाक्य, झुंझलाहट।
4. डर: उन्हें चिंता है कि स्विच में क्या टूटेगा।
5. तेज़ जीत: स्विच करने के बाद पहला दृश्य सुधार।
6. प्रमाण: लोगो, परिणाम, या सुरक्षा स्थिति जो डर को दूर करते हैं।

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

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

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

क्लाइंट की अपेक्षाओं को जल्दी निर्धारित करने के लिए मेमो का उपयोग करें। संस्थापक देखता है कि साइट एक कला परियोजना नहीं है; यह एक अनुनय दस्तावेज़ है। यह 'बस इसे पॉप बनाओ' फीडबैक को रोकता है और बातचीत को परिणामों की ओर मोड़ता है। मेमो को क्लाइंट की इन-हाउस मार्केटिंग टीम के साथ साझा करें ताकि वे संदेश का पुनर्निर्माण किए बिना बाद में नए पेज लिख सकें।

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

स्विच ही रणनीति है। बाकी सब सजावट है।

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

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

एक स्विच-फ्रेम वाली साइट समय के साथ बेहतर भी होती जाती है। अब आपके पास एक परिकल्पना है — ट्रिगर — और आप इसे हीटमैप, सत्र रिकॉर्डिंग या A/B परीक्षणों में परीक्षण कर सकते हैं। ढाँचा रीडिज़ाइन को एक घटना से एक प्रयोग में बदल देता है।

आपको 40-पृष्ठ रणनीति डेक की आवश्यकता नहीं है। आपको छह पंक्तियों और उन पेजों को ना कहने की इच्छा की आवश्यकता है जो स्विच की सेवा नहीं करते हैं। यह स्पष्टता ही है जिसके लिए ग्राहक आपको भुगतान कर रहे हैं।

फीचर्स बेचना बंद करें। स्विच बेचें। यही पूरी रणनीति है।