एक स्टोर प्लेटफ़ॉर्म चुनें जिसका आप बचाव कर सकें

सारांश

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

आपको अभी एक नया स्टोर प्रोजेक्ट मिला है। ग्राहक पूछता है, 'आप किस प्लेटफ़ॉर्म की अनुशंसा करते हैं?' आप वास्तव में क्या कहते हैं?

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

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

ऐसा करने का सबसे तेज़ तरीका उन मान्यताओं पर हमला करना है जो अधिकांश टीमें रखती हैं। ये हैं मिथक, और वास्तविकता।

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

'एक सर्वश्रेष्ठ प्लेटफ़ॉर्म है' एक आरामदायक झूठ है

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

इसके बजाय यह करें। ग्राहक से मिलने से पहले स्टोर के तीन स्तर परिभाषित करें।

स्तर एक: सरल स्टोर। कुछ दर्जन उत्पाद, स्थानीय डिलीवरी, कोई सदस्यता नहीं, छोटी टीम। इन ग्राहकों को कम लागत, तेज़ सेटअप और भुगतान प्रसंस्करण की आवश्यकता होती है जो तुरंत काम करता है। इस श्रेणी में शुरुआती-अनुकूल होस्टेड विकल्प जैसे Square Online और Ecwid शामिल हैं, जिन्हें अक्सर तकनीकी अनुभव के बिना उद्यमियों के लिए उत्कृष्ट शुरुआती बिंदु के रूप में वर्णित किया जाता है।

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

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

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

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

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

'ग्राहक को चुनने दें' एक शॉर्टकट है जो बाद में आपको महंगा पड़ता है

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

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

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

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

'सबसे कम मासिक शुल्क' सबसे सस्ता स्टोर नहीं है

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

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

शुल्क पृष्ठ को अनुबंध की तरह पढ़ें। पूछें कि रिफंड के साथ क्या होता है। चार्जबैक के बारे में पूछें। पूछें कि क्या ग्राहक अन्य देशों से ग्राहकों को स्वीकार कर सकता है, और मुद्रा रूपांतरण कैसा दिखता है। एक गेटवे जो घरेलू बिक्री के लिए सस्ता है, अंतर्राष्ट्रीय बिक्री के लिए विनाशकारी हो सकता है।

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

'भुगतान एक आफ्टरथॉट है' स्टोर का गला घोंट देगा

सिद्धांत: भुगतान गेटवे एक व्यावसायिक निर्णय है, तकनीकी विवरण नहीं। यह निर्धारित करता है कि ग्राहक को भुगतान कब मिलता है, वे किन ग्राहकों को स्वीकार कर सकते हैं, और हर बिक्री का कितना हिस्सा वे रखते हैं।

निर्णय को प्लेटफ़ॉर्म और ग्राहक की वास्तविकता से जुड़ा रखें। गेटवे को व्यवसाय से मिलाएँ:

• यदि ग्राहक व्यक्तिगत रूप से और ऑनलाइन बेचता है, तो एक एकीकृत प्रणाली देखें जो इन्वेंट्री और भुगतान को एक स्थान पर रखती है। शोध Square को एक शुरुआती-अनुकूल विकल्प के रूप में उजागर करता है जो ई-कॉमर्स सुविधाओं को भुगतान प्रसंस्करण के साथ जोड़ता है।
• यदि ग्राहक अंतर्राष्ट्रीय रूप से बढ़ने या सदस्यताएँ शुरू करने की योजना बनाता है, तो एक मजबूत API वाला डेवलपर-अनुकूल प्रोसेसर बेहतर फिट बैठता है। Stripe वैश्विक भुगतान और सदस्यता समर्थन के लिए व्यापक रूप से मान्यता प्राप्त है।
• यदि ग्राहक के पास ऐसे स्थानों पर खरीदार हैं जहाँ कार्ड कम आम हैं, तो विश्वास और पहुंच के लिए PayPal जैसा व्यापक रूप से मान्यता प्राप्त ई-वॉलेट जोड़ें।

इस निर्णय को डेवलपर की व्यक्तिगत पसंद पर न छोड़ें। एक डेवलपर सबसे अच्छे API वाले प्रोसेसर को पसंद कर सकता है; ग्राहक को सबसे तेज़ जमा गति वाले की आवश्यकता हो सकती है। दोनों विकल्पों को मेज पर रखें और समझौते को स्पष्ट करें।

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

'लॉन्च समाप्ति रेखा है' ऐसे ही स्टोर मरते हैं

सिद्धांत: माप योजना के बिना लॉन्च करना स्टोर को अंधेरे में फेंकने के समान है। स्टोर का काम लॉन्च के बाद शुरू होता है।

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

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

ऑनलाइन व्यवसाय शुरू करने पर शोध उसी सलाह पर लौटता रहता है: छोटा शुरू करें, परीक्षण करें, मापें और परिष्कृत करें। पहले महीने में एक बड़े पुनः डिज़ाइन किए गए स्टोर की योजना न बनाएं। प्रति सप्ताह एक छोटा सुधार की योजना बनाएं। यह ताल स्टोर को जीवित रहने के लिए आवश्यक फीडबैक लूप बनाता है।

'सब कुछ मानकीकृत करें' जाल है

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

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

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

एक प्लेटफ़ॉर्म हर ग्राहक के लिए उपयुक्त नहीं होगा। जो टीम इसे स्वीकार करती है — और एक-आकार-सभी-फिट नियम के बजाय एक स्तरित प्रक्रिया बनाती है — वह दोहराव में जीतती है क्योंकि वह वास्तविकता से लड़ना बंद कर देती है।

इस सप्ताह अपना ढांचा बनाएँ

अब आपके पास प्रत्येक मिथक के लिए सुधार है। इसे कार्रवाई में बदलें।

अपनी खोज प्रश्नावली लिखें। इसे प्रिंट करें। अगली ग्राहक कॉल पर इसका उपयोग करें।

अपने प्लेटफ़ॉर्म स्तरों को परिभाषित करें। प्रत्येक स्तर के लिए एक पैराग्राफ लिखें, जिसमें यह बताया जाए कि यह किस प्रकार के ग्राहक के लिए उपयुक्त है और यह किस समझौते को स्वीकार करता है।

अपना एक-पृष्ठ अनुशंसा टेम्पलेट बनाएँ। अगले प्लेटफ़ॉर्म प्रस्ताव के लिए इसका उपयोग करें।

भुगतान गेटवे के लिए एक नियम निर्धारित करें। गेटवे को ग्राहक की भुगतान वास्तविकता से मिलाएँ, न कि अपनी API पसंद से।

लॉन्च-पश्चात अनुसूची चुनें। नब्बे दिनों के लिए प्रति सप्ताह एक सुधार के लिए प्रतिबद्ध हों।

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