CRM कैसे काम करता है? गेस्ट डेटा, मैचिंग और जर्नी

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

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

विषय-सूची

• पाँच चरणों में CRM कैसे काम करता है
• गेस्ट डेटा कहाँ से आता है और यह कैसे जुड़ता है
  • मुख्य द्वार के रूप में गेस्ट WiFi
  • कनेक्शन वास्तव में कैसे चलता है
  • शुरुआत में स्वीकार करने योग्य तीन सीमाएं
• रिकॉर्ड्स को एक गेस्ट में मिलाना
  • तुलना करने से पहले की (Key) को साफ़ करना
  • नियम जो आपकी टीम को तय करने हैं
• सेगमेंट और जर्नी रिकॉर्ड्स को मैसेज में बदलते हैं
  • डायनेमिक सेगमेंट और स्टेटिक लिस्ट्स
  • जर्नी कैसे चलती है
• यह मापना कि क्या CRM गेस्ट के व्यवहार को बदलता है
  • होल्डआउट परिणाम को ईमानदारी से पढ़ना
• भेजने से पहले सहमति और मंज़ूरी के नियमों की पुष्टि करें

CRM पाँच चरणों में कैसे काम करता है

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

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

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

केवल सॉफ़्टवेयर ही वैल्यू नहीं बनाता है। 202 अमेरिकी कंपनियों के एक पीयर-रिव्यू अध्ययन में, केवल 39% ने CRM सॉफ़्टवेयर का उपयोग किया, और CRM उपयोगकर्ताओं के बीच, मार्केटिंग और CRM रिटर्न के Nucleus Research सारांश के अनुसार, 40% निवेश पर रिटर्न (ROI) से संतुष्ट थे। उस अध्ययन में पाया गया कि CRM का उपयोग सबसे अधिक ग्राहक प्रतिधारण (retention) और विकास के लिए किया गया था, और प्रतिधारण अपेक्षाओं को पूरा करने से लाभप्रदता का पूर्वानुमान लगाया गया था।

व्यावहारिक नियम: यदि किसी चरण के पीछे कोई दोहराव योग्य प्रक्रिया नहीं है, तो CRM केवल उस अंतर को अधिक सफाई से संग्रहीत करता है।

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

अतिथि डेटा कहाँ से आता है और यह कैसे जुड़ता है

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

मुख्य द्वार के रूप में Guest WiFi

Guest WiFi अक्सर किसी भौतिक स्थान के लिए सबसे समृद्ध पहला संपर्क बिंदु होता है। हमारी अतिथि एक Captive Portal खोलती है, अपना ईमेल दर्ज करती है, आपकी शर्तों को स्वीकार करती है, और मार्केटिंग में ऑप्ट-इन करना चुनती है या नहीं। जब वह ऐसा करती है, तो हम उसका ईमेल, विज़िट की तारीख, ठहरने का समय और पसंदीदा स्थान एक केंद्रीकृत CRM में संग्रहीत करते हैं, जिससे एक साधारण लॉगिन उसकी टाइमलाइन की शुरुआत बन जाता है।

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

स्रोत	उदाहरण सिस्टम	यह क्या रिकॉर्ड करता है	यह CRM तक कैसे पहुँचता है	मुख्य सीमा
गेस्ट WiFi	Cisco Meraki, Juniper Mist	ईमेल, विज़िट की तारीख, रुकने का समय, पसंदीदा स्थान, मार्केटिंग ऑप्ट-इन	गेस्ट साइन-इन करते समय ईमेल दर्ज करता है और शर्तों को स्वीकार करता है	केवल कनेक्ट होने वाले अतिथियों को कैप्चर करता है
पॉइंट ऑफ़ सेल	Square, Epos Now, Loyverse	लेन-देन, खर्च, आइटम, तारीख और साइट	गेस्ट ईमेल से जुड़ा टिल कनेक्टर या एक्सपोर्ट	बिना ईमेल वाली नकद बिक्री को लिंक नहीं किया जा सकता
बुकिंग	ResDiary (पायलट)	बुकिंग की तारीख, लोगों की संख्या, कवर्स, रद्दीकरण, नो-शो	रिजर्वेशन प्लेटफ़ॉर्म से कनेक्टर या API	यह इस बात पर निर्भर करता है कि गेस्ट बुकिंग के समय ईमेल देता है या नहीं
होटल स्टे	Mews (पायलट), apaleo (पायलट)	चेक-इन, चेक-आउट, कमरे का प्रकार, स्टे की तारीखें	प्रॉपर्टी मैनेजमेंट सिस्टम एकीकरण	केवल कनेक्टेड प्रॉपर्टीज़ को कवर करता है
एंटरप्राइज टिल	Lightspeed X-Series (पायलट), Oracle Simphony (पायलट)	गेस्ट से जुड़े बिक्री रिकॉर्ड	टिल से कनेक्टर, केवल पायलट	अधिकांश स्थानों पर अभी लाइव नहीं है
फॉर्म और सर्वेक्षण	वेब फॉर्म, QR सर्वेक्षण, कियोस्क फॉर्म	उत्तर, प्राथमिकताएं और फीडबैक	गेस्ट फॉर्म पूरा करता है और उत्तर रिकॉर्ड में दर्ज हो जाते हैं	केवल रिस्पॉन्स दर जितनी ही पूर्ण होती है

कनेक्शन वास्तव में कैसे काम करता है

प्रत्येक स्रोत अपने तरीके से CRM तक पहुँचता है। WiFi Captive Portal के माध्यम से साइन-इन पर डेटा लिखता है, एक टिल कनेक्टर या निर्धारित निर्यात के माध्यम से डेटा भेज सकता है, और एक आरक्षण प्लेटफ़ॉर्म आमतौर पर एक API के माध्यम से जुड़ता है। संपत्ति प्रबंधन प्रणाली एक एकीकरण के माध्यम से प्रवास डेटा पास करती है, और एक भरा हुआ फ़ॉर्म अपने उत्तरों को सीधे अतिथि रिकॉर्ड में लिखता है।

वे अलग-अलग मार्ग एक ही घड़ी पर नहीं चलते हैं। एक कनेक्टर तेज़ी से सिंक हो सकता है, जबकि एक शेड्यूल्ड फ़ाइल इंपोर्ट घंटों बाद आ सकता है, और यदि पुनर्रूपण (retry) को साफ़ तौर पर नहीं संभाला जाता है तो एक ही इवेंट दो बार दिखाई दे सकता है। समय क्षेत्र (time zones) भी मायने रखते हैं, क्योंकि यदि हर साइट हेड ऑफिस के समय में रिपोर्ट करती है तो एक क्षेत्र में देर रात की विजिट गलत दिन में दर्ज हो सकती है।

एक CRM उन स्रोत प्रणालियों (source systems) को प्रतिस्थापित नहीं करता है। भुगतान आपके भुगतान प्रदाता के पास रहते हैं, टेबल आपके बुकिंग प्लेटफॉर्म के पास रहती हैं, रूम बिलिंग आपकी प्रॉपर्टी सिस्टम के पास रहती है, और टिल ऑपरेशन टिल पर ही रहता है। आप ऐसा टूल भी रख सकते हैं जिसे आपकी टीम पहले से जानती है, क्योंकि CRM लेयर Mailchimp जैसे मौजूदा टूल के साथ काम कर सकती है या आप सब कुछ एक ही स्थान पर समेकित कर सकते हैं।

एक जुड़ा हुआ स्रोत एक उपयोग योग्य रिकॉर्ड के समान नहीं है। आपको अभी भी एक पहचानकर्ता और एक सहमति स्थिति की आवश्यकता है जिस पर आप भरोसा कर सकें।

तीन सीमाएँ जिन्हें जल्दी स्वीकार करना होगा

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

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

रिकॉर्ड्स को एक अतिथि में मिलाना

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

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

तुलना करने से पहले की (Key) को साफ़ करना

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

मैचिंग केस	CRM क्या करता है	गलत तरीके से संभालने पर जोखिम
WiFi और टिल पर एक ही ईमेल	एक प्रोफाइल में मर्ज करता है	ईमेल सही ढंग से दर्ज होने पर कम जोखिम
ईमेल में टाइपो, जैसे gmial.com	एक अलग प्रोफाइल बनाता है	मेहमान को कोई ऑफर नहीं मिलता और डुप्लिकेट प्रोफाइल बन जाती है
साझा किया गया पारिवारिक या कार्य ईमेल	कई लोगों को एक प्रोफाइल में मर्ज करता है	गलत ऑफर और गलत बुकिंग इतिहास
बिना ईमेल के टिल बिक्री	अनाम ट्रांजेक्शन के रूप में रहता है	इसे किसी मेहमान से लिंक नहीं किया जा सकता या प्रति व्यक्ति मापा नहीं जा सकता
दो ईमेल पतों वाला एक व्यक्ति	जब तक लिंक न हो, दो प्रोफाइल	दोहरे मैसेज या चूका हुआ विन-बैक
केवल फोन नंबर के साथ बुकिंग	केवल तभी मैच करता है जब फोन फाइल पर हो	रिजर्वेशन प्लेटफॉर्म से डुप्लिकेट प्रोफाइल

नियम जो आपकी टीम को तय करने होंगे

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

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

पहले ऑडिट करें: उन पर बनाए गए किसी भी सेगमेंट पर भरोसा करने से पहले पिछली तिमाही के डुप्लिकेट प्रोफाइल को गिनें।

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

सेगमेंट और जर्नी रिकॉर्ड को मैसेज में बदलते हैं

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

वह रिकॉर्ड मेहमानों के लिए मायने रखता है, केवल मार्केटर्स के लिए नहीं। 2024 में, Forbes के स्टेट ऑफ कस्टमर सर्विस एंड CX स्टडी के लिए सर्वेक्षण में शामिल 81% अमेरिकी उपभोक्ताओं ने कहा कि वे व्यक्तिगत अनुभव (personalized experiences) प्रदान करने वाली कंपनियों को प्राथमिकता देते हैं, और व्यक्तिगत ग्राहक अनुभव पर Forbes की रिपोर्ट के अनुसार, 70% ने कहा कि कर्मचारियों के लिए कंपनी के साथ उनकी पहचान और इतिहास को जानना महत्वपूर्ण था। एक साझा टाइमलाइन ही वह माध्यम है जिससे कर्मचारी और संदेश उस इतिहास पर लगातार काम कर पाते हैं।

डायनामिक सेगमेंट और स्टैटिक सूचियां

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

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

एक यात्रा कैसे चलती है

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

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

मान लीजिए कि हमारी अतिथि ने 45 दिनों से विज़िट नहीं किया है। वह निष्क्रिय सेगमेंट में प्रवेश करती है, यात्रा यह जांचती है कि उसने ऑप्ट-इन किया है और उसे अभी तक कोई अन्य ऑफ़र नहीं मिला है, फिर 3 दिन प्रतीक्षा करती है और एक विन-बैक संदेश भेजती है। यदि वह प्रतीक्षा के दौरान विज़िट करती है, तो निकास नियम को संदेश भेजे जाने से पहले उसे हटा देना चाहिए।

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

यह मापना कि क्या CRM अतिथि के व्यवहार को बदलता है

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

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

ओपन रेट्स से इतर भौतिक स्थलों में ईमेल रिटर्न को मापने के लिए हमारी गाइड इन ऑफ़लाइन परिणामों को चुनने पर गहराई से विचार करती है। इसका मूल समाधान एक होल्डआउट (holdout) है, जहाँ योग्य मेहमानों का एक यादृच्छिक हिस्सा, उदाहरण के लिए 10% निष्क्रिय मेहमान, कुछ भी प्राप्त नहीं करता है। इसके बाद आप एक निश्चित समयावधि में ऑफ़र पाने वाले और न पाने वाले समूहों की विजिट दरों की तुलना करते हैं।

नीचे दिया गया वॉकथ्रू व्यवहार में उस मापन मानसिकता को दिखाता है, एक जर्नी भेजने से लेकर यह जांचने तक कि क्या बदला है।

होल्डआउट परिणाम को ईमानदारी से पढ़ना

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

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

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

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

भेजने से पहले सहमति और अनुमोदन नियमों की पुष्टि करें

गवर्नेंस भेजने वाले वर्कफ़्लो के भीतर होनी चाहिए, न कि किसी ऐसे गोपनीयता परिशिष्ट (privacy appendix) में जिसे कोई खोलता ही नहीं है। भरोसे का यह अंतर मार्केटर्स और AI पर SAS रिपोर्ट में स्पष्ट दिखाई देता है, जहां 2025 के एक वैश्विक सर्वेक्षण में पाया गया कि 90% मार्केटर्स ने एजेंटिक AI पर कुछ हद तक भरोसा किया, लेकिन केवल 5% ने पूर्ण विश्वास व्यक्त किया, और 48% का मानना था कि मनुष्यों को AI-जनरेटेड निर्णयों को मंजूरी देनी चाहिए। उसी रिपोर्ट में अलग से किए गए शोध से पता चला कि 77% मार्केटर्स ने या तो मानवीय पर्यवेक्षण के साथ कम जोखिम वाले AI निर्णयों को या मानव के अंतिम निर्णयों के बाद AI-जनरेटेड अंतर्दृष्टि (insights) को प्राथमिकता दी।

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

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

1. ऑप्ट-इन शब्दावली की पुष्टि करें: WiFi साइन-इन और CRM को फीड करने वाले प्रत्येक फ़ॉर्म पर सटीक शब्दों की जाँच करें।
2. सप्रेशन (suppression) का परीक्षण करें: एक नमूना अतिथि को ऑप्ट-आउट करें, नया डेटा आयात करें, और पुष्टि करें कि उसे अभी भी कुछ भी प्राप्त नहीं होता है।
3. एक नामित व्यक्ति के साथ स्वीकृत करें: पहला अभियान केवल एक जवाबदेह व्यक्ति द्वारा दर्शकों, सामग्री और समय को मंज़ूरी देने के बाद ही भेजें।
4. ऑडिट लॉग की जाँच करें: एक सप्ताह बाद वापस आएं और पुष्टि करें कि अनुमोदन, सप्रेशन और प्रेषण का पता लगाया जा सकता है।

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

---

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