हर ग्राहक के स्टोर को दोबारा बनाना बंद करें: एक दोहराने योग्य ऑनबोर्डिंग सिस्टम

सारांश

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

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

1. इंटेक को चैट के बजाय गेट के रूप में चलाएं

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

किसी भी टूल को छूने से पहले एक-पेज का ब्रीफ भेजें। इन सवालों को अनिवार्य बनाएं:

• पहले 90 दिनों में आप कितने SKU बेचने की योजना बना रहे हैं?
• भौतिक, डिजिटल, या मिश्रित?
• ऑर्डर कौन पूरा करता है — आप, एक सप्लायर, या कोई तीसरा पक्ष?
• औसत ऑर्डर मूल्य क्या है?
• क्या आप राज्य या देश की सीमाओं के पार बेचते हैं? आपके पास टैक्स उपस्थिति कहाँ है?
• क्या आप सब्सक्रिप्शन, प्री-ऑर्डर, या मल्टी-आइटम बंडल पेश करेंगे?
• पहले महीने में इस स्टोर में कौन सी एक विशेषता होनी चाहिए?

क्लाइंट से कॉल पर बताने के बजाय जवाब टाइप करवाएं। टाइप किए गए जवाब एक रिकॉर्ड बन जाते हैं। मौखिक जवाब छठे सप्ताह में 'मैंने ऐसा कभी नहीं कहा' बन जाते हैं।

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

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

2. क्लाइंट प्रोफ़ाइल के आधार पर प्लेटफ़ॉर्म मैट्रिक्स बनाएं, आदत से नहीं

यह पैटर्न बार-बार टूटता है: आप हर नए स्टोर के लिए वही होस्टेड ड्रैग-एंड-ड्रॉप बिल्डर खोलते हैं क्योंकि यह तेज़ है। फिर एक भौतिक स्टोर वाले क्लाइंट को इन्वेंट्री को कैश रजिस्टर से सिंक करने की आवश्यकता होती है। आपका पसंदीदा बिल्डर तीन पेड ऐप्स के बिना ऐसा नहीं कर सकता। आप तीसरे सप्ताह में प्लेटफ़ॉर्म बदलते हैं और सभी का समय बर्बाद होता है।

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

क्लाइंट प्रोफ़ाइल	प्लेटफ़ॉर्म श्रेणी	कब जीतता है
कम SKU संख्या, तेज़ लॉन्च, गैर-तकनीकी मालिक	होस्टेड ड्रैग-एंड-ड्रॉप बिल्डर	गति, ऐप इकोसिस्टम, बिल्ट-इन होस्टिंग
मौजूदा कंटेंट साइट, डिज़ाइन नियंत्रण मायने रखता है	वर्तमान CMS के लिए ओपन-सोर्स स्टोर प्लगइन	साइट बनाए रखें, कॉमर्स जोड़ें
उच्च SKU संख्या, जटिल कैटलॉग, विकास योजनाएँ	मजबूत API के साथ स्केलेबल होस्टेड प्लेटफ़ॉर्म	कस्टम इंटीग्रेशन, मल्टी-चैनल
भौतिक स्टोर के साथ ऑनलाइन स्टोर	POS-एकीकृत बिल्डर	चैनलों में इन्वेंट्री सिंक
सीमित बजट, कुछ उत्पाद	हल्का एम्बेडेड स्टोरफ्रंट	कम मासिक लागत, सरल चेकआउट

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

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

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

3. भुगतान स्टैक को परिचित के बजाय नकदी प्रवाह के आधार पर डिफ़ॉल्ट करें

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

1. पूछें कि क्लाइंट का नकदी चक्र क्या है। साप्ताहिक या दैनिक जमा? कुछ प्रोसेसर तेज़ी से निपटान करते हैं, और कुछ निश्चित व्यावसायिक प्रकारों के लिए धन लंबे समय तक रोकते हैं।
2. आपके द्वारा चुनी गई प्लेटफ़ॉर्म श्रेणी के साथ गेटवे के एकीकरण की जाँच करें। यदि ब्रीफ में आवश्यकता हो तो क्या यह सब्सक्रिप्शन का समर्थन करता है? क्या यह आपके ब्रीफ में देशों का समर्थन करता है?
3. निर्माण से पहले प्रोसेसर की प्रतिबंधित सूची के विरुद्ध क्लाइंट की उत्पाद श्रेणी की जाँच करें। उच्च-जोखिम वाली श्रेणियों को चेतावनी ईमेल नहीं, बल्कि फ्रोज़न खाते मिलते हैं।
4. यदि क्लाइंट के पास पहले से कोई भुगतान विधि है जिस पर उनके ग्राहक भरोसा करते हैं — उदाहरण के लिए, एक व्यापक रूप से मान्यता प्राप्त वॉलेट — तो इसे शामिल करें भले ही यह शुल्क जोड़ता हो। भरोसा शुल्क अंतर से बेहतर कन्वर्ट करता है।
5. दस्तावेज़ीकरण करें कि क्लाइंट ने किस गेटवे, किस खाते, और किस भुगतान अनुसूची को मंजूरी दी है। इसे दिनांक के साथ प्रोजेक्ट फ़ाइल में रखें।

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

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

4. डिज़ाइन से पहले अनुपालन जाँच चलाएं

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

अनुपालन एक लॉन्च गेट है, प्रशासन नहीं। किसी भी डिज़ाइन कार्य से पहले, पुष्टि करें:

• व्यवसाय पंजीकरण क्लाइंट की वास्तविक इकाई से मेल खाता है।
• क्लाइंट के पास हर राज्य के लिए सेल्स टैक्स पंजीकरण मौजूद है जहाँ उसका nexus है।
• उत्पाद श्रेणी उस भुगतान प्रोसेसर द्वारा अनुमत है जिसे आप कनेक्ट करने वाले हैं।
• क्लाइंट के पास उत्पाद प्रकार के लिए आवश्यक लाइसेंस या परमिट हैं।
• सेवा की शर्तें, गोपनीयता नीति, रिफंड नीति, और शिपिंग नीति लिखित हैं और स्टोर वास्तव में जो करता है उससे मेल खाती हैं।

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

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

5. उत्पाद डेटा कॉन्ट्रैक्ट को मानकीकृत करें

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

उत्पाद डेटा को जिस भी आकार में आता है स्वीकार करना बंद करें। एक उत्पाद डेटा कॉन्ट्रैक्ट परिभाषित करें। प्रत्येक उत्पाद में न्यूनतम निम्न शामिल होना चाहिए:

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

उन्हीं दो क्लाइंटों के बारे में सोचें। मोमबत्ती वाला क्लाइंट आपको 12 SKU देता है। आप एक घंटे में फ़ील्ड सेट करते हैं। ड्रॉपशिपर आपको 300 SKU देता है। आप प्रत्येक आपूर्तिकर्ता से CSV निर्यात की आवश्यकता रखते हैं और उन कॉलमों को कॉन्ट्रैक्ट में मैप करते हैं। यदि कोई आपूर्तिकर्ता कोई फ़ील्ड नहीं देता है, तो यह एक सोर्सिंग समस्या है जिसे क्लाइंट को हल करना चाहिए, न कि एक डेटा समस्या जिसके बारे में आप अनुमान लगाएं।

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

6. हर स्टोर पर एक ही स्टेजिंग टेस्ट स्क्रिप्ट चलाएं

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

आपको एक टेस्ट स्क्रिप्ट चाहिए। समान क्रम, समान चरण, हर क्लाइंट:

1. परीक्षण भुगतान विधि के साथ एक वास्तविक परीक्षण ऑर्डर दें।
2. पुष्टि करें कि पुष्टिकरण ईमेल ग्राहक तक पहुँचता है।
3. एक रिफंड संसाधित करें और पुष्टि करें कि क्लाइंट इसे देखता है।
4. एक डिस्काउंट कोड लागू करें और गणित की जाँच करें।
5. अतिथि चेकआउट और लॉग-इन चेकआउट को अलग-अलग जाँचें।
6. केवल डेस्कटॉप पूर्वावलोकन से नहीं, बल्कि मोबाइल फोन से कार्ट में एक उत्पाद जोड़ें।
7. यदि क्लाइंट अंतरराष्ट्रीय शिपिंग करता है तो एक अंतरराष्ट्रीय शिपिंग पते का परीक्षण करें।
8. क्लाइंट के गृह राज्य और एक अन्य राज्य के लिए कर गणना की जाँच करें।
9. एक अस्वीकृत भुगतान ट्रिगर करें और त्रुटि संदेश सत्यापित करें।
10. पुष्टि करें कि बिक्री होने पर इन्वेंट्री घटती है।

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

इसे छोड़ दें और आप जानबूझकर टूटा हुआ स्टोर शिप नहीं करेंगे। आप एक अनपरीक्षित रास्ते वाला स्टोर शिप करेंगे, और पहला वास्तविक ग्राहक इसे ढूंढ लेगा।

7. प्लेटफ़ॉर्म को पहला निर्णय न बनने दें

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

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

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

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

8. न्यूनतम व्यवहार्य कैटलॉग पर लॉन्च गेट करें

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

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

इन शर्तों पर लॉन्च गेट करें, ये सभी द्विआधारी हैं:

• इंटेक ब्रीफ भरा और हस्ताक्षरित है।
• प्रत्येक लॉन्च उत्पाद के लिए उत्पाद डेटा कॉन्ट्रैक्ट फ़ाइल पूर्ण है।
• भुगतान स्टैक स्वीकृत है और परीक्षण ऑर्डर पास हो गया है।
• अनुपालन चेकलिस्ट पूर्ण है।
• स्टेजिंग टेस्ट स्क्रिप्ट पास हो गई है।

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

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

निष्कर्ष: आपकी प्रक्रिया ही उत्पाद है

आप वेबसाइट नहीं बेचते। आप 'मुझे एक स्टोर चाहिए' से 'स्टोर लाइव है और ऑर्डर प्रोसेस कर रहा है' तक एक पूर्वानुमान योग्य मार्ग बेचते हैं। उस मार्ग को डिफ़ॉल्ट की आवश्यकता है, तात्कालिकता की नहीं।

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

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