रेस्टोरेंट CRM सॉफ़्टवेयर: सुविधाएं और चयन कैसे करें
रेस्टोरेंट CRM सॉफ़्टवेयर WiFi, टिल और बुकिंग को एक ही अतिथि रिकॉर्ड में जोड़ता है। सुविधाएं, खरीदारी के परीक्षण और वास्तविक बार-बार आने वाले आगंतुकों को मापने का तरीका देखें।
लोकप्रिय सलाह अभियान बिल्डरों, लॉयल्टी फ़ीचर्स और ईमेल टेम्पलेट्स की तुलना करके रेस्तरां CRM फ़ैब्रिक चुनने की है। वह क्रम उल्टा है। यदि सिस्टम आपके WiFi, टिल और बुकिंग में मेहमानों का मिलान नहीं कर सकता है, या टूल के बीच रिकॉर्ड स्थानांतरित होने पर उनकी सहमति को सुरक्षित नहीं रख सकता है, तो अधिक अभियान फ़ीचर्स केवल आपको एक विखंडित दर्शकों को अधिक संदेश भेजने में मदद करते हैं।
सुविधा दौरे के बजाय एक पायलट से शुरुआत करें। प्रतिबद्ध होने से पहले विक्रेता से यह साबित करवाएं कि अतिथि की पहचान मेल खाती है, ऑप्ट-आउट आयात से बच जाते हैं, और एक होल्डआउट समूह अधिक बार लौटता है।
विषय-सूची
- रेस्तरां CRM सॉफ़्टवेयर को क्या करना चाहिए
- एक ही ग्राहक कई रिकॉर्ड में क्यों बदल जाता है
- वे सिस्टम जो अतिथि रिकॉर्ड में डेटा जोड़ते हैं
- खरीदने से पहले किए जाने वाले परीक्षण
- ऐसे ऑफ़र जो रियायत देने के बजाय नए विजिट जनरेट करते हैं
- साइन अप करने से पहले इंक्रीमेंटल विजिट साबित करें
रेस्टोरेंट CRM सॉफ़्टवेयर को क्या करना चाहिए
| क्षमता | यह क्या संभालता है | यह क्यों महत्वपूर्ण है |
|---|---|---|
| अतिथि पहचान | ईमेल के आधार पर WiFi, टिल, बुकिंग और स्टे रिकॉर्ड को मैच करता है | एक नियमित ग्राहक चार अलग संपर्क न बने |
| सहमति लेजर | रिकॉर्ड करता है कि किसने, कब, किस चैनल पर और किन शब्दों के साथ सहमति दी | डेटा इंपोर्ट करने से ऑप्ट-आउट का फ़ैसला बदलना नहीं चाहिए |
| सेगमेंट | विज़िट, खर्च, टैग और सर्वे के उत्तरों का उपयोग करता है | निष्क्रिय ग्राहकों को खोजता है, जैसे 45 दिनों में कोई विजिट नहीं |
| जर्नी | WiFi जॉइन, खरीदारी, बुकिंग या चेकआउट पर ट्रिगर होता है | संदेश वास्तविक विजिट के बाद भेजा जाता है |
| ऑफ़र | कैप, बजट, समय सीमा और प्रति अतिथि एक बार उपयोग होने वाला कोड लागू करता है | असीमित छूट की लागत को रोकता है |
| मापन | होल्डआउट ग्रुप का उपयोग करता है और इंक्रीमेंटल विजिट को ट्रैक करता है | अभियान के प्रभाव को सामान्य आदत से अलग करता है |
ये पास-या-फ़ेल होने वाले कार्य हैं, न कि अच्छे-से-होने वाले फ़ीचर्स की सूची। एक सामान्य ईमेल प्लेटफ़ॉर्म नाम और पता स्टोर कर सकता है, लेकिन केवल वही किसी खरीदारी को बुकिंग से नहीं जोड़ेगा या यह नहीं दिखाएगा कि क्या किसी अभियान ने किसी को वापस लाया। यदि कोई उत्पाद पायलट में गेस्ट आइडेंटिटी और होल्डआउट मेजरमेंट का प्रदर्शन नहीं कर सकता है, तो टेम्पलेट्स की तुलना करने से पहले इसे अस्वीकार कर दें।
गेस्ट रिकॉर्ड से शुरुआत करें
एक रेस्टोरेंट CRM को भोजन के पूरे अनुभव के दौरान होने वाली बातचीत को एकत्र करना चाहिए, उन्हें एक व्यक्ति से जोड़ना चाहिए, और परिणामी टाइमलाइन को मैसेजिंग और मापन के लिए उपयोगी बनाना चाहिए। ईमेल एक व्यावहारिक मिलान कुंजी हो सकता है जब इसे लगातार कैप्चर किया जाता है, लेकिन यह कोई जादू नहीं है: मेहमान विभिन्न पतों का उपयोग कर सकते हैं, एक पता साझा कर सकते हैं, या अपनी पहचान बताए बिना भुगतान कर सकते हैं। अपने स्थानों के वास्तविक, अज्ञात (de-identified) रिकॉर्ड का उपयोग करके उन अपवाद स्थितियों (edge cases) का परीक्षण करें, और सहमति व्यक्त करें कि कौन सी प्रणाली किस फ़ील्ड का स्वामित्व रखती है।
सेगमेंट को सामान्य बिक्री चरणों के बजाय रेस्तरां के व्यवहार को प्रतिबिंबित करने की आवश्यकता है। उदाहरण के लिए, एक "लैर्स्ड" सेगमेंट नियम का उपयोग कर सकता है जैसे कि 45 दिनों में कोई दर्ज की गई विजिट नहीं, जबकि अन्य समूह विजिट आवृत्ति, खर्च, टैग या सर्वेक्षण उत्तरों से बनाए जा सकते हैं। एक सेगमेंट जो डेमो में व्यवस्थित दिखता है लेकिन नियमित ग्राहकों को छोड़ देता है क्योंकि उनकी बुकिंग और टिल रिकॉर्ड कनेक्ट नहीं होते हैं, उपयोगी नहीं है।
सेंड्स को नियंत्रित संचालन के रूप में लें
सहमति के रिकॉर्ड को सदस्यता चेकबॉक्स से अधिक की आवश्यकता होती है। इसे वह चैनल और उद्देश्य याद रखना चाहिए जिसके लिए अतिथि सहमत हुआ था, वह शब्दावली जो उन्होंने देखी थी, और उन्होंने अनुमति कब और कहाँ दी थी। रिकॉर्ड आयात या मर्ज किए जाने पर भी दमन लागू होना चाहिए।
इसी तरह, किसी ऑफ़र के लाइव होने से पहले उसकी ऑपरेटिंग सीमाएँ होनी चाहिए। एक बजट और समय सीमा निर्धारित करें, रिडेम्प्शन को सीमित करें, और उपयुक्त होने पर सिंगल-यूज़ कोड का उपयोग करें। ये नियंत्रण टीम को अभियान चलाने के बाद उसके पैमाने की खोज करने के बजाय छूट के जोखिम को सीमित करने में मदद करते हैं।
खरीदार का नियम: किसी चमकदार अभियान डेमो के बल पर न खरीदें। केवल तभी खरीदें जब विक्रेता यह साबित कर दे कि वह एक विश्वसनीय अतिथि रिकॉर्ड बना सकता है और एक नियंत्रण समूह के खिलाफ व्यवहार को माप सकता है।
एक ही गेस्ट कई रिकॉर्ड क्यों बन जाता है
इससे पहले कि कोई रेस्तरां अपने सिस्टम को कनेक्ट करे, प्रत्येक चैनल अपनी नोटबुक रखता है। टिल में एक लेन-देन होता है, रिज़र्वेशन बुक में एक बुकिंग होती है, WiFi पोर्टल में एक लॉगिन होता है, और ईमेल टूल में एक संपर्क होता है। एक ही गेस्ट इन चारों में दिखाई दे सकता है, और प्रत्येक में अलग-अलग तरीके से दर्ज हो सकता है।
जैसे-जैसे ऑर्डरिंग ऑनलाइन होती गई, यह विखंडन और अधिक महत्वपूर्ण होता गया। FinancesOnline के रेस्तरां सॉफ़्टवेयर आंकड़ों के सारांश के अनुसार, डिजिटल ऑर्डरिंग प्लेटफ़ॉर्म बिक्री में महामारी शुरू होने के बाद 313% की वृद्धि हुई और दिसंबर 2020 तक यह महामारी से पहले के स्तर से 452% अधिक थी, जब डिजिटल ऑर्डर सभी रेस्तरां ऑर्डर का 28% थे। प्रत्येक अतिरिक्त ऑर्डरिंग चैनल उपयोगी गतिविधि उत्पन्न कर सकता है, लेकिन केवल तभी जब रेस्तरां इसे किसी अतिथि की पहचान और उस पहचान से जुड़ी अनुमतियों से जोड़ सके।
सिस्टम के माध्यम से एक गेस्ट को फॉलो करें
मान लीजिए कि कोई ग्राहक Captive Portal के माध्यम से गेस्ट WiFi से जुड़ता है, एक ईमेल दर्ज करता है, शर्तों को स्वीकार करता है, और मार्केटिंग के लिए ऑप्ट-इन करता है। WiFi रिकॉर्ड में ईमेल, विज़िट की तारीख, रुकने का समय और पसंदीदा स्थान शामिल हो सकते हैं। जब ग्राहक बाद में उसी ईमेल का उपयोग करके टेबल बुक करता है या टिल से खरीदारी करता है, तो वे इवेंट उसी गेस्ट टाइमलाइन से जुड़ सकते हैं।
वह टाइमलाइन किसी स्थान को एड्रेस लिस्ट की तुलना में काम करने के लिए बहुत कुछ देती है। Purple Engage प्रत्येक गेस्ट के लिए 60 से अधिक इवेंट प्रकारों को रिकॉर्ड करता है, जिसमें WiFi साइन-इन, खरीदारी, बुकिंग, चेक-आउट, फॉर्म सबमिशन, अभियान गतिविधि और सर्वेक्षण प्रतिक्रियाएं शामिल हैं। इसके 36 ऑटोमेशन ट्रिगर्स में WiFi से जुड़ना, खरीदारी करना, बुकिंग पूरी करना और प्रवास से चेक-आउट करना शामिल है। व्यावहारिक बिंदु इवेंट कैटलॉग का आकार नहीं है। यह बात महत्वपूर्ण है कि क्या प्रासंगिक इवेंट आता है, सही व्यक्ति से जुड़ता है, और एक उपयुक्त अगला कदम ट्रिगर करता है।
केवल भेजने को नहीं, बल्कि रिटर्न को मापें
40 स्थानों वाले एक रेस्तरां समूह ने पहले से ही Mailchimp का उपयोग किया और 35% ओपन रेट दर्ज की। अपने Cisco Meraki नेटवर्क पर Purple Engage को तैनात करने के बाद, समूह ने एक जन्मदिन माह ऑफ़र और एक लैर्स्ड डिनर अभियान चलाया और प्रत्येक अभियान से जुड़े फ़ुटफ़ॉल की रिपोर्ट कर सका। जब नेटवर्क किसी रिटर्न विजिट पर अतिथि के डिवाइस को पहचानता है, तो विजिट को बिना किसी QR कोड या वाउचर स्कैन के अभियान के खिलाफ लॉग किया जा सकता है।
ओपन रेट यह दर्शा सकता है कि एक ईमेल खोला गया था, लेकिन यह ऑपरेटर को यह नहीं बता सकता कि ग्राहक उस संदेश के कारण वापस आया था या नहीं। एक कनेक्टेड टाइमलाइन के माध्यम से बुकिंग, खरीदारी या उसके बाद की अन्य गतिविधियों के साथ-साथ रिटर्न विजिट की जांच करना संभव हो जाता है। यह निर्णय लेने का एक अधिक उपयोगी आधार है कि क्या कोई अभियान दोबारा भेजे जाने के योग्य है या नहीं।
सिस्टम जो गेस्ट रिकॉर्ड को फ़ीड करने चाहिए
एक और लॉगिन जोड़ने से पहले अपने मौजूदा सिस्टम का इन्वेंट्री करें। एक रेस्तरां CRM को उन टूल को पढ़ना चाहिए जो पहले से ही मेहमानों के इंटरैक्शन को संभालते हैं, न कि बुकिंग इंजन या भुगतान प्रणाली को बदलने की कोशिश करनी चाहिए। स्टैक के टिल पक्ष पर अधिक विस्तृत नज़र डालने के लिए, व्यस्त डिनर सेवाओं के लिए POS चुनना आपको यह सोचने में मदद कर सकता है कि भुगतान प्रणाली को CRM से स्वतंत्र रूप से क्या करने की आवश्यकता है।
| स्रोतः | नामित प्रणालियां | स्थिति |
|---|---|---|
| Guest WiFi | Purple WiFi | लाइव |
| Guest WiFi | Cisco Meraki, Cisco Spaces | पायलट |
| Guest WiFi | Juniper Mist | लाइव |
| टिल (Tills) | Square, Epos Now, Loyverse | लाइव |
| टिल (Tills) | Lightspeed X-Series, Oracle Simphony | पायलट |
| बुकिंग | ResDiary | पायलट |
| स्टे (Stays) | Mews, apaleo | पायलट |
| हेड ऑफिस CRM और ईमेल सिंक | HubSpot, Salesforce, Mailchimp | लाइव |
| फाइनेंस एक्सट्रैक्ट्स और कस्टम जॉइन्स | Google Sheets, सार्वजनिक API, साइन किए गए वेबहुक | उपलब्ध |
एक "लाइव" कनेक्शन और एक "पायलट" कनेक्शन आपस में बदले जाने योग्य नहीं हैं। Purple Engage के वर्तमान एकीकरणों में, Purple WiFi, Juniper Mist, Square, Epos Now, और Loyverse से डेटा कैप्चर किया जा सकता है; Cisco Spaces, Cisco Meraki, Lightspeed X-Series, Oracle Simphony, ResDiary, Mews, और apaleo पायलट में हैं। HubSpot, Salesforce, और Mailchimp दोनों दिशाओं में गेस्ट रिकॉर्ड सिंक कर सकते हैं। यदि आप कस्टम रिपोर्टिंग की योजना बना रहे हैं, तो यह तय करने से पहले कि फाइनेंस एक्सट्रैक्ट या बेस्पोक जॉइन कैसे काम करेंगे, जानें कि वेबहुक और API प्रत्येक क्या करते हैं।
प्लेटफ़ॉर्म की सीमाओं को स्पष्ट रखें
इस प्रकार का प्लेटफॉर्म कोई बुकिंग इंजन, पॉइंट्स स्कीम, भुगतान प्रदाता या कुकी बैनर नहीं है। इसे आपके मौजूदा सहमति टूल के साथ मिलकर काम करना चाहिए। यह टिल में बिक्री को वापस दर्ज करने के बजाय टिल डेटा को पढ़ता है, और टिल पर रिडेम्पशन समर्थित प्रणालियों पर एक पायलट बना रहता है, इसलिए यह मान न लें कि प्रत्येक ऑफर कोड पहले दिन चेकआउट पर स्कैन हो जाएगा।
एक साधारण स्टैक इन्वेंट्री बनाएं जिसमें गेस्ट ईमेल रखने वाले प्रत्येक सिस्टम के लिए एक रो (row) हो। प्रत्येक कनेक्शन को लाइव या पायलट के रूप में चिह्नित करें, डेटा के मालिक का नाम बताएं, और ध्यान दें कि सिंक विफल होने पर क्या होता है। ऐसे किसी भी विक्रेता को हटा दें जो पायलट से कार्यशील कनेक्शन को स्पष्ट रूप से अलग नहीं कर सकता है या यह नहीं समझा सकता है कि कौन सा डेटा किस दिशा में जाता है।
खरीदने से पहले किए जाने वाले परीक्षण
कई खरीदारी मार्गदर्शिकाएं अभियान सुविधाओं से शुरू होती हैं। अधिक महत्वपूर्ण सवाल यह है कि क्या मेहमान डेटा को मज़बूती से सक्रिय किया जा सकता है। 2025 रेस्टोरेंट बिज़नेस डिजिटल टेक्नोलॉजी रिपोर्ट में, 36% रेस्टोरेंट ऑपरेटरों ने कहा कि उन्होंने निश्चित रूप से या संभवतः अपने द्वारा एकत्र किए गए ग्राहक डेटा को अनुकूलित किया है, जो पिछले वर्ष के 45% से कम है। इंटीग्रेशन और API में नियोजित निवेश 14% से बढ़कर 20% हो गया, जबकि डेटा प्रबंधन और सुरक्षा में नियोजित निवेश 17% से बढ़कर 26% हो गया। यदि कोई नया CRM पहचान, डेटा स्वामित्व और सिंक व्यवहार को ठीक किए बिना केवल सुविधाएं जोड़ता है, तो वह विखंडन को और बढ़ा सकता है।
एक वास्तविक पायलट का उपयोग करें और प्रत्येक परीक्षण को पास या फ़ेल स्कोर करें। कोर डेटा पथ काम करने तक टेम्पलेट दीर्घाओं की तुलना न करें।
| परीक्षण | सफल ऐसा दिखता है | विफल ऐसा दिखता है |
|---|---|---|
| पहचान मिलान | एक ही ईमेल सभी साइटों पर WiFi, टिल और बुकिंग रिकॉर्ड को मर्ज करता है | डुप्लिकेट मेहमान और छूटे हुए नियमित ग्राहक |
| फ़ील्ड स्वामित्व | एक प्रणाली प्रत्येक फ़ील्ड के लिए सत्य का स्रोत है | दो टूल एक-दूसरे को ओवरराइट करते हैं |
| सहमति अस्तित्व | आयात के बाद भी ऑप्ट-आउट दबा हुआ रहता है और भेजने पर दोबारा जांचा जाता है | आयात ऑप्ट-आउट को वापस चालू कर देता है |
| ताज़ा करने की गति | व्यवहार संबंधी खंड लगभग एक मिनट के भीतर अपडेट हो जाते हैं | केवल रातोंरात बैच |
| ऐतिहासिक पोर्टेबिलिटी | अतीत की यात्राएं और बिक्री अतिथि रिकॉर्ड पर लोड होती हैं | केवल नए साइन-अप ही गिने जाते हैं |
| विफलता से उबरना | टूटा हुआ सिंक दिखाई देता है और घटनाओं को चुपचाप नहीं छोड़ा जाता है | बिना किसी अलर्ट के डेटा अंतराल |
| वृद्धिशील प्रमाण | होल्डआउट अतिरिक्त यात्राएं या खरीदारी दिखाता है | केवल ओपन और क्लिक |
केवल सफल पथ ही नहीं, बल्कि विफलता के मामलों का भी परीक्षण करें
एक से अधिक स्थानों पर WiFi, टिल और बुकिंग रिकॉर्ड में समान टेस्ट ईमेल का उपयोग करें। फिर जानबूझकर एक डुप्लिकेट, एक परस्पर विरोधी फ़ील्ड, एक बदला हुआ ईमेल और एक सिंक व्यवधान पेश करें। एक सक्षम प्लेटफ़ॉर्म को गलत गेस्ट को मर्ज करने या गतिविधि को छोड़ने के बजाय परिणाम को दृश्यमान बनाना चाहिए।
सहमति (consent) के लिए, पूरा पाथ चलाएं: मेहमान का ऑप्ट-आउट रिकॉर्ड करें, उस संपर्क के किसी पुराने संस्करण को इंपोर्ट करें, और भेजने का प्रयास करें। मैसेज भेजने की प्रक्रिया ब्लॉक रहनी चाहिए। सहमति को एक ही सूची की सदस्यता वाले फ़ील्ड से अनुमान लगाने के बजाय, उद्देश्य और चैनल के अनुसार दर्ज किया जाना चाहिए, जिसमें मेहमान की पसंद का एक स्थायी इतिहास हो। सहमति रिकॉर्ड करने और प्रबंधित करने पर ICO का मार्गदर्शन ऐसे रिकॉर्ड की मांग करता है जो यह दिखाते हों कि किसने सहमति दी, कब दी, उन्होंने कौन सी जानकारी और शब्द देखे, और सहमति कैसे एकत्र की गई थी। यूरोपीय आयोग का सहमति मार्गदर्शन भी यह स्पष्ट करता है कि सहमति स्वेच्छा से, सूचित होकर, विशिष्ट और केवल उजागर किए गए उद्देश्यों तक ही सीमित होनी चाहिए।
डैशबोर्ड में हरी बत्ती ही काफी नहीं है। विक्रेता से दिखाएं कि जब कोई रिकॉर्ड गलत होता है, सिंक टूटता है, या ऑप्ट-आउट किसी आयातित संपर्क से मिलता है, तो ऑपरेटर क्या देखता है।
ऑफ़र जो सब्सिडी देने के बजाय विज़िट बढ़ाते हैं
भुनाया गया ऑफर यह साबित नहीं करता कि उसने विज़िट उत्पन्न की है। भारी डिस्काउंट नियमित ग्राहकों को वही काम करने के लिए पैसे दे सकते हैं जो वे वैसे भी करते, इसलिए किसी अभियान का मूल्यांकन उससे उत्पन्न अतिरिक्त व्यवहार और उसकी लागत के बाद बचे मार्जिन से करें। भोजन करने वाले प्रासंगिकता को महत्व देते हैं: 2025 Restaurant Consumer Insights Report के अनुसार, 46% ग्राहक पिछले ऑर्डर और प्राथमिकताओं के आधार पर संदेशों की सराहना करते हैं, और 61% मुफ़्त भोजन या पेय के लिए पॉइंट्स को प्राथमिकता देते हैं। वे प्राथमिकताएं लक्षित संदेशों के परीक्षण का समर्थन करती हैं, न कि यह मान लेने का कि पर्सनलाइजेशन किसी ऑफर को लाभदायक बना देता है।
अभियान प्राप्त करने वाले समूह की तुलना बेतरतीब ढंग से असाइन किए गए होल्डआउट से करें जिसे कोई अभियान प्राप्त नहीं होता है। एक स्पष्ट निष्क्रियता नियम सेट करें, जैसे 45 दिनों में कोई विजिट नहीं, फिर ट्रीटमेंट ग्रुप को व्यवहार-ट्रिगर विन-बैक संदेश भेजें। विजिट दरों की तुलना करें और अनिश्चितता का हिसाब रखें। रैंडम असाइनमेंट अभियानों के प्रभाव को मेहमानों की वापस लौटने की मौजूदा संभावना से अलग करने में मदद करता है।
गणना करें कि ऑफर ने क्या जोड़ा
ट्रीटमेंट ग्रुप की विज़िट दर से कंट्रोल ग्रुप की विज़िट दर घटाकर इंक्रीमेंटल विज़िट का अनुमान लगाएं। फिर एट्रिब्यूटेबल ट्रांजैक्शन से जुड़े लाभ में से डिस्काउंट, मैसेजिंग लागत और अभियान लागत को घटाकर इंक्रीमेंटल ग्रॉस प्रॉफिट का अनुमान लगाएं। रिटेंशन बेंचमार्क संदर्भ प्रदान करते हैं, लेकिन यह साबित नहीं कर सकते कि किसी विशिष्ट प्रमोशन के कारण ही ग्राहक वापस आया। DoorDash की रेस्टोरेंट कस्टमर-रिटेंशन गाइडेंस रिपोर्ट बताती है कि ग्राहक रिटेंशन में 5% का सुधार लाभ को लगभग 25% से 95% तक बढ़ा सकता है। इसे एक बेंचमार्क मानें, न कि अपने अभियान का पूर्वानुमान।
Purple Engage रेस्तरां के लिए 14 दिनों की एट्रिब्यूशन विंडो से शुरू करने और इसे स्थान की प्राकृतिक विजिट आवृत्ति के अनुसार समायोजित करने की सलाह देता है। एक सामान्य छूट, एक व्यवहार आधारित पुरस्कार, गैर-मौद्रिक मान्यता और बिना किसी ऑफ़र की तुलना करें। रिडेम्पशन के साथ-साथ मार्जिन और अनसब्सक्राइब को ट्रैक करें। मजबूत रिडेम्पशन का मतलब अभी भी कमजोर परिणाम हो सकता है यदि नियमित ग्राहक उन विजिट के लिए कोड का उपयोग करते हैं जो वे वैसे भी करते।
यह मानने के बजाय कि हर गेस्ट को छूट की आवश्यकता है, किसी गैर-मौद्रिक संदेश, जैसे कि शुरुआती एक्सेस या मान्यता के खिलाफ एक व्यक्तिगत प्रचार का परीक्षण करें। रेस्तरां के लिए डिस्काउंट बनाम एडेड वैल्यू ऑफर की मार्गदर्शिका उस विकल्प को तैयार करने में मदद कर सकती है।
ऑपरेटर द्वारा रिपोर्ट किए गए वफादारी परिणाम, जिसमें रेस्तरां-मालिक के सर्वेक्षण शामिल हैं, कथित लाभों का संकेत दे सकते हैं, लेकिन वे नियंत्रित परीक्षण से प्राप्त प्रमाण नहीं हैं। अपने कार्यक्रम का मूल्यांकन नामांकन की कुल संख्या या रिवॉर्ड रिडेम्पशन के बजाय वृद्धिशील व्यवहार और मार्जिन के आधार पर करें।
प्रतिबद्ध होने से पहले वृद्धिशील विज़िट साबित करें
निर्णय को एक स्टॉप-गो अनुक्रम बनाएं। किसी CRM को सिर्फ इसलिए लंबा अनुबंध नहीं मिलना चाहिए क्योंकि उसका डेमो आकर्षक लग रहा था। इसे डेटा पथ को साबित करके और यह दिखाकर एक अनुबंध अर्जित करना चाहिए कि एक अभियान ने अतिथि के व्यवहार को बदल दिया।
मेहमान का मिलान करें। पुष्टि करें कि वही व्यक्ति WiFi, टिल और बुकिंग के माध्यम से जुड़ता है, जिसके लिए आपके स्थान द्वारा एकत्र किए गए पहचान नियमों का उपयोग किया जाता है। यदि जुड़ाव विफल हो जाता है, तो अभियान टूल खरीदने से पहले रुकें और डेटा समस्या को ठीक करें।
अनुमति की रक्षा करें। पुष्टि करें कि ऑप्ट-आउट आयात या विलय के बाद भी लागू रहता है और प्रत्येक भेजने से ठीक पहले फिर से जांचा जाता है। यदि बाद का आयात अनुमति को पुनर्स्थापित कर सकता है, तो आगे न बढ़ें।
एक वास्तविक अभियान का परीक्षण करें। चुने गए एट्रिब्यूशन विंडो का उपयोग करके, एक वास्तविक होल्डआउट के खिलाफ निष्क्रिय-डाइनर यात्रा और जन्मदिन या यात्रा-प्रेरित प्रस्ताव चलाएं। आतिथ्य से बाहर नियंत्रित माप पर एक उपयोगी प्राइमर के लिए, DTC ब्रांडों के लिए विज्ञापन प्रभाव को मापना एक नियंत्रण समूह के साथ उजागर दर्शकों की तुलना करने के तर्क को समझाता है। रेस्तरां को उस अनुशासन को यात्राओं और खरीदारी पर लागू करना चाहिए, न कि क्लिकों को अंतिम परिणाम मानना चाहिए। Meta का उपयोग करने वाले अभियानों के लिए, रेस्तरां के लिए Conversions API मार्गदर्शन रूपांतरण घटनाओं को कैसे साझा किया जाता है, इसके अलग प्रश्न को फ्रेम करने में मदद कर सकता है।
व्यावसायिक मॉडल की जाँच करें। केवल मुख्य योजना मूल्य की नहीं, बल्कि प्रति वृद्धिशील यात्रा कुल लागत की तुलना करें। सेंड और AI क्रेडिट, ओवरएज, स्थानीय करों और किस योजना में आपके द्वारा आवश्यक वॉल्यूम शामिल है, का हिसाब रखें। Purple Engage की हर योजना पर असीमित संपर्क हैं, जिसमें इसकी मुफ्त योजना भी शामिल है; इसकी 15,000-क्रेडिट योजना की लागत £27 प्रति माह या £293 सालाना भुगतान है, जिसमें 10% की वार्षिक बचत शामिल है। सूचीबद्ध कीमतों में जहां यह लागू होता है वहां VAT शामिल है, जिसमें UK में 20% VAT शामिल है।
AI द्वारा ड्राफ्ट की गई किसी भी चीज़ को किसी व्यक्ति द्वारा अनुमोदित किए बिना संदेश भेजना या शुल्क नहीं लगाना चाहिए। Purple Engage इस पायलट को गेस्ट WiFi और कनेक्टेड टिल वाले स्थानों पर चला सकता है, स्थल डेटा को पढ़ सकता है और अभियान फुटफ़ॉल को उसी स्कोरकार्ड के खिलाफ रिपोर्ट कर सकता है जिसे आप किसी अन्य विक्रेता के लिए उपयोग करेंगे। यदि पायलट किसी सीमा के साथ इंक्रीमेंटल विज़िट नहीं दिखा सकता है, तो अपने वर्तमान टूल को बनाए रखें और पहले डेटा जॉइन को ठीक करें।
Purple Engage WiFi साइन इन, टिल रसीदों, बुकिंग और मेहमानों के ठहराव को सहमति नियंत्रण, अभियानों और होल्डआउट आधारित मापन के साथ एक एकीकृत गेस्ट रिकॉर्ड में जोड़ता है। यदि आप यह जांचने के लिए तैयार हैं कि क्या आपका डेटा वास्तविक रिटर्न विजिट साबित कर सकता है, तो Purple Engage पर जाएं और अपने पायलट स्कोरकार्ड के आधार पर इसका आकलन करें।