कार्ट परित्याग के बारे में बहस बंद करें: चेकआउट सुधारों को मंजूरी दिलाएँ

सारांश

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

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

वास्तव में क्या काम करता है यह रणनीतियों की एक लंबी सूची नहीं है। यह अनुमोदन प्रक्रिया को स्वयं रूपांतरण अनुकूलन समस्या के हिस्से के रूप में मानना है। आप जो प्रतिरोध सुन रहे हैं—"हमारे पास डेटा नहीं है," "हमें डेवलपर समय नहीं मिल सकता," "हमने पहले यह कोशिश की थी," "यह हमारा काम नहीं है"—शोर नहीं है। हर आपत्ति आपको बता रही है कि परियोजना का कौन सा हिस्सा आपने अभी तक ठोस नहीं बनाया है। आपत्ति का उत्तर दें, और परिवर्तन एक अनुरोध नहीं रह जाता और एक योजना बन जाता है।

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

"मुझे डेटा दिखाओ" का मतलब है मुझे फ़नल दिखाओ

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

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

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

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

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

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

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

"हमारे पास डेवलपर समय नहीं है" आमतौर पर इसका मतलब है कि आपने सेटिंग्स को कोड से अलग नहीं किया है

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

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

थोड़ी देर के लिए अपनी आउटडोर गियर कंपनी पर वापस जाएँ। रिटर्न नीति फुटर में दबी हुई है, और खरीदारी को लेकर घबराए हुए खरीदार इसे कभी नहीं पाते। आपका बॉस मानता है कि सुधार का मतलब है "फुटर और टेम्पलेट को फिर से बनाना।" लेकिन वास्तविक सुधार कार्ट में जोड़ें बटन के नीचे टेक्स्ट की एक पंक्ति जोड़ना है: "30-दिन की वापसी, कोई सवाल नहीं—हमारी नीति देखें।" लिंक एक ऐसे पेज पर जाता है जो पहले से मौजूद है। यह एक CMS संपादन है, एक स्प्रिंट नहीं।

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

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

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

"हमने पहले ही सरलीकरण आज़मा लिया है" का मतलब है कि आप गलत कारण को ठीक कर रहे थे

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

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

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

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

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

वह बारीकी उसी तर्क के पीछे है जो बताता है कि चेकआउट के लिए "सब कुछ सरल करें" दृष्टिकोण एक भ्रांति क्यों है। ऐसा नहीं है कि सरलीकरण बुरा है; यह है कि सरलीकरण कई में से एक लीवर है, और यह जाने बिना इसे खींचना कि आप किस कारण को संबोधित कर रहे हैं, एक तिमाही बर्बाद कर सकता है।

"हमें पहले एक योजना चाहिए" वास्तव में एक प्रक्रिया का अनुरोध है

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

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

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

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

यहाँ चेतावनी एक साथ बहुत सारे बदलाव न करने के बारे में है। एक छोटी साइट पर, आपको जानना होगा कि किस बदलाव ने परिणाम उत्पन्न किया। प्रति सप्ताह या प्रति माह एक बदलाव डींग मारने के लिए धीमा है लेकिन सीखने के लिए तेज़ है। A/B परीक्षण एक विलासिता है; एक स्पष्ट विफलता के लिए, जिस मीट्रिक की आप परवाह करते हैं उसका एक पहले-और-बाद का दृश्य अक्सर अगले कदम को सही ठहराने के लिए पर्याप्त होता है। यदि आप इस लूप का अधिक औपचारिक संस्करण चाहते हैं, ई-कॉमर्स ग्राहकों के लिए एक दोहराने योग्य CRO प्रक्रिया बनाने के लिए हमारी मार्गदर्शिका चरणों को बताती है।

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

"यह मार्केटिंग का काम नहीं है" गायब हो जाता है जब आप संदेश के मालिक होते हैं

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

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

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

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

अगली बजट बैठक के लिए एक संदर्भ तालिका

अब तक पैटर्न स्पष्ट हो जाना चाहिए: प्रत्येक आपत्ति एक अलग अनुरोध है—मुझे सबूत दिखाओ, मुझे दिखाओ कि यह छोटा है, मुझे दिखाओ कि यह पिछली बार की पुनरावृत्ति नहीं है, मुझे योजना दिखाओ, मुझे दिखाओ कि यह हमारा है। यहाँ वे एक साथ हैं, साथ में जो उत्तर आमतौर पर काम करता है।

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

"अगर यह चीजों को बदतर बना देता है तो क्या होगा?" एक सीधा उत्तर का हकदार है

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

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

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

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

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

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

निष्कर्ष: अगले बदलाव को इतना छोटा बनाएं कि हाँ कहना आसान हो

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

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

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