अकाउंट इंटेलिजेंस के लिए गेस्ट WiFi के साथ Salesforce इंटीग्रेशन

पॉडकास्ट स्क्रिप्ट — "अकाउंट इंटेलिजेंस के लिए गेस्ट WiFi के साथ Salesforce इंटीग्रेशन" Purple टेक्निकल ब्रीफिंग सीरीज | रनटाइम: ~10 मिनट | UK English --- [परिचय और संदर्भ — 1 मिनट] Purple टेक्निकल ब्रीफिंग सीरीज में आपका स्वागत है। मैं आपका होस्ट हूँ, और आज हम कुछ ऐसा करने जा रहे हैं जो बहुत सारे B2B संगठनों के रोडमैप पर है लेकिन उन्होंने अभी तक इसे पूरी तरह से क्रैक नहीं किया है: वास्तविक अकाउंट इंटेलिजेंस उत्पन्न करने के लिए अपने गेस्ट WiFi इन्फ्रास्ट्रक्चर को सीधे Salesforce से जोड़ना। यदि आपके पास कोई वेन्यू है — एक कॉन्फ्रेंस सेंटर, एक होटल, एक ट्रेड शो फ्लोर, एक कॉर्पोरेट कैंपस — और आप गेस्ट WiFi चला रहे हैं, तो आप फर्स्ट-पार्टी इंटेंट डेटा की सोने की खान पर बैठे हैं। हर बार जब कोई संभावित ग्राहक, पार्टनर या ग्राहक आपके नेटवर्क से जुड़ता है, तो वे आपको कुछ बता रहे होते हैं। वे ऑन-साइट हैं। वे जुड़े हुए हैं। और अभी, अधिकांश संगठनों के लिए, वह सिग्नल हवा में गायब हो जाता है। आज हम जो कवर करने जा रहे हैं वह यह है कि इसे कैसे बदला जाए। उस WiFi ऑथेंटिकेशन इवेंट को Salesforce में कैसे रूट किया जाए, अपने मौजूदा अकाउंट्स के खिलाफ इसका मिलान कैसे किया जाए, और सही व्यावसायिक प्रतिक्रिया को कैसे ट्रिगर किया जाए — चाहे वह किसी अकाउंट एक्जीक्यूटिव को अलर्ट हो, कॉन्टैक्ट रिकॉर्ड को समृद्ध करना हो, या आपकी RevOps टीम के लिए कार्रवाई करने का कोई फ़्लैग हो। यह एक व्यावहारिक ब्रीफिंग है। हम आर्किटेक्चर, डेटा मॉडल के निर्णयों, GDPR विचारों और सामान्य कमियों से गुजरेंगे। आइए शुरू करते हैं। --- [तकनीकी विश्लेषण — 5 मिनट] आइए आर्किटेक्चर से शुरू करें। इसके मूल में, Salesforce WiFi इंटीग्रेशन के तीन घटक हैं: Captive Portal लेयर, इंटीग्रेशन मिडलवेयर और Salesforce डेटा मॉडल। Captive Portal — जो आपके मेहमान कनेक्ट होने पर देखते हैं — वह स्थान है जहाँ पहचान कैप्चर की जाती है। जब कोई आगंतुक ईमेल, LinkedIn या सोशल लॉगिन के माध्यम से ऑथेंटिकेट करता है, तो प्लेटफॉर्म एक सत्यापित ईमेल पता, एक टाइमस्टैम्प, एक वेन्यू पहचानकर्ता और सहमति रिकॉर्ड कैप्चर करता है। GDPR और UK डेटा प्रोटेक्शन एक्ट 2018 के तहत अंतिम वाला गैर-परक्राम्य (non-negotiable) है। आपको मार्केटिंग संचार के लिए स्पष्ट, विस्तृत सहमति की आवश्यकता है, और वह सहमति रिकॉर्ड संग्रहीत और ऑडिट करने योग्य होना चाहिए। Purple का प्लेटफॉर्म इसे मूल रूप से संभालता है, ऑथेंटिकेशन के बिंदु पर सहमति कैप्चर करता है और कॉन्टैक्ट डेटा के साथ Salesforce को एक सहमति फ़्लैग पास करता है। अब, इंटीग्रेशन मिडलवेयर वह जगह है जहाँ इंटेलिजेंस काम करती है। Purple का इंटीग्रेशन इंजन उस ऑथेंटिकेशन इवेंट को प्राप्त करता है और वह करता है जिसे हम आइडेंटिटी रेजोल्यूशन कहते हैं। पहला कदम डोमेन मैच है: ईमेल पता लें, डोमेन निकालें — मान लें, acme-corp.com — और मैचिंग वेबसाइट या ईमेल डोमेन फ़ील्ड वाले किसी भी Account रिकॉर्ड के लिए Salesforce से क्वेरी करें। यह आपका प्राथमिक मिलान संकेत है। यदि कोई डोमेन मैच मिल जाता है, तो मिडलवेयर फिर जांच करता है कि क्या उस विशिष्ट ईमेल पते के लिए कोई Contact रिकॉर्ड पहले से मौजूद है। यदि ऐसा है, तो आप मौजूदा रिकॉर्ड को अपडेट करते हैं — एक नई गतिविधि लॉग करते हैं, पिछली बार देखे गए टाइमस्टैम्प को अपडेट करते हैं, विज़िट काउंटर बढ़ाते हैं। यदि कोई Contact मौजूद नहीं है लेकिन Account मौजूद है, तो आप एक नया Contact बनाते हैं और उसे उस Account से जोड़ते हैं। यदि दोनों में से कोई भी मौजूद नहीं है — डोमेन अज्ञात है — तो आप एक Lead रिकॉर्ड बनाते हैं और समीक्षा के लिए इसे फ़्लैग करते हैं। यह थ्री-पाथ राउटिंग लॉजिक WiFi-स्रोत वाले कॉन्टैक्ट्स के लिए एक साफ Salesforce डेटा मॉडल की नींव है। इसका विकल्प — संदर्भ की परवाह किए बिना सब कुछ Lead के रूप में धकेलना — डेटा गुणवत्ता का वह दुःस्वप्न पैदा करता है जिससे अधिकांश RevOps टीमें डरती हैं: हजारों डुप्लिकेट लीड, कोई अकाउंट एसोसिएशन नहीं, और अकाउंट एक्जीक्यूटिव्स अपने मौजूदा व्यवसाय पर सिग्नल्स खो देते हैं। मुझे Salesforce डेटा मॉडल के बारे में अधिक विस्तार से बात करने दें, क्योंकि यहाँ आपके द्वारा लिए गए फ़ील्ड मैपिंग निर्णय दीर्घकालिक परिणाम देते हैं। Lead ऑब्जेक्ट पर, आप कैप्चर करना चाहते हैं: WiFi Venue Name, First Seen Date, Last Seen Date, Visit Count, Consent Status, और Lead Source को "Guest WiFi" जैसे मानकीकृत मान पर सेट करना। Contact ऑब्जेक्ट पर, वही फ़ील्ड लागू होते हैं, साथ ही पैरेंट Account का लुकअप। Account ऑब्जेक्ट पर, आप एक रोल-अप समरी फ़ील्ड चाहते हैं जो कुल WiFi-ऑथेंटिकेटेड कॉन्टैक्ट्स, एक Last Visitor Date फ़ील्ड और एक Visit Frequency स्कोर दिखाए। ये Account-स्तरीय फ़ील्ड ही इस इंटीग्रेशन को अकाउंट-आधारित बिक्री के लिए वास्तव में उपयोगी बनाते हैं। अब, अलर्ट मैकेनिज्म। यह वह जगह है जहाँ व्यावसायिक मूल्य मूर्त हो जाता है। Salesforce Flow का उपयोग करके — या यदि आप पुराने ऑर्ग पर हैं तो Process Builder का उपयोग करके — आप विशिष्ट स्थितियों के आधार पर ट्रिगर कॉन्फ़िगर करते हैं। सबसे मूल्यवान अलर्ट वह है जिसे हम "Target Account Visit" ट्रिगर कहते हैं: जब टारगेट अकाउंट के रूप में टैग किए गए Account से जुड़ा कोई Contact आपके WiFi से ऑथेंटिकेट करता है, तो असाइन किए गए Account Executive को कुछ ही मिनटों में एक Salesforce Task और एक Chatter नोटिफिकेशन प्राप्त होता है। संदेश सरल है: "Acme Corp के James अभी-अभी आपके Manchester वेन्यू पर कनेक्ट हुए हैं। उन्होंने इस तिमाही में तीन बार विज़िट की है।" यह एक वार्म आउटरीच सिग्नल है जिसके लिए अधिकांश सेल्स टीमें महत्वपूर्ण पैसा चुकाएंगी। और आप इसे निष्क्रिय रूप से उत्पन्न कर रहे हैं, उस इन्फ्रास्ट्रक्चर से जो आपके पास पहले से है। कॉन्फ़िगर करने योग्य दूसरा अलर्ट "Re-engagement" ट्रिगर है: एक Contact जो नब्बे से अधिक दिनों से निष्क्रिय है, आपके WiFi से कनेक्ट होता है। यह उन मंथन किए गए (churned) या ठंडे संपर्कों को सतह पर लाता है जो शारीरिक रूप से आपके दायरे में वापस आ गए हैं — नवीनीकरण (renewal) बातचीत के लिए एक मजबूत संकेत। तीसरा, "New Domain" अलर्ट: एक ईमेल डोमेन से WiFi साइन-इन जो किसी मौजूदा Account से मेल नहीं खाता है। यह क्वालिफिकेशन के लिए BDR या RevOps कतार में रूट होता है। हर अज्ञात डोमेन एक संभावित ग्राहक नहीं होता है, लेकिन कंपनी डोमेन के लिए फ़िल्टर करना — Gmail, Outlook और अन्य उपभोक्ता प्रदाताओं को छोड़कर — आपको एक उच्च-गुणवत्ता वाला पूर्वेक्षण (prospecting) संकेत देता है। तकनीकी इंटीग्रेशन पक्ष पर, Purple एक REST API प्रदर्शित करता है और आउटबाउंड वेबहुक का समर्थन करता है। Salesforce इंटीग्रेशन के लिए अनुशंसित पैटर्न वेबहुक-टू-मिडलवेयर दृष्टिकोण है: Purple प्रत्येक ऑथेंटिकेशन इवेंट पर एक वेबहुक फायर करता है, एक लाइटवेट मिडलवेयर लेयर — यह एक Salesforce Connected App, एक MuleSoft फ्लो, या एक साधारण AWS Lambda फ़ंक्शन हो सकता है — पेलोड प्राप्त करता है, डोमेन मिलान लॉजिक निष्पादित करता है, और उपयुक्त रिकॉर्ड को अपसर्ट करने के लिए Salesforce REST API को कॉल करता है। यह लॉजिक को Salesforce के बाहर रखता है, जिससे स्वतंत्र रूप से इसका रखरखाव और परीक्षण करना आसान हो जाता है। Salesforce के MuleSoft Anypoint प्लेटफॉर्म वाले संगठनों के लिए, Purple का API दस्तावेज़ एक प्री-बिल्ट कनेक्टर टेम्पलेट प्रदान करता है। बिना MuleSoft वाले लोगों के लिए, Purple के API की ओर इशारा करने वाली एक Salesforce External Service परिभाषा, एक Flow के साथ मिलकर, बिना किसी कस्टम कोड के समान परिणाम प्राप्त करती है। एक और तकनीकी विचार: MAC एड्रेस रैंडमाइजेशन। आधुनिक iOS और Android डिवाइस प्रत्येक नेटवर्क कनेक्शन पर अपने MAC एड्रेस को रैंडमाइज करते हैं, जिसका अर्थ है कि आप लौटने वाले आगंतुक ट्रैकिंग के लिए स्थायी डिवाइस पहचानकर्ता के रूप में MAC एड्रेस का उपयोग नहीं कर सकते। ऑथेंटिकेशन पर कैप्चर किया गया ईमेल पता आपका विश्वसनीय स्थायी पहचानकर्ता है। यह एक और कारण है कि CRM इंटीग्रेशन उद्देश्यों के लिए ईमेल-आधारित Captive Portal ऑथेंटिकेशन क्लिक-थ्रू या केवल-डिवाइस ऑथेंटिकेशन की तुलना में आर्किटेक्चरल रूप से बेहतर है। --- [इम्प्लीमेंटेशन सिफारिशें और कमियां — 2 मिनट] मुझे आपको वे चार चीजें बताने दें जो एक साफ-सुथरे डिप्लॉयमेंट को एक गड़बड़ डिप्लॉयमेंट से अलग करती हैं। पहला: लाइव होने से पहले अपनी डोमेन ब्लॉकलिस्ट को परिभाषित करें। उपभोक्ता ईमेल डोमेन — Gmail, Yahoo, Hotmail, iCloud, Outlook — को Account मैचिंग और Lead क्रिएशन से बाहर रखा जाना चाहिए। यदि आप ऐसा नहीं करते हैं, तो आप अपने Salesforce ऑर्ग को उपभोक्ता संपर्कों से भर देंगे जिनका कोई व्यावसायिक मूल्य नहीं है और यह आपकी सेल्स टीम के लिए डेटा गुणवत्ता को खराब कर देगा। एक प्रबंधित ब्लॉकलिस्ट बनाएं और इसे अपने मिडलवेयर लॉजिक में लागू करें। दूसरा: डिप्लॉयमेंट से पहले अपने RevOps लीड के साथ अपने Lead-से-Contact कन्वर्शन थ्रेशोल्ड पर सहमत हों। एक आम गलती WiFi इवेंट्स से Leads बनाना और उन्हें कभी कन्वर्ट न करना है, जिससे वे अनिश्चित काल के लिए Lead कतार में बैठे रहते हैं। एक नियम परिभाषित करें: यदि किसी ज्ञात कंपनी डोमेन से कोई Lead तीस दिनों के भीतर दो से अधिक बार विज़िट करता है, तो स्वचालित रूप से Contact में कन्वर्ट करें और मिलान किए गए Account से जोड़ें। यह आपकी पाइपलाइन को साफ रखता है और आपके AE को केंद्रित रखता है। तीसरा: सहमति आर्किटेक्चर को न छोड़ें। GDPR के तहत, आपको प्रोसेसिंग के लिए एक कानूनी आधार की आवश्यकता होती है, और मार्केटिंग संचार के लिए, वह आधार सहमति है। आपके Captive Portal को WiFi एक्सेस के लिए सेवा की शर्तों से अलग, मार्केटिंग के लिए एक स्पष्ट ऑप्ट-इन प्रस्तुत करना होगा। Purple का प्लेटफॉर्म विस्तृत सहमति श्रेणियों — WiFi एक्सेस, मार्केटिंग ईमेल, थर्ड-पार्टी शेयरिंग — का समर्थन करता है और इन्हें API पेलोड में बूलियन फ़्लैग के रूप में पास करता है। इन्हें सीधे Salesforce Contact फ़ील्ड में मैप करें और अपने मार्केटिंग ऑटोमेशन नियमों में इनका सम्मान करें। चौथा: पहले दिन से ही एरर लॉगिंग के साथ अपने इंटीग्रेशन को सुसज्जित करें। ऑथेंटिकेशन इवेंट्स जो मेल खाने या Salesforce रिकॉर्ड बनाने में विफल रहते हैं, उन्हें एक कस्टम Salesforce ऑब्जेक्ट या बाहरी मॉनिटरिंग टूल में लॉग किया जाना चाहिए। इसके बिना, आपके पास मूक विफलताएं (silent failures) होंगी — आगंतुक कनेक्ट हो रहे हैं लेकिन कोई रिकॉर्ड नहीं बन रहा है — और आपको तब तक पता नहीं चलेगा जब तक कि कोई यह नोटिस न करे कि डेटा कम दिख रहा है। --- [रैपिड-फायर प्रश्नोत्तर — 1 मिनट] ठीक है, आइए उन सवालों पर एक त्वरित प्रश्नोत्तर करें जो मैं अक्सर सुनता हूँ। "क्या मुझे Leads या Contacts में सिंक करना चाहिए?" — ज्ञात अकाउंट्स के लिए Contacts से शुरू करें, अज्ञात के लिए Leads से। सब कुछ कभी भी Leads में न धकेलें। "GDPR के बारे में क्या?" — पोर्टल पर सहमति, Salesforce में सहमति फ़्लैग, हर डाउनस्ट्रीम सिस्टम में इसका सम्मान करें। गैर-परक्राम्य। "मैं उन कॉन्फ्रेंस वेन्यू को कैसे संभालूँ जहाँ एक दिन में हजारों लोग कनेक्ट होते हैं?" — अपने वेबहुक प्रोसेसिंग को रेट-लिमिट करें, अपने Salesforce अपसर्ट को बैच करें, और उच्च-मात्रा वाले इवेंट्स के लिए Salesforce Bulk API का उपयोग करें। स्टेडियम-स्तरीय डिप्लॉयमेंट के लिए मानक REST API का उपयोग न करें। "क्या मैं इसका उपयोग ABM के लिए कर सकता हूँ?" — बिल्कुल। Salesforce में अपने टारगेट अकाउंट्स को टैग करें, उन अकाउंट्स से किसी भी WiFi विज़िट पर अपने AE को सचेत करने के लिए एक Flow कॉन्फ़िगर करें, और आपके पास एक भौतिक इंटेंट सिग्नल है जिसे कोई भी डिजिटल ABM टूल दोहरा नहीं सकता है। "ROI क्या है?" — Purple के Salesforce इंटीग्रेशन का उपयोग करने वाले संगठन मौजूदा अकाउंट्स पर AE-शुरू की गई आउटरीच में 20 से 35 प्रतिशत की वृद्धि की रिपोर्ट करते हैं, जो पूरी तरह से WiFi विज़िट अलर्ट द्वारा संचालित होती है। WiFi-स्रोत वाले संपर्कों से प्रभावित पाइपलाइन आमतौर पर कोल्ड आउटरीच की तुलना में 15 से 25 प्रतिशत अधिक क्लोज रेट दिखाती है, क्योंकि आगंतुक ने भौतिक जुड़ाव प्रदर्शित किया है। --- [सारांश और अगले कदम — 1 मिनट] समाप्त करने के लिए: Salesforce WiFi इंटीग्रेशन एक परिपक्व, डिप्लॉय करने योग्य क्षमता है जो निष्क्रिय नेटवर्क इन्फ्रास्ट्रक्चर को एक सक्रिय अकाउंट इंटेलिजेंस सिग्नल में बदल देती है। आर्किटेक्चर सीधा है — Captive Portal, आइडेंटिटी रेजोल्यूशन मिडलवेयर, Salesforce अपसर्ट — लेकिन मूल्य डेटा मॉडल के निर्णयों, अलर्ट कॉन्फ़िगरेशन और डेटा गुणवत्ता गवर्नेंस में है जो आप इसके चारों ओर रखते हैं। आपके तत्काल अगले कदम: डोमेन फ़ील्ड पूर्णता के लिए अपने वर्तमान Salesforce Account रिकॉर्ड का ऑडिट करें — यह आपका मिलान आधार है। Lead-बनाम-Contact राउटिंग नियमों को परिभाषित करने के लिए अपने RevOps लीड को शामिल करें। और API पेलोड संरचना और उपलब्ध वेबहुक इवेंट्स को समझने के लिए Purple के Salesforce इंटीग्रेशन दस्तावेज़ों की समीक्षा करें। यदि आप ऐसे वेन्यू पर गेस्ट WiFi चला रहे हैं जहाँ आपके ग्राहक या संभावित ग्राहक आते हैं, तो यह इंटीग्रेशन एक तिमाही के भीतर लाइव होना चाहिए। डेटा वहाँ है। आपको बस इसे कनेक्ट करना है। सुनने के लिए धन्यवाद। यदि आप आज कवर किए गए किसी भी विषय पर गहराई से जाना चाहते हैं, तो पूर्ण तकनीकी संदर्भ गाइड purple.ai पर उपलब्ध है। हम आपको अगली ब्रीफिंग में मिलेंगे। --- [स्क्रिप्ट का अंत]