CRM कसे कार्य करते? गेस्ट डेटा, मॅचिंग आणि जर्नीज

एक नियमित ग्राहक तुमच्या कॅफेमध्ये येतो, WiFi शी जोडला जातो, दुपारच्या जेवणासाठी पैसे देतो आणि शुक्रवारी टेबल बुक करतो. तुमची टीम तिचा चेहरा ओळखू शकेल, पण तुमची सिस्टीम तिला तीच व्यक्ती म्हणून ओळखण्याची शक्यता कमी आहे. WiFi पोर्टलकडे तिचा ईमेल आहे, बिलिंग काउंटरकडे कार्ड पेमेंटची नोंद आहे आणि बुकिंग डायरीमध्ये नाव व फोन नंबर आहे.

ही ती तफावत आहे जी CRM भरून काढते. हे कर्मचाऱ्यांना अधिक गोष्टी लक्षात ठेवण्यास सांगत नाही. हे संपूर्ण ठिकाणाला एक सामायिक गेस्ट मेमरी देते जी ते तपासू शकतात, विभागू शकतात, त्यावर कारवाई करू शकतात आणि मोजू शकतात. CRM प्रत्यक्ष व्यवहारात कसे कार्य करते हे तुम्ही विचारत असाल, तर प्रणालीद्वारे एका पाहुण्याचे अनुसरण करा. प्रत्येक टप्पा एकतर तिच्या रेकॉर्डमध्ये एक तपशील जोडतो, पुढे काय व्हावे हे ठरवतो किंवा तुम्ही पाठवलेल्या मेसेजने तिची कृती बदलली आहे का ते तपासतो.

अनुक्रमणिका

• पाच टप्प्यांत CRM कसे कार्य करते
• पाहुण्यांचा डेटा कुठून येतो आणि तो कसा कनेक्ट होतो
  • मुख्य प्रवेशद्वार म्हणून Guest WiFi
  • कनेक्शन प्रत्यक्षात कसे चालते
  • सुरवातीलाच स्वीकारायच्या तीन मर्यादा
• रेकॉर्ड्स एका पाहुण्याच्या प्रोफाइलमध्ये जुळवणे
  • तुलना करण्यापूर्वी की (key) स्वच्छ करणे
  • तुमच्या टीमला ठरवावे लागणारे नियम
• विभाग आणि जर्नी रेकॉर्ड्सना संदेशांमध्ये रूपांतरित करतात
  • डायनॅमिक सेगमेंट्स आणि स्टॅटिक लिस्ट्स
  • जर्नी कशी चालते
• CRM मुळे पाहुण्यांच्या वर्तनात बदल होतो का याचे मोजमाप करणे
  • होल्डआउट परिणामाचे प्रामाणिकपणे विश्लेषण करणे
• पाठवण्यापूर्वी संमती आणि मंजुरीच्या नियमांची पुष्टी करा

CRM पाच टप्प्यांत कसे कार्य करते

CRM हे प्रत्येक पाहुण्याची सामायिक आठवण (shared memory) आहे, जुन्या हॉटेल कार्ड फाइलसारखे जे कर्मचाऱ्यांना परत येणाऱ्या पाहुण्यांचे नाव घेऊन स्वागत करण्यास सक्षम करते. ते परस्परसंवाद कॅप्चर करून, योग्य व्यक्तीशी मॅच करून, त्या व्यक्तीला विशिष्ट विभागात वर्गीकृत करून, त्यांची डिजिटल प्रवास सुरू करून आणि निकालांचे मोजमाप करून कार्य करते.

समजा आमचा पाहुणा मंगळवारी तुमच्या कॅफेच्या WiFi शी जोडला जातो, गुरुवारी कार्डने पैसे देतो आणि शुक्रवारी टेबल बुक करतो. CRM शिवाय, या तीन वेगवेगळ्या ठिकाणच्या तीन संबंध नसलेल्या घटना आहेत. CRM सह, त्या एक टाइमलाइन बनतात जी ते कधी भेट देतात, काय खर्च करतात आणि कधी परत येण्याचे नियोजन करतात हे दाखवते.

टप्पा	काय घडते	स्थळाचे उदाहरण	आउटपुट
1. Capture	पाहुण्यांच्या संवादातून एक रेकॉर्ड तयार होतो	पाहुणे ईमेल आयडीसह WiFi वर जॉइन होतात	एक रॉ ॲक्टिव्हिटी इव्हेंट
2. Match	इव्हेंट्स एकाच व्यक्तीशी जोडले जातात	त्याच ईमेलची कॅश काउंटर पावती WiFi रेकॉर्डशी जोडली जाते	टाईमलाइनसह एक गेस्ट प्रोफाईल
3. Segment	नियम पाहुण्यांची वेगवेगळ्या गटांमध्ये वर्गवारी करतात	45 दिवसांत भेट न दिलेल्या पाहुण्यांचा लॅप्स (lapsed) गटामध्ये समावेश होतो	एक लाईव्ह ऑडियन्स लिस्ट
4. Act	ट्रिगर झाल्यावर जर्नी मेसेज किंवा ऑफर्स पाठवतात	पाहुणे गटामध्ये समाविष्ट झाल्यानंतर 3 दिवसांनी विन-बॅक मेसेज पाठवला जातो	पाठवलेला मेसेज आणि त्याचा केलेला वापर (redemption)
5. Measure	निकाल होल्डआउट गटाशी पडताळून पाहिले जातात	लॅप्स झालेल्या 10% पाहुण्यांना कोणतीही ऑफर मिळत नाही	कॉन्फिडन्स रेंजसह वाढीव भेटी (incremental visits)

फक्त सॉफ्टवेअर मूल्य निर्माण करत नाही. २०२ अमेरिकन कंपन्यांच्या पीअर-रिव्ह्यू केलेल्या अभ्यासात, केवळ ३९% कंपन्यांनी CRM सॉफ्टवेअर वापरले, आणि CRM वापरकर्त्यांपैकी, मार्केटिंग आणि CRM परताव्यावरील Nucleus Research संक्षिप्त अहवालानुसार फक्त ४०% लोक गुंतवणुकीवरील परताव्यावर (ROI) समाधानी होते. त्या अभ्यासात असे आढळून आले की CRM चा वापर सर्वाधिक ग्राहकांना टिकवून ठेवण्यासाठी आणि त्यांचा विकास करण्यासाठी केला गेला, आणि ग्राहक टिकवून ठेवण्याच्या अपेक्षा पूर्ण केल्याने फायदेशीरतेचा अंदाज बांधता आला.

व्यावहारिक नियम: जर एखाद्या टप्प्यामागे पुनरावृत्ती करण्यायोग्य प्रक्रिया नसेल, तर CRM फक्त ती तफावत अधिक नीटसपणे स्टोअर करते.

काहीही खरेदी करण्यापूर्वी किंवा पुन्हा तयार करण्यापूर्वी एक जलद सराव करून पहा. पाच टप्प्यांच्या आधारे तुमचे सध्याचे गेस्ट टचपॉइंट्स लिस्ट करा, त्यानंतर तुम्ही आज कोणत्या इव्हेंट्स व्यक्तीशी कनेक्ट करू शकत नाही ते चिन्हांकित करा. ती चिन्हे तुम्हाला दाखवतात की आधी कुठे काम करणे आवश्यक आहे.

गेस्ट डेटा कोठून येतो आणि तो कसा कनेक्ट होतो

कॅप्चरमुळे नोंद सुरू होते आणि प्रत्येक स्त्रोत पाहुण्याबद्दलची वेगवेगळी माहिती जोडतो. एका सिस्टीमला ती भेट दिल्याबद्दल माहिती असते, दुसऱ्या सिस्टीमला तिने काय खरेदी केले हे माहित असते आणि तिसऱ्या सिस्टीमला ती शुक्रवारी परत येत आहे हे माहित असते. CRM चे काम त्या सिस्टीम्सवर ताबा न घेता ही माहिती एकत्रितपणे वाचणे हे आहे.

मुख्य प्रवेशद्वार म्हणून गेस्ट WiFi

गेस्ट WiFi हा सहसा भौतिक ठिकाणासाठी सर्वात समृद्ध पहिला स्पर्श बिंदू असतो. आमची गेस्ट Captive Portal उघडते, तिचा ईमेल प्रविष्ट करते, तुमच्या अटी स्वीकारते आणि मार्केटिंगमध्ये समाविष्ट व्हायचे की नाही ते निवडते. जेव्हा ती सहमती देते, तेव्हा आम्ही तिचा ईमेल, भेटीची तारीख, राहण्याचा वेळ आणि पसंतीचे स्थान एका केंद्रीकृत CRM मध्ये संग्रहित करतो, ज्यामुळे एक साधा लॉगिन तिच्या टाइमलाइनची सुरुवात बनतो.

जेव्हा पावती त्याच ईमेलशी जोडली जाते, तेव्हा बिलिंग सिस्टीम (till) व्यवहार, वस्तू आणि खर्चाची नोंद जोडते. बुकिंग सिस्टीममध्ये लोकांची संख्या, कव्हर, रद्दबातल केलेल्या गोष्टी आणि नो-शो जोडले जातात. हॉटेल सिस्टीम चेक-इन, खोलीचा प्रकार आणि मुक्कामाच्या तारखा जोडते, तर फॉर्म आणि सर्वेक्षणांमधून प्राधान्ये आणि थेट अभिप्राय जोडला जातो. आमची ठिकाणांसाठी फर्स्ट-पार्टी डेटा तयार करण्याची मार्गदर्शिका (building first-party data for venues) हे स्रोत जोडण्यास सुरुवात करण्यापूर्वी त्याचे नियोजन कसे करावे हे स्पष्ट करते.

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

कनेक्शन प्रत्यक्षात कसे कार्य करते

प्रत्येक स्रोत आपापल्या पद्धतीने CRM पर्यंत पोहोचतो. WiFi हे Captive Portal द्वारे साइन इन करताना माहिती नोंदवते, बिलिंग काउंटर कनेक्टर किंवा शेड्यूल्ड एक्सपोर्टद्वारे डेटा पाठवू शकते आणि आरक्षण प्लॅटफॉर्म सहसा API द्वारे कनेक्ट होतो. प्रॉपर्टी मॅनेजमेंट सिस्टम्स एका एकात्मतेद्वारे मुक्कामाचा डेटा पाठवतात, आणि पूर्ण केलेला फॉर्म त्याची उत्तरे थेट गेस्ट रेकॉर्डवर लिहितो.

ते वेगवेगळे मार्ग एकाच घड्याळावर चालत नाहीत. एखादे कनेक्टर वेगाने सिंक होऊ शकते, तर शेड्यूल्ड फाइल इम्पोर्ट काही तासांनंतर पोहोचू शकते आणि रीट्राई व्यवस्थित न हाताळल्यास तीच इव्हेंट दोनदा दिसू शकते. टाइम झोन देखील महत्त्वाचे आहेत, कारण प्रत्येक ठिकाण मुख्य कार्यालयाच्या वेळेत रिपोर्ट करत असल्यास एका प्रदेशातील उशिरा रात्रीची भेट दुसऱ्या चुकीच्या दिवशी नोंदवली जाऊ शकते.

CRM त्या मूळ सिस्टीम्सची जागा घेत नाही. पेमेंट्स तुमच्या पेमेंट प्रोव्हायडरकडे राहतात, टेबल्स तुमच्या बुकिंग प्लॅटफॉर्मकडे राहतात, रूम बिलिंग तुमच्या प्रॉपर्टी सिस्टीमकडे राहते आणि टिल ऑपरेशन टिलवरच राहते. CRM लेयर मेलचिंप सारख्या विद्यमान साधनांसोबत काम करू शकते किंवा तुम्ही सर्वकाही एकाच ठिकाणी एकत्र करू शकत असल्यामुळे तुम्ही तुमच्या टीमला आधीच माहित असलेले टूल देखील सुरू ठेवू शकता.

कनेक्ट केलेला स्रोत वापरण्यायोग्य रेकॉर्डसारखा नसतो. तुम्हाला अजूनही आयडेंटिफायर आणि संमतीची स्थिती आवश्यक आहे ज्यावर तुम्ही विश्वास ठेवू शकता.

सुरवातीलाच मान्य करायच्या तीन मर्यादा

• आयडेंटिफायर नाही, लिंक नाही: जिथे पाहुणे आयडेंटिफायर देतात, सामान्यतः ईमेल, तिथेच रेकॉर्ड अस्तित्वात येतो, त्यामुळे निनामी रोख विक्री अनलिंक राहते आणि ती प्रति व्यक्ति मोजमापास सपोर्ट करू शकत नाही.
• सहमती गृहीत धरली जात नाही, ती मिळवली जाते: पाहुण्याने साइन-अप करताना दिलेला ऑप्ट-इन हा रेकॉर्डसह स्टोअर केला जातो. तिने काहीतरी खरेदी केले किंवा टेबल बुक केले म्हणून नंतर परवानगी गृहीत धरू नका.
• इंपोर्ट्समध्ये सर्वाधिक धोका असतो: स्प्रेडशीट इंपोर्ट्स इतर चांगल्या स्वच्छ डेटाबेसमध्ये जुने, डुप्लिकेट केलेले किंवा सहमती नसलेले कॉन्टॅक्ट्स आणू शकतात. पहिल्यांदा ईमेल पाठवण्यापूर्वी सहमती फील्ड्स आणि तारखा तपासा, नंतर नाही.

तुम्ही चालवत असलेल्या प्रत्येक स्रोतासाठी एका सोप्या ऑडिटसह पूर्ण करा. ते ईमेल कलेक्ट करते का, ते संमतीची नोंद ठेवते का, ते फक्त अनामित अ‍ॅक्टिव्हिटी लॉग करते का आणि त्याचे कनेक्टर लाइव्ह आहे की अजूनही पायलट मोडमध्ये आहे याची नोंद घ्या. ती छोटी यादी तुम्हाला तुमचे CRM प्रामाणिकपणे काय जाणून घेऊ शकते ते सांगते.

रेकॉर्ड्स एकाच गेस्टशी मॅच करणे

मॅचिंग हे एखाद्या ग्रंथालयाच्या रिटर्न डेस्कप्रमाणे काम करते. असिस्टंट ओळखीच्या चेहऱ्यावरून कोणी पुस्तक नेले आहे याचा अंदाज लावत नाही. बोरॉवरचा कार्ड नंबर हे काम करतो आणि वेन्यू CRM मध्ये, पाहुण्यांचा ईमेल पत्ता सहसा हे काम करतो.

ईमेल ही सामायिक केलेली कूंजी आहे कारण गेस्ट ती अनेक ठिकाणी टाईप करतात. आमची गेस्ट मंगळवारी WiFi साइन इन करताना ती प्रविष्ट करते, गुरुवारी ई-पावतीसाठी देते आणि शुक्रवारी बुकिंग करताना ती पुन्हा वापरते. जेव्हा तोच पत्ता दिसतो, तेव्हा CRM तीन तुकडे सोडण्याऐवजी प्रत्येक इव्हेंट एका टाइमलाइनसह एका प्रोफाईलला जोडतो.

तुलना करण्यापूर्वी की (key) स्वच्छ करणे

दोन पत्त्यांची तुलना करण्यापूर्वी, CRM त्यांना सामान्यीकृत (normalise) करते. हे कॅपिटल अक्षरे आणि अतिरिक्त जागांकडे दुर्लक्ष करते, त्यामुळे कॅपिटल पहिल्या अक्षरामुळे दुसरी व्यक्ती तयार होत नाही. ही छोटी स्वच्छता चुकीच्या डुप्लिकेट्सना प्रतिबंधित करते, परंतु ती खरोखर भिन्न पत्ता किंवा डोमेन मधील स्पेलिंगची चूक सुधारू शकत नाही.

मॅचिंग केस	CRM काय करते	योग्यरित्या न हाताळल्यास होणारा धोका
WiFi आणि कॅश काउंटरवर एकच ईमेल	एका प्रोफाईलमध्ये विलीन करते	ईमेल योग्यरित्या प्रविष्ट केल्यास कमी धोका असतो
ईमेल टायपो, जसे की gmial.com	स्वतंत्र प्रोफाईल तयार करते	पाहुण्यांना कोणत्याही ऑफर्स मिळत नाहीत आणि डुप्लिकेट प्रोफाईल तयार होते
शेअर केलेला कौटुंबिक किंवा कामाचा ईमेल	अनेक व्यक्तींना एकाच प्रोफाईलमध्ये विलीन करते	चुकीच्या ऑफर्स आणि चुकीचा बुकिंग इतिहास
ईमेलशिवाय कॅश काउंटर विक्री	अनामित व्यवहार म्हणून राहते	पाहुण्याशी जोडले जाऊ शकत नाही किंवा प्रति व्यक्ती मोजले जाऊ शकत नाही
दोन ईमेल आयडी असलेली एक व्यक्ती	लिंक करेपर्यंत दोन प्रोफाईल राहतात	दोनदा मेसेज जातात किंवा विन-बॅकची संधी हुकते
फक्त फोन नंबरसह बुकिंग	फोन नंबर रेकॉर्डवर असल्यास फक्त मॅच होते	आरक्षण प्लॅटफॉर्मवरून डुप्लिकेट प्रोफाईल्स तयार होतात

तुमच्या टीमला ठरवावे लागणारे नियम

सॉफ्टवेअर मॅचिंग नियम लागू करू शकते, परंतु ते तुमच्या टीमला निवडावे लागतील. दोन प्रोफाइल कधी मर्ज करायची हे ठरवा, जसे की जेव्हा ईमेल आणि फोन दोन्ही जुळतात. ते कधी वेगळे राहिले पाहिजेत हे ठरवा, कारण सामायिक केलेले कौटुंबिक इनबॉक्स वेगवेगळ्या सवयी असलेल्या दोन पाहुण्यांचे प्रतिनिधित्व करू शकते.

जेव्हा प्रोफाइल विलीन होतात, तेव्हा पूर्ण एकत्रित टाइमलाइन ठेवा. दोन्ही रेकॉर्डमधील भेटी, खरेदी, बुकिंग, संमतीतील बदल आणि संदेश टिकून राहिले पाहिजेत, तसेच सर्वात अलीकडील संमती स्थिती काळजीपूर्वक हाताळली पाहिजे. विलीन करताना इतिहास हटवला गेल्यास, भेटीची वारंवारता किंवा शेवटच्या भेटीच्या तारखेवर तयार केलेले सेगमेंट्स कोणत्याही सूचनेशिवाय चुकीचे होतील.

पहिले ऑडिट: त्यावर तयार केलेल्या कोणत्याही सेगमेंटवर विश्वास ठेवण्यापूर्वी शेवटच्या तिमाहीतील डुप्लिकेट प्रोफाईल्सची गणना करा.

ते ऑडिट क्लिष्ट असण्याची गरज नाही. समान ईमेल, शेअर केलेला फोन नंबर आणि जवळजवळ समान नावानुसार प्रोफाईलचे गट करा, त्यानंतर काहींचे स्वतः नमुने तपासा. जर तुम्हाला आमचा पाहुणा दोनदा आढळला, तर तिच्या भेटीच्या वारंवारतेबद्दलचा प्रत्येक दावा आधीच संशयास्पद आहे.

सेगमेंट आणि जर्नी रेकॉर्डचे मेसेजमध्ये रुपांतर करतात

सेगमेंट हा गेस्ट रेकॉर्डला लागू केलेला एक नियम आहे. ते असे असू शकते: किमान दोनदा भेट दिली, ठराविक रक्कमेपेक्षा जास्त खर्च केला, हॉटेल गेस्ट म्हणून टॅग केले गेले, सर्वेक्षणात विशिष्ट प्रकारे उत्तर दिले, किंवा 45 दिवसांत भेट दिली नाही. ज्या गेस्टचा रेकॉर्ड या नियमाची पूर्तता करतो तो त्या गटात समाविष्ट होतो.

तो रेकॉर्ड केवळ मार्केटर्ससाठीच नाही, तर पाहुण्यांसाठीही महत्त्वाचा असतो. 2024 मध्ये, Forbes च्या ग्राहक सेवा आणि CX अभ्यासासाठी सर्वेक्षण केलेल्या 81% U.S. ग्राहकांनी सांगितले की ते व्यक्तिगत अनुभव (personalized experiences) देणाऱ्या कंपन्यांना प्राधान्य देतात, आणि व्यक्तिगत ग्राहक अनुभवावरील Forbes अहवालानुसार 70% लोकांनी सांगितले की कर्मचाऱ्यांना त्यांची ओळख आणि कंपनीसोबतचा त्यांचा इतिहास माहिती असणे महत्त्वाचे आहे. एक सामायिक टाइमलाइन हीच गोष्ट कर्मचारी आणि संदेशांना त्या इतिहासावर सातत्याने कारवाई करण्यास सक्षम करते.

डायनॅमिक सेगमेंट्स आणि स्टॅटिक लिस्ट्स

पाहुणे जसे वागतात तसतसे डायनॅमिक सेगमेंट अपडेट होते. नवीन भेट नोंदवल्याबरोबर आमचा पाहुणा लॅप्स झालेल्या ग्रुपमधून बाहेर पडतो आणि तिच्या भेटींची संख्या तुमच्या थ्रेशोल्डपेक्षा जास्त झाल्यावर ती रेग्युलर ग्रुपमध्ये सामील होते. प्रत्येक मोहीम चालवण्यापूर्वी कोणालाही ही लिस्ट पुन्हा तयार करण्याची गरज नाही.

स्टॅटिक लिस्ट (static list) स्नॅपशॉटसारखी स्थिर असते. ही एकाच वेळी होणाऱ्या इव्हेंटच्या आमंत्रणासाठी उपयुक्त आहे जिथे ग्राहक बदलू नयेत, परंतु भेट, खर्च आणि ऑप्ट-आऊट सतत बदलत असल्याने काही आठवड्यांत ती कालबाह्य होते. स्टॅटिक लिस्टचा वापर विचारपूर्वक करा आणि त्यांना तारीख द्या जेणेकरून कोणीही चुकीने जुना स्नॅपशॉट पुन्हा वापरणार नाही.

प्रवास कसा चालतो

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

1. ट्रिगर फायर होतो: पाहुणे एखाद्या सेगमेंटमध्ये सामील होतात किंवा एखादा इव्हेंट पूर्ण करतात, जसे की भेट न देता 45 दिवस पूर्ण होणे.
2. अट तपासली जाते: CRM त्यांच्या संमती, अलीकडील मेसेज, स्थान आणि आपण सेट केलेल्या कोणत्याही अपवादासाठी त्यांचे रेकॉर्ड वाचते.
3. प्रतीक्षा वेळ सेट केला जातो: जर्नी ठरवलेल्या कालावधीसाठी (उदा. 3 दिवस) थांबते, जेणेकरून नियम बदलल्या क्षणी त्यांच्याशी संपर्क साधला जाणार नाही.
4. मेसेज किंवा ऑफर पाठवली जाते: त्यांना परवानगी असलेल्या चॅनेलद्वारे विन-बॅक ईमेल, टेक्स्ट किंवा ऑफर मिळते.
5. पाहुणे बाहेर पडतात किंवा पुन्हा प्रवेश करतात: त्या पाहुण्यांनी भेट दिल्यास, ऑफर वापरल्यास, ऑप्ट-आऊट केल्यास किंवा मार्ग पूर्ण केल्यास बाहेर पडतात आणि ठरवलेल्या कालावधीनंतरच पुन्हा प्रवेश करू शकतात.

समजा आमच्या गेस्टने 45 दिवस भेट दिलेली नाही. ती लॅप्स झालेल्या सेगमेंटमध्ये प्रवेश करते, जर्नी तपासते की तिने संमती दिली आहे आणि तिला नुकतीच दुसरी ऑफर मिळालेली नाही, नंतर 3 दिवस वाट पाहते आणि विन-बॅक मेसेज पाठवते. जर तिने वाट पाहण्याच्या काळात भेट दिली, तर मेसेज पाठवण्यापूर्वी एक्झिट रूलने तिला काढून टाकले पाहिजे.

कोणताही विभाग (segment) तयार करण्यापूर्वी, ड्युटी मॅनेजरला समजेल अशा एका सोप्या वाक्यात त्याचे वर्णन करा. "ज्या पाहुण्यांनी दोनदा भेट दिली आहे, गेल्या 45 दिवसांत परत आलेले नाहीत आणि या साइटवर साइन-अप केले आहे" हे तयार करण्यायोग्य आणि तपासण्यायोग्य आहे. "लॅप्स झालेले फॅन्स" असे नाही, कारण CRM ने योग्य लोकांना निवडले आहे की नाही हे कोणीही तपासू शकत नाही.

CRM मुळे गेस्टच्या वर्तनात बदल होतो का याचे मापन करणे

Mailchimp वापरणाऱ्या आणि ३५ टक्के ओपन रेट असलेल्या ४० ठिकाणांच्या रेस्टॉरंट समूहाने त्यांच्या Cisco Meraki नेटवर्कवर Purple Engage लागू केले. त्यांनी बर्थडे मंथ ऑफर आणि लॅप्सड डाइनर कॅम्पेन सेट केले आणि त्यानंतर प्रत्येक कॅम्पेनमुळे प्रत्यक्ष किती लोक आले याची अचूक आकडेवारी ते रिपोर्ट करू शकले. हे व्हेंडरने रिपोर्ट केलेले अकाऊंट म्हणून पाहा, त्यामुळे तुमच्या स्वतःच्या ठिकाणांवर चाचणी करण्याचा हा एक दावा आहे, प्रत्येक समूहाला समान निकाल दिसेल असा हा पुरावा नाही.

ओपन आणि क्लिक्स हे सिद्ध करू शकत नाहीत की संदेशामुळे पाहुण्याने अतिरिक्त भेट दिली. AdExchanger आणि DISQO प्रोग्रामेटिक मेजरमेंट रिपोर्ट मधील विखंडित डेटा, असंगत मेट्रिक्स आणि चुकीचे ॲट्रिब्युशन यांसारखे कायमस्वरूपी अडथळे ओळखले गेले आहेत, तसेच अपूर्ण रेकॉर्ड्स, संघटनात्मक अडथळे आणि अनुपालन मर्यादांमुळे फर्स्ट-पार्टी डेटा कसा मर्यादित होतो हे देखील नमूद केले आहे. ठिकाणांसाठी (venues), खरा महत्त्वाचा परिणाम हा ऑफलाइन, म्हणजेच एखाद्या भेटीत, बुकिंगमध्ये, पावतीमध्ये किंवा मुक्कामामध्ये दिसून येतो.

भौतिक ठिकाणांमध्ये ओपन रेट्सच्या पलीकडे जाऊन ईमेल रिटर्नचे मोजमाप करण्याबाबतची आमची मार्गदर्शिका त्या ऑफलाइन निकालांची निवड करण्यावर अधिक सखोल माहिती देते. यावरील मूलभूत उपाय म्हणजे होल्डआउट, जिथे पात्र पाहुण्यांचा ठराविक भाग, उदाहरणार्थ १०% लॅप्स झालेले पाहुणे, यांना काहीही पाठवले जात नाही. त्यानंतर तुम्ही एका ठराविक कालावधीत मेसेज पाठवलेल्या आणि न पाठवलेल्या गटांमधील भेटीच्या दरांची तुलना करता.

खालील वॉकथ्रू जर्नी पाठवण्यापासून ते काय बदलले हे तपासण्यापर्यंत व्यवहारात ते मोजण्याचे माइंडसेट दाखवते.

होल्डआउट निकालाचे प्रामाणिकपणे वाचन करणे

एका भव्य आकड्याऐवजी श्रेणी (range) चा अहवाल द्या. जर संदेश पाठवलेले गेस्ट holdout पेक्षा जास्त वेळा भेट देत असतील, तर हा फरक तुमच्या मेसेजने तयार केलेल्या अतिरिक्त भेटींचा अंदाज लावतो. चाचणी कालावधीत संबंधित ऑफर, जाहिराती आणि कर्मचाऱ्यांद्वारे चालवल्या जाणाऱ्या जाहिरातींपासून त्यांना वगळून नियंत्रण गट दूषित होणार नाही याची काळजी घ्या.

प्रतिक्रियांना (feedback) देखील पावलांच्या संख्येइतकेच शिस्तीची गरज असते. जर तुम्ही पाहुण्यांना ते परत का आले असे विचारत असाल, तर मेसेज पाठवलेल्या आणि न पाठवलेल्या अशा दोन्ही पाहुण्यांसाठी TopFoodApp कडून एकसमान पाहुण्यांचा अभिप्राय फॉर्म वापरा, जेणेकरून उत्तरे केवळ ऑफर मिळालेल्या लोकांकडेच झुकणार नाहीत. सर्व्हेची उत्तरे संभाव्य कारणे स्पष्ट करतात, परंतु ते वर्तणुकीच्या तुलनेची जागा घेत नाहीत.

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

या महिन्यात एक छोटी चाचणी घ्या. एक जर्नी निवडा, यादृच्छिक होल्डआउट सेट करा आणि एक निकाल निश्चित करा, जसे की पुढील 30 दिवसांमधील भेटी. अशा प्रकारे CRM त्याची स्कोरकीपर भूमिका सिद्ध करते.

तुम्ही पाठवण्यापूर्वी संमती आणि मंजुरीच्या नियमांची पुष्टी करा

गव्हर्नन्स पाठवण्याच्या कार्यप्रवाहाचा भाग असले पाहिजे, कुणीही उघडून न पाहणाऱ्या गोपनीयता अपेंडिक्समध्ये नाही. मार्केटर्स आणि AI यावरील SAS अहवालात विश्वासातील ही तफावत स्पष्ट दिसते, जिथे 2025 च्या जागतिक सर्वेक्षणात 90% मार्केटर्सने एजेंटिक AI वर काही प्रमाणात विश्वास दाखवला, परंतु केवळ 5% लोकांनी पूर्ण विश्वास व्यक्त केला, आणि 48% लोकांचे असे मत होते की AI द्वारे तयार केलेल्या निर्णयांना मानवांनी मंजुरी दिली पाहिजे. त्याच अहवालातील स्वतंत्र संशोधनातून असे दिसून आले आहे की 77% मार्केटर्सनी एकतर मानवी देखरेखीसह कमी जोखमीच्या AI निर्णयांना किंवा AI द्वारे जनरेट केलेल्या इनसाइट्सनंतर मानवी अंतिम निर्णयांना प्राधान्य दिले.

पहिले मेसेज पाठवण्यापूर्वी नियंत्रणे तयार करा. टिकाऊ संमती रेकॉर्ड ठेवा जे कॅम्पेन मंजूर झाल्यावर आणि प्रत्येक मेसेज पाठवण्याच्या अगदी आधी पुन्हा तपासले जाते, कारण आमचा पाहुणा त्या दोन क्षणांच्या दरम्यान संमती रद्द (opt out) करू शकतो. ऑप्ट-आउट्स देखील टिकाऊ बनवा, जेणेकरून नंतरची बिल किंवा स्प्रेडशीट आयात ते बदलू शकणार नाही, आणि CRM संमती टूलची जागा घेते असे मानण्याऐवजी तुमच्या सध्याच्या संमती टूलसोबत काम करा.

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

1. ऑप्ट-इन शब्दांची खात्री करा: WiFi साइन-इन दरम्यान आणि CRM ला डेटा पुरवणाऱ्या प्रत्येक फॉर्मवरील तंतोतंत शब्दांची तपासणी करा.
2. सप्रेशन (suppression) ची चाचणी घ्या: एका नमुना पाहुण्याला ऑप्ट-आऊट करा, नवीन डेटा इंपोर्ट करा आणि तिला अजूनही कोणताही संदेश मिळत नसल्याची खात्री करा.
3. नामित व्यक्तीकडून मंजुरी घ्या: एका जबाबदार व्यक्तीने लक्ष्यित वर्ग (audience), मजकूर आणि वेळेला मंजुरी दिल्यानंतरच पहिली मोहीम (campaign) पाठवा.
4. ऑडिट लॉग तपासा: एका आठवड्यानंतर पुन्हा तपासा आणि मंजुरी, सप्रेशन्स आणि पाठवलेले संदेश ट्रॅक करण्यायोग्य असल्याची खात्री करा.

कोणत्याही CRM किंवा मेसेजिंग प्लॅटफॉर्मसाठी खरेदीचे प्रश्न म्हणून ते तपासणीचे नियम वापरा. ते तुमच्या विद्यमान संमती साधनासह संमतीची नोंद ठेवते का, काहीही पाठवण्यापूर्वी ते मंजुरी लागू करते का, आणि ते एकाच गुणवत्तेच्या आकड्याऐवजी holdout range सह निकालांचा अहवाल देते का? जर एखादा पुरवठादार स्पष्ट उत्तर देऊ शकत नसेल, तर ऑटोमेशनला ही उणीव लपवू देऊ नका.

---

तुमचे WiFi लॉगिन, बिल पावत्या, बुकिंग आणि मुक्काम अजूनही एकाच पाहुण्याचे वर्णन अनेक वेगवेगळे व्यक्ती म्हणून करत असल्यास, Purple Engage त्यांना सामायिक संमती, मंजुरी नियंत्रणे, विभाग (segments), प्रवास (journeys) आणि होल्डआउट मोजमापासह एकाच रेकॉर्डमध्ये आणते. अनेक ठिकाणे असलेल्या ठिकाणांसाठी पाहुण्यांची टाइमलाइन, कॅम्पेन मंजुरी आणि वाढीव भेटींचे रिपोर्टिंग कसे एकत्र काम करते हे पाहण्यासाठी साइटला भेट द्या.