हॉटेल अतिथी WiFi व्यवस्थापन: PMS, पोर्टल्स आणि ब्रँड मानके यांचे एकत्रीकरण

Purple च्या टेक्निकल ब्रीफिंगमध्ये आपले स्वागत आहे. आज आपण हॉटेल अतिथी WiFi व्यवस्थापन कव्हर करत आहोत - विशेषतः तुमची प्रॉपर्टी मॅनेजमेंट सिस्टम, तुमचे captive portals आणि तुमचे ब्रँड मानके एका सुसंगत, अनुपालन करणाऱ्या आणि व्यावसायिकदृष्ट्या मूल्यवान नेटवर्क आर्किटेक्चरमध्ये कसे समाकलित करायचे. तुम्ही एखाद्या सिंगल प्रॉपर्टीचे IT व्यवस्थापक असाल, संपूर्ण पोर्टफोलिओचे नेटवर्क आर्किटेक्ट असाल किंवा बहु-वर्षीय पायाभूत सुविधा नूतनीकरणाला मंजुरी देणारे CTO असाल, तर हे ब्रीफिंग तुमच्यासाठी आहे. आम्ही थेट आणि व्यावहारिक बोलणार आहोत. स्वतःच्या फायद्यासाठी कोणताही सिद्धांत नाही. चला समस्येपासून सुरुवात करूया. हॉटेल अतिथी WiFi हा त्या पायाभूत सुविधांपैकी एक आहे जो कागदावर सोपा दिसतो आणि व्यवहारात डोकेदुखी ठरतो. याचे कारण असे की हॉटेल नेटवर्कला एकाच वेळी किमान चार वेगवेगळ्या श्रेणींना सेवा द्यावी लागते - अतिथी, कर्मचारी, बिल्डिंग सिस्टम्स आणि वाढत्या प्रमाणात, स्मार्ट टीव्ही, थर्मोस्टॅट्स आणि व्हॉइस असिस्टंट सारख्या इन-रूम IoT उपकरणांना सेवा देणे आवश्यक असते. प्रत्येक श्रेणीच्या पूर्णपणे भिन्न सुरक्षा आवश्यकता, कार्यप्रदर्शन अपेक्षा आणि अनुपालन परिणाम असतात. हे आर्किटेक्चर चुकीचे डिझाइन केल्यास तुमचे तीन प्रकारे नुकसान होते: अतिथी समाधानाचा स्कोअर घसरतो, तुमची सुरक्षा स्थिती कमकुवत होते आणि आपण डेटा मालमत्ता गमावता जी प्रमाणित WiFi द्वारे तयार व्हायला हवी. तर आता आर्किटेक्चरबद्दल बोलूया. पायाभूत सुविधा म्हणजे VLANs - व्हर्च्युअल लोकल एरिया नेटवर्क्स वापरून नेटवर्कचे विभाजन करणे. VLAN ही IEEE 802.1Q मध्ये परिभाषित केलेली लेअर 2 रचना आहे जी तुम्हाला एकाच भौतिक पायाभूत सुविधांवर एकाधिक तार्किकदृष्ट्या स्वतंत्र नेटवर्क चालवू देते. याचा विचार एकाच महामार्गावरील एकाधिक लेन्स म्हणून करा, ज्याची स्वतःची गती मर्यादा आणि प्रवेश नियम आहेत. हॉटेलमध्ये, तुम्हाला किमान चार VLAN हवे आहेत: VLAN 10 वर अतिथी WiFi, VLAN 20 वर कर्मचारी, VLAN 30 वर IoT आणि बिल्डिंग सिस्टम्स आणि VLAN 40 वर तुमचे PCI-स्कोप पेमेंट नेटवर्क. प्रत्येक SSID - जे अतिथींना दिसणारे नेटवर्कचे नाव आहे - एका संबंधित VLAN शी मॅप होते. तुमचा फायरवॉल त्यांच्या दरम्यान डिफॉल्ट-नाकारण्याचे धोरण लागू करतो. अतिथी ट्रॅफिक फक्त इंटरनेटवर पाठवले जाते. हे तुमच्या प्रॉपर्टी मॅनेजमेंट सिस्टमला, तुमच्या पॉईंट-ऑफ-सेल टर्मिनल्सना किंवा तुमच्या कर्मचाऱ्यांच्या संपर्कांना कधीही स्पर्श करत नाही. आता, ते एकत्रीकरण जे सर्व काही बदलते: तुमच्या WiFi व्यवस्थापन प्लॅटफॉर्मला तुमच्या प्रॉपर्टी मॅनेजमेंट सिस्टमशी - म्हणजेच तुमच्या PMS शी जोडणे. तुम्ही Oracle OPERA, Mews, Protel किंवा इतर कोणतीही सिस्टम चालवत असाल, तरी तुमचे PMS हे इमारतीमध्ये कोण आहे, ते कोणत्या खोलीत आहेत, त्यांच्याकडे कोणती लॉयल्टी टायर आहे आणि ते कधी चेक आउट करत आहेत याबद्दलचे खरे सत्य असते. जर तुमचा WiFi प्लॅटफॉर्म तुमच्या PMS शी बोलत नसेल, तर तुम्ही अंधारात काम करत आहात. एक उत्तम प्रकारे इंटिग्रेट केलेले डिप्लॉयमेंट या पद्धतीने काम करते. एखादा पाहुणा चेक-इन करतो - एकतर फ्रंट डेस्कवर किंवा मोबाईल ॲपद्वारे. PMS हे WiFi मॅनेजमेंट प्लॅटफॉर्मला वेबहुक किंवा API कॉल पाठवते. प्लॅटफॉर्म त्या पाहुण्याची प्रोफाईल आधीच तयार करून ठेवते: त्यांची लॉयल्टी श्रेणी, त्यांचा पसंतीचा SSID, त्यांचे बँडविड्थ धोरण. जेव्हा ते नेटवर्कशी कनेक्ट होतात, तेव्हा त्यांना त्वरित इंटरनेट अनुभव मिळतो. जेव्हा ते चेक-आऊट करतात, तेव्हा त्यांचे सेशन आपोआप रद्द केले जाते. कोणतीही रेंगाळणारी क्रेडेन्शियल्स राहत नाहीत. तीन तासांपूर्वी चेक-आऊट केलेल्या पाहुण्याचे डिव्हाइस अजूनही तुमच्या नेटवर्कवर ऑथेंटिकेट असल्यामुळे उद्भवणारा कोणताही सुरक्षा धोका राहत नाही. Captive Portal - ज्याला कधीकधी स्प्लॅश पेज देखील म्हटले जाते - ही अशी जागा आहे जिथे तुमचे नेटवर्क खर्चाच्या केंद्रावरून डेटा ॲसेटमध्ये बदलते. चुकीच्या पद्धतीने केले तर, हे पाहुण्यांना त्रासदायक वाटते आणि ते ते सोडून देतात. चांगल्या प्रकारे केले तर, हे तुमचे फर्स्ट-पार्टी डेटा कॅप्चर करण्याचे प्राथमिक साधन बनते. पाहुणे ईमेल, सोशल लॉगिन किंवा SMS व्हेरिफिकेशनद्वारे ऑथेंटिकेट करतात. तुम्ही एक व्हेरिफाइड ओळख कॅप्चर करता. ती ओळख त्यांच्या डिव्हाइसशी, त्यांच्या भेटीच्या वेळेची नोंद, त्यांचा थांबण्याचा वेळ आणि त्यांच्या पुढील सर्व भेटींशी लिंक होते. कालांतराने, तुम्ही तुमच्या प्रत्यक्ष पाहुण्यांचा संमती असलेला, GDPR सुसंगत डेटासेट तयार करता - अंदाज लावलेला डेटा नाही, थर्ड-पार्टी डेटा नाही, तर तुमचा स्वतःचा फर्स्ट-पार्टी डेटा. येथे GDPR चे पालन करणे अनिवार्य आहे. तुमच्या स्प्लॅश पेजने स्पष्ट प्रायव्हसी नोटीस, मार्केटिंगसाठी स्पष्ट संमतीचे पर्याय आणि पाहुण्यांना त्यांच्या डेटा हक्कांचा वापर करण्यासाठी सोपी यंत्रणा दाखवणे आवश्यक आहे. महत्त्वाचे म्हणजे, WiFi वापरण्याची संमती आणि मार्केटिंग ईमेल मिळवण्याची संमती ही एकच गोष्ट नाही. या दोन्ही गोष्टी स्वतंत्र आणि वेगळ्या निवडी असल्या पाहिजेत. Purple चे प्लॅटफॉर्म हे मूळतःच हाताळते, ज्यामध्ये संमतीच्या नोंदी प्रत्येक युझर प्रोफाईलशी जोडलेल्या असतात आणि नियामक पुनरावलोकनासाठी ऑडिट ट्रेल्स उपलब्ध असतात. सुरक्षेच्या बाबतीत: स्टाफ नेटवर्कसाठी IEEE 802.1X सह WPA3-Enterprise हा सर्वोत्तम दर्जा मानला जातो. पाहुण्यांच्या नेटवर्कसाठी, WPA3-Personal किंवा HTTPS अंमलबजावणीसह Captive Portal च्या मागे असलेले ओपन नेटवर्क हा प्रमाणित दृष्टिकोन आहे. तुम्ही क्लायंट आयसोलेशनशिवाय ओपन नेटवर्क चालवू नये. क्लायंट आयसोलेशन हे कोणत्याही पाहुण्याच्या डिव्हाइसला त्याच नेटवर्कवरील दुसऱ्या पाहुण्याच्या डिव्हाइसशी थेट संवाद साधण्यापासून रोखते. त्याशिवाय, एखाद्या पाहुण्याच्या हॅक झालेल्या स्मार्टफोनमुळे त्याच SSID वरील इतर प्रत्येक डिव्हाइसचा सुरक्षिततेचा अंदाज घेतला जाऊ शकतो. प्रत्येक गेस्ट-फेसिंग SSID वर क्लायंट आयसोलेशन सुरू करा. यात कोणताही अपवाद नको. स्टाफ नेटवर्कवरील ऑथेंटिकेशनसाठी, 802.1X हे RADIUS सर्व्हरच्या विरोधात ओळख पडताळण्यासाठी Extensible Authentication Protocol - EAP - चा वापर करते, जे पुढे तुमच्या ओळख प्रदात्याकडे चौकशी करते. Purple हे Microsoft Entra ID, Okta, आणि Google Workspace सोबत इंटिग्रेट होते. जेव्हा स्टाफचा एखादा सदस्य ऑथेंटिकेट करतो, तेव्हा RADIUS सर्व्हर केवळ पास किंवा फेल न दाखवता, त्यांच्या भूमिकेवर आधारित VLAN असाइनमेंट आणि QoS धोरण देखील परत करू शकतो. हे ते तांत्रिक कार्य आहे जे मॅन्युअल प्रोव्हिजनिंगशिवाय, रोल-बेस्ड नेटवर्क ॲक्सेस स्वयंचलितपणे कार्यक्षम करते. आता ब्रँड मानके आणि संपूर्ण साखळीतील सातत्य याबद्दल बोलूया - कारण येथेच गव्हर्नन्सचे आव्हान तांत्रिक आव्हानाइतकेच महत्त्वाचे बनते. एका जागतिक हॉटेल ब्रँडच्या डझनभर देशांमध्ये शेकडो मालमत्ता असू शकतात, ज्यातील प्रत्येकाचे स्थानिक ISP, वेगवेगळ्या काळातील इन्फ्रास्ट्रक्चर आणि वेगवेगळ्या फ्रँचायझी व्यवस्था असू शकतात. त्या सर्व मालमत्तांवर सुसंगत अतिथी WiFi अनुभव प्रदान करण्यासाठी केंद्रीकृत पॉलिसी व्यवस्थापनासह क्लाउड-व्यवस्थापित नेटवर्क आर्किटेक्चरची आवश्यकता असते. यासाठी उपयुक्त ठरणारे मॉडेल म्हणजे त्रि-स्तरीय उतरंड (three-tier hierarchy). ब्रँडचे मुख्यालय पॉलिसी टेम्पलेट्स परिभाषित करते: SSIDs, सुरक्षा मानके, लॉयल्टी टियर बँडविड्थ वाटप आणि captive portal ब्रँडिंग. प्रादेशिक हब स्थानिक बदलांनुसार हे टेम्पलेट्स लागू करतात. वैयक्तिक मालमत्ता प्रादेशिक हबकडून हे वारशाने मिळवतात आणि ब्रँडने परिभाषित केलेल्या पॅरामीटर्समध्येच सानुकूलित करू शकतात. मालमत्तांना लवचिकता असते, परंतु ते ब्रँडच्या मानकांचे उल्लंघन करू शकत नाहीत. तांत्रिक दृष्टिकोनातून, यासाठी प प उतरंड पॉलिसी इंजिन असलेल्या क्लाउड-व्यवस्थापित WiFi प्लॅटफॉर्मची आवश्यकता असते. प्रत्येक मालमत्तेवरील ॲक्सेस पॉइंट्स क्लाउड कंट्रोलरशी कनेक्ट होतात, त्यांचे कॉन्फिगरेशन मिळवतात आणि ते स्थानिक पातळीवर लागू करतात. जर एखाद्या मालमत्तेचे इंटरनेट कनेक्शन खंडित झाले, तर APs त्यांच्या शेवटच्या ज्ञात योग्य कॉन्फिगरेशननुसार ऑटोनॉमस मोडमध्ये काम करत राहतात. ती लवचिकता अत्यंत महत्त्वाची आहे. मी तुम्हाला प्रत्यक्ष अंमलबजावणीच्या क्रमाबद्दल सांगतो. पाच टप्पे. टप्पा एक: साइट सर्व्हे. एकाही केबलला स्पर्श करण्यापूर्वी, स्पेक्ट्रम ॲनालायझर घेऊन मालमत्तेची पाहणी करा. केबल टाकण्यापूर्वी तुमच्या ॲक्सेस पॉइंटच्या जागा निश्चित करण्यासाठी प्रेडिक्टिव मॉडेलिंग सॉफ्टवेअर वापरा. इन-रूम कव्हरेज हे ध्येय आहे. प्रति खोली एक AP, किंवा किमान दर दोन खोल्यांसाठी एक. कॉरिडॉरमध्ये प्लेसमेंट करणे ही एक सामान्य चूक आहे ज्यामुळे खोल्यांमध्ये कव्हरेज शॅडो (कमी कव्हरेजचे क्षेत्र) तयार होतात. टप्पा दोन: VLAN आर्किटेक्चर डिझाइन. काहीही कॉन्फिगर करण्यापूर्वी प्रत्येक डिव्हाइस प्रकार एका समर्पित VLAN वर मॅप करा. अतिथी, कर्मचारी, IoT, पेमेंट सिस्टम्स. तुमचे फायरवॉल इंटर-VLAN नियम हे VLAN आर्किटेक्चरइतकेच महत्त्वाचे आहेत. डिफॉल्ट-नाकारा, स्पष्टपणे-परवानगी द्या. टप्पा तीन: PMS इंटिग्रेशन स्कोपिंग. हे तुमचे WiFi प्लॅटफॉर्म निवडण्यापूर्वी करा, नंतर नाही. तुमच्या निवडलेल्या प्लॅटफॉर्ममध्ये तुमच्या PMS साठी आधीच तयार केलेले कनेक्टर असल्याची खात्री करा, आणि निर्णय घेण्यापूर्वी API इंटिग्रेशनच्या कामाची व्याप्ती समजून घ्या. टप्पा चार: captive portal आणि ऑथेंटिकेशन फ्लो. गो-लाइव्ह करण्यापूर्वी iOS, Android आणि Windows वर अतिथींच्या संपूर्ण प्रवासाची सुरुवातीपासून शेवटपर्यंत चाचणी घ्या. सहमतीच्या प्रवाहांची (consent flows) चाचणी घ्या. परत भेट दिल्यावर काय होते याची चाचणी घ्या. जे captive portal लोड होण्यासाठी ४५ सेकंद घेते किंवा वैयक्तिक माहितीचे दहा रकाने विचारते, ते केवळ तांत्रिक अपयश नसून ब्रँडचे अपयश आहे. टप्पा पाच: ॲनालिटिक्स आणि रिपोर्टिंग कॉन्फिगरेशन. तुमच्या WiFi डेटा लेयरला तुमच्या CRM आणि मार्केटिंग ऑटोमेशन टूल्सशी कनेक्ट करा. तुम्ही ऑथेंटिकेटेड WiFi द्वारे तयार केलेली डेटा मालमत्ता केवळ तेव्हाच मौल्यवान ठरते जेव्हा ती डाउनस्ट्रीम वर्कफ्लोमध्ये वापरली जाते. आता संभाव्य अडचणी. मी याच चुका वारंवार घडताना पाहतो. पहिले म्हणजे इंटरनेट अपलिंक कमी प्रमाणात पुरवणे. दहापैकी नऊ वेळा, हॉटेलचे संथ WiFi हे WAN मधील बँडविड्थची समस्या असते, रेडिओ फ्रिक्वेन्सीची नाही. ८०% ऑक्युपन्सी असलेल्या आणि पाहुणे व्हिडिओ स्ट्रीमिंग करत असलेल्या २०० खोल्यांच्या हॉटेलसाठी, पीक अवर्समध्ये प्रति खोली पाच ते दहा मेगाबिट्स प्रति सेकंदाचे नियोजन करा. म्हणजेच ८०० मेगाबिट्स ते १.६ गिगाबिट्सची कमिटेड बँडविड्थ. दुसरी चूक म्हणजे चुकीच्या पद्धतीने कॉन्फिगर केलेले ट्रंक पोर्ट्स. जर मल्टिपल VLANs वाहून नेणारा स्विच पोर्ट चुकून ॲक्सेस पोर्ट म्हणून कॉन्फिगर झाला, तर सर्व ट्रॅफिक एकाच VLAN वर कोलमडते आणि तुमचे सेगमेंटेशन नकळत नाहीसे होते. प्रत्येक बदलानंतर तुमच्या स्विच कॉन्फिगरेशनचे ऑडिट करा. तिसरी चूक म्हणजे असा Captive Portal तैनात करणे जो डेटा गोळा करतो परंतु ज्यामध्ये कोणताही डाउनस्ट्रीम मार्केटिंग वर्कफ्लो नसतो. तुम्ही डेटा ॲसेट तयार केली आहे. आता तिचा वापर करा. झटपट प्रश्न. मी पाहुण्यांकडून WiFi साठी शुल्क आकारावे का? नाही. २०२६ मध्ये, सशुल्क गेस्ट WiFi हे पाहुण्यांच्या समाधानाच्या दृष्टीने एक दायित्व आहे. विनामूल्य, ऑथेंटिकेट केलेल्या WiFi चे डेटा आणि मार्केटिंग मूल्य हे ॲक्सेस शुल्कातून मिळणाऱ्या कोणत्याही महसुलापेक्षा कितीतरी पतीने जास्त आहे. मला Wi-Fi 6 ची गरज आहे की Wi-Fi 5 पुरेसे ठरेल? जर तुम्ही आज नवीन इन्फ्रास्ट्रक्चर तैनात करत असाल, तर नेहमी Wi-Fi 6 निवडा. खर्चातील फरक नगण्य आहे आणि परफॉर्मन्सची क्षमता लक्षणीय आहे. मी अतिथींच्या खोल्यांमधील IoT डिव्हाइसेस कसे हाताळू? त्यांना कोणत्याही लॅटरल मूव्हमेंट क्षमतेशिवाय आणि कडक इग्रेस फिल्टरिंगसह एका डेडिकेटेड IoT VLAN वर सेगमेंट करा. त्यांनी कधीही गेस्ट डिव्हाइसेससोबत नेटवर्क सेगमेंट शेअर करू नये. हे सर्व एकत्र आणायचे तर - हॉटेल गेस्ट WiFi व्यवस्थापन ही प्रामुख्याने बँडविड्थची समस्या नाही. ही आर्किटेक्चर, इंटिग्रेशन आणि गव्हर्नन्सची समस्या आहे. ज्या प्रॉपर्टीजमध्ये हे योग्यरित्या केले जाते त्यांच्यामध्ये तीन गोष्टी समान असतात: हायशार्किकल पॉलिसी मॉडेलसह सेंट्रलाइज्ड क्लाउड-मॅनेज्ड नेटवर्क, डीप PMS इंटिग्रेशन जे सेशन मॅनेजमेंट आणि लॉयल्टी टियरचे वर्गीकरण स्वयंचलित करते, आणि ते WiFi परफॉर्मन्स डेटाला एक महत्त्वाचा ऑपरेशनल मेट्रिक मानतात. लक्षात ठेवण्यासारख्या तीन गोष्टी. एक: पहिल्या दिवसापासून तुमच्या नेटवर्कचे योग्य प्रकारे सेगमेंटेशन करा. गेस्ट, कर्मचारी आणि IoT स्वतंत्र VLANs वर, आणि त्यांच्यामध्ये फायरवॉल असावा. दोन: गो-लाइव्ह होण्यापूर्वी तुमचे WiFi प्लॅटफॉर्म तुमच्या PMS सोबत इंटिग्रेट करा. ऑटोमॅटिक सेशन प्रोव्हिजनिंग आणि रिव्होकेशन ही केवळ हौस नसून गरज आहे. तीन: तुमच्या Captive Portal कडे केवळ एक ॲक्सेस गेटवे म्हणून न पाहता एक मार्केटिंग प्लॅटफॉर्म म्हणून पहा. ऑथेंटिकेट केलेल्या WiFi द्वारे तुम्ही कॅप्चर केलेला फर्स्ट-पार्टी डेटा ही तुमच्या सर्वात मौल्यवान व्यावसायिक मालमत्तांपैकी एक आहे. Purple हे ८०,००० पेक्षा जास्त ठिकाणांवर कार्यरत आहे आणि २०२४ मध्ये ४४० दशलक्ष लॉगइन्स प्रविष्ट केले आहेत. जर तुम्हाला Purple चे Guest WiFi प्लॅटफॉर्म PMS इंटिग्रेशन, चेन-व्यापी पॉलिसी व्यवस्थापन आणि गेस्ट डेटा ॲनालिटिक्स कसे हाताळते हे जाणून घ्यायचे असेल, तर purple.ai ला भेट द्या. ऐकल्याबद्दल धन्यवाद.