व्हाइट लेबल captive portal सॉफ्टवेअर: MSPs आणि रिसेलर्सनी स्वाक्षरी करण्यापूर्वी काय तपासले पाहिजे

White label Captive Portal सॉफ्टवेअर MSP किंवा रीसेलरला त्यांच्या स्वतःच्या ब्रँडखाली गेस्ट WiFi लॉगिन पेज विकण्याची अनुमती देते. करारावर स्वाक्षरी करण्यापूर्वी, सहा गोष्टींची पुष्टी करा: डेलिगेटेड ॲडमिनसह ट्रू मल्टी-टेनन्सी, डोमेन, ईमेल आणि रिपोर्ट्सवर ब्रँडिंग, तुम्ही इंस्टॉल केलेल्या प्रत्येक ॲक्सेस पॉइंट व्हेंडरसाठी सपोर्ट, मार्जिन सुरक्षित ठेवणारे बिलिंग मॉडेल, तुमच्या क्लायंटच्या मालकीचे GDPR सहमती रेकॉर्ड, आणि डॉक्युमेंट केलेले APIs.

तुम्ही कोणते white label Captive Portal मॉडेल निवडावे?

Captive Portal हे असे वेब पेज आहे जे नेटवर्क इंटरनेट ॲक्सेस देण्यापूर्वी डिव्हाइसला दिसते. IETF RFC 8952 मध्ये आर्किटेक्चर मांडते. RFC 8908 एक API परिभाषित करते जे डिव्हाइसेसना पोर्टल उपस्थित असल्याचे सांगते.

White label Captive Portal सॉफ्टवेअर तुम्हाला ते लॉगिन पेज तुमच्या स्वतःच्या ब्रँडखाली विकू देते. त्यामागील कन्सोल आणि रिपोर्ट्सवरही तुमचाच ब्रँड असतो.

रीसेलर मार्केटमध्ये तीन कमर्शियल मॉडेल्सचे वर्चस्व आहे. ते तीन मुद्द्यांवर भिन्न आहेत:

• क्लायंटचा करार कोणाकडे आहे
• तुमचा ब्रँड कुठपर्यंत पोहोचतो
• प्रत्येक क्लायंटचा डेटा किती चांगल्या प्रकारे वेगळा केला आहे

प्रथम मॉडेल निवडा, नंतर त्यामधील व्हेंडर्सचे मूल्यमापन करा.

मॉडेल	तुमचा ब्रँड येथे दिसतो	क्लायंट डेटा आयसोलेशन	क्लायंटचा करार कोणाकडे आहे	टिपिकल बिलिंग	कोणासाठी योग्य
Full white label, multi-tenant	लॉगिन पेज, कस्टम डोमेन, ॲडमिन कन्सोल, ईमेल्स, SMS आणि रिपोर्ट्स	स्कोप केलेले ॲडमिन रोल आणि API की सह प्रति क्लायंट स्वतंत्र टेनंट	तुम्ही	प्रति साइट किंवा प्रति ॲक्सेस पॉइंट होलसेल, तुम्ही रिटेल ठरवता	सर्व्हिस डेस्क आणि वेन्यू क्लायंटचे पोर्टफोलिओ असलेले MSPs
Co-branded reseller	फक्त लॉगिन पेज आणि ईमेल्स; कन्सोल आणि रिपोर्ट्स व्हेंडर दाखवतात	एका शेअर केलेल्या अकाउंटमध्ये सब-अकाउंट्स किंवा फोल्डर्स	तुम्ही किंवा व्हेंडर	व्हेंडर लिस्ट प्राईज वजा रीसेलर डिस्काउंट	हार्डवेअर विक्रीमध्ये गेस्ट WiFi जोडणारे रीसेलर्स
Referral किंवा direct contract	पूर्णपणे व्हेंडरचा ब्रँड; तुम्ही इंस्टॉलर्स म्हणून दिसता	क्लायंटचे स्वतःचे व्हेंडर अकाउंट	व्हेंडर	व्हेंडर लिस्ट प्राईज; तुम्ही रेफरल फी किंवा सर्व्हिसेसचे उत्पन्न मिळवता	सपोर्ट डेस्कशिवाय वन-ऑफ प्रोजेक्ट्स चालवणारे पार्टनर

सपोर्ट डेस्क आणि अनेक वेन्यू क्लायंट असलेले बहुतेक MSPs पहिल्या मॉडेलची निवड करतात. या मार्गदर्शकाचा उर्वरित भाग तेच मॉडेल गृहीत धरतो आणि व्हेंडरच्या दाव्यांची चाचणी कशी करावी हे दाखवतो.

White label Captive Portal प्लॅटफॉर्म्स खरोखर कुठे भिन्न आहेत

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

ट्रू मल्टी-टेनन्सी आणि डेलिगेटेड ॲडमिन

ट्रू मल्टी-टेनन्सी म्हणजे प्रति टेनंट एक क्लायंट. डेटा, सेटिंग्ज, ॲडमिन अकाउंट्स आणि API की प्लॅटफॉर्म स्तरावर आयसोलेट केलेल्या असतात. शेअर केलेल्या अकाउंटमधील फोल्डर म्हणजे टेनंट नाही. जर चुकीच्या पद्धतीने कॉन्फिगर केलेल्या रोलमुळे एका क्लायंटची गेस्ट लिस्ट दुसऱ्याला दिसली, तर डेटा ब्रीचची जबाबदारी तुमची असेल.

डलिगेटेड ॲडमिनची चाचणी ट्रायल टेनंटमध्ये करा, स्लाईडवर नाही. तुम्हाला किमान चार रोल्सची आवश्यकता आहे:

• तुमचा स्वतःचा सुपर ॲडमिन
• क्लायंट ॲडमिन
• एकाच ठिकाणापुरता मर्यादित असलेला वेन्यू मॅनेजर
• फक्त वाचण्याची परवानगी असलेली (read-only) मार्केटिंग भूमिका

एका हॉटेलच्या जनरल मॅनेजरला फक्त त्यांचे स्वतःचे हॉटेल दिसले पाहिजे, इतर काहीही नाही.

SAML 2.0 द्वारे सिंगल साइन-ऑनची मागणी करा, जे फेडेरेटेड लॉगिनसाठी OASIS मानक आहे. हे Microsoft Entra ID, Okta आणि Google Workspace सोबत कार्य केले पाहिजे.

SCIM 2.0 (System for Cross-domain Identity Management, RFC 7643 आणि RFC 7644) ॲडमिन खाती तयार करण्याची आणि हटवण्याची प्रक्रिया स्वयंचलित करते. याशिवाय, तुमच्या क्लायंटची नोकरी सोडणारी व्यक्ती कोणीतरी आठवण ठेवून ॲक्सेस काढेपर्यंत कंसोल ॲक्सेस राखून ठेवते. ऑडिट लॉग प्रति टणंट (tenant) जतन केले जातात आणि निर्यात केले जाऊ शकतात याची खात्री करा, जेणेकरून कोणी काय बदलले हे तुम्ही क्लायंटला दाखवू शकाल.

ब्रँडिंगची खोली: डोमेन, पाठवणारा ईमेल, पोर्टल आणि रिपोर्ट्स

ब्रँडिंगच्या खोलीच्या बाबतीत बहुतेक "व्हाइट लेबल" दावे अपुरे पडतात. पाहुणे किंवा क्लायंट पाहू शकणाऱ्या प्रत्येक घटकाला गुण द्या:

• लॉगिन पेज डोमेन. Captive Portal तुमच्या किंवा तुमच्या क्लायंटच्या डोमेनवरून लोड झाले पाहिजे. व्हेंडरने त्याचे TLS प्रमाणपत्र स्वयंचलितपणे नूतनीकरण केले पाहिजे.
• ॲडमिन कंसोल. तुमचा लोगो, रंग आणि URL साइन-इन स्क्रीनवर असले पाहिजेत. व्हेंडर-ब्रँडेड कंसोल तुमच्या क्लायंटला नूतनीकरणाच्या वेळी कोणाला कॉल करायचे ते नेमके सांगते.
• पाठवणारा ईमेल. पडताळणी कोड आणि मार्केटिंग ईमेल तुमच्या डोमेनवरून पाठवले जाणे आवश्यक आहे. त्यासाठी SPF (RFC 7208), DKIM (RFC 6376) आणि DMARC (RFC 7489) तुमच्या डोमेनशी अलाइन असणे आवश्यक आहे, अन्यथा मेसेज स्पॅममध्ये जातात.
• SMS सेन्डर ID. पडताळणी मेकसेजेसवर तुमचे किंवा वेन्यूचे नाव दिसले पाहिजे, व्हेंडरचे कधीही नाही.
• रिपोर्ट्स. शेड्यूल केलेल्या निर्याती आणि डॅशबोर्डवर व्हेंडरचा कोणताही वॉटरमार्क नसावा आणि त्यावर तुमचे ब्रँडिंग असावे. तुम्ही WiFi Analytics चे रीसेल करत असल्यास, मासिक रिपोर्ट हेच उत्पादन असते जे तुमचे क्लायंट प्रत्यक्षात पाहतात.
• हेल्प लिंक्स आणि स्टेटस पेजेस. कंसोल लिंक्स तुमच्या नॉलेज बेसकडे निर्देशित केल्या पाहिजेत, किंवा कुठेही नाही.
• प्रति-टणंट (Per-tenant) टेम्पलेट्स. पब ग्रुप आणि कौन्सिल यांना वेगवेगळे लॉगिन फ्लो, संमती शब्द रचना आणि भाषा हवी असतात.

तुमच्या इन्स्टॉल केलेल्या बेसवर हार्डवेअर कव्हरेज

तुमच्या क्लायंटकडे आधीपासूनच ॲक्सेस पॉइंट्स आहेत आणि ते क्वचितच एकाच व्हेंडरचे असतात. सपोर्ट असलेल्यांची यादी नाव आणि मॅनेजमेंट प्लॅटफॉर्मनुसार मागवा: Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet. "सर्व प्रमुख व्हेंडर्स" हे उत्तर नाही, तर तो धोक्याचा इशारा आहे.

सपोर्ट म्हणजे केवळ रिडायरेक्टपेक्षा जास्त आहे. प्रत्येक व्हेंडरसाठी, चार क्षमतांची पुष्टी करा:

• एक्सटर्नल captive portal रिडायरेक्ट
• RADIUS (Remote Authentication Dial-In User Service, RFC 2865) ऑथेंटिकेशन
• सेशन डेटासाठी RADIUS अकाउंटिंग (RFC 2866)
• सोशल आणि पेमेंट लॉगिनसाठी वॉल्ड गार्डन कॉन्फिगरेशन

प्रत्येक व्हेंडरसाठी प्रकाशित दिलेली इंटिग्रेशन मार्गदर्शिका मागवा. नंतर तुमचे क्लायंट प्रत्यक्षात वापरत असलेल्या फर्मवेअरवर ते तपासा.

हार्डवेअर कव्हरेज रिफ्रेश सायकलदरम्यान तुमचे रक्षण करते. क्लाउड ओव्हरले नेटवर्कच्या वर बसतो, ज्यामुळे क्लायंट गेस्ट अनुभव न बदलता ॲक्सेस पॉइंट व्हेंडर बदलू शकतो. Planning a WiFi 6 to WiFi 7 access point refresh when Cisco Meraki WiFi 6 reaches end of sale द्वारे काम करणाऱ्या कोणत्याही मालमत्तेसाठी हे महत्त्वाचे आहे.

Purple चे Guest WiFi वरील सर्व आठ व्हेंडर्सवर हार्डवेअर-अॅग्नोस्टिक क्लाउड ओव्हरले म्हणून चालते. याची पार्श्वभूमी Why your next WiFi upgrade doesn't need new hardware मध्ये आहे.

काही क्लायंट्सना गेस्ट ॲक्सेसपेक्षा जास्त हवे असेल. प्लॅटफॉर्म 802.1X हाताळतो का ते विचारा, जे पोर्ट-आधारित नेटवर्क ॲक्सेस कंट्रोलसाठी IEEE मानके आहे. iPSK (आयडेंटिटी प्री-शेअर की) बद्दल देखील विचारा, जे प्रत्येक डिव्हाइसला किंवा व्यक्तीला त्यांची स्वतःची WiFi की देते. जर तुम्ही कर्मचारी ॲक्सेस जोडत असाल, तर Troubleshooting Windows 11 802.1X authentication issues: enterprise IT guide सोबत ठेवा.

Passpoint, ज्याला Hotspot 2.0 देखील म्हणतात, ते पुन्हा येणाऱ्या पाहुण्यांना पोर्टलशिवाय स्वयंचलितपणे पुन्हा कनेक्ट करू देते. Wireless Broadband Alliance चे फेडरेशन असलेले OpenRoaming, सहभागी नेटवर्कमध्ये तेच काम करते. यांशिवाय असलेला प्लॅटफॉर्म तुम्ही नंतर काय विकू शकता यावर मर्यादा घालतो.

GDPR संमतीच्या नोंदी ज्यांवर तुमच्या क्लायंटची मालकी आहे

GDPR अंतर्गत, तुमचा क्लायंट, म्हणजे वेन्यू ऑपरेटर, हा सामान्यतः गेस्ट डेटाचा नियंत्रक असतो (अनुच्छेद 4(7)). तुम्ही प्रोसेसर म्हणून आणि प्लॅटफॉर्म व्हेंडर तुमचे सब-प्रोसेसर म्हणून काम करता. अनुच्छेद 28 त्या साखळीतील प्रत्येक लिंकवर लेखी कराराची मागणी करतो. अनुच्छेद 28(2) प्रोसेसरला नियंत्रकाच्या पूर्व लेखी प्राधिकरणाशिवाय सब-प्रोसेसर नियुक्त करण्यास मनाई करतो.

अनुच्छेद 7(1) नुसार नियंत्रकाने संमती सिद्ध करणे आवश्यक आहे. याचा अर्थ प्रत्येक पाहुण्यामागे संपूर्ण नोंद:

• टाइमस्टॅम्प
• दाखवलेले तंतोतंत शब्द
• प्रायव्हसी नोटीस आवृत्ती
• चॅनेल
• स्वीकारलेले उद्देश

फक्त "मार्केटिंग ऑप्टेड-इन" फ्लॅग पुरेसा नाही. Recital 32 जोडते की पूर्वीच टिक केलेले बॉक्स संमती म्हणून गणले जात नाहीत. यूके ईमेल आणि SMS मार्केटिंगसाठी, संमतीने Privacy and Electronic Communications Regulations (PECR) चे देखील समाधान केले पाहिजे.

स्वाक्षरी करण्यापूर्वी तीन कराराचे मुद्दे तपासा:

1. व्हेंडर स्वतःच्या उद्देशांसाठी गेस्ट डेटा वापरण्याचा कोणताही दावा करत नाही. जर त्यांनी तसे केले, तर ते नियंत्रक बनतात आणि तुमच्या क्लायंटच्या प्रायव्हसी नोटीसमध्ये तसे नमूद असणे आवश्यक आहे.
2. अनुच्छेद 28(3)(g) करार संपल्यावर वैयक्तिक डेटा परत करणे किंवा हटवणे आवश्यक करते. एक्सपोर्ट स्वरूप, कालमर्यादा आणि खर्च लेखी स्वरूपात घ्या.
3. व्हेंडर सब-प्रोसेसरची यादी प्रकाशित करतो आणि बदलांबद्दल तुम्हाला सूचित करतो, जेणेकरून तुम्ही क्लायंटना सूचना पाठवू शकता.

Purple लॉगिन फ्लोमध्ये जाणीवपूर्वक-निवड असणारे ऑप्ट-इन्स तयार करते, ज्यामुळे प्रत्येक पाहुणा सक्रियपणे मार्केटिंग निवडतो. Purple हे ISO 27001 प्रमाणित आणि GDPR सुसंगत आहे.

API आणि वेबहुक ॲक्सेस

APIs ठरवतात की तुम्ही तुमची स्वतःची किती सेवा तयार करू शकता. एकाच टेनंटपुरती मर्यादा असलेल्या की सह डॉक्युमेंट केलेल्या REST API ची मागणी करा. मग एक तडजोड केलेली की सर्व क्लायंटपर्यंत पोहोचू शकत नाही. टेनंट्स, वेन्यूज आणि पोर्टल टेम्पलेट्ससाठी बल्क एंडपॉइंट्स तुम्हाला क्लिक करत बसण्याऐवजी ऑनबोर्डिंग स्क्रीप्ट करण्यास अनुमती देतात.

वेबहुक्स घटना, जसे की गेस्ट लॉगिन किंवा नवीन ऑप्ट-इन, तुमच्या क्लायंटच्या CRM मध्ये घडताच पुश करतात. तीन गोष्टी तपासा:

• पेलोड्स स्वाक्षरीत आहेत, जेणेकरून प्राप्तकर्ता प्रेषकाची पडताळणी करू शकेल
• अयशस्वी डिलिव्हरींचा स्वयंचलितपणे पुन्हा प्रयत्न केला जातो
• रेट मर्यादा आणि API ॲक्सेससाठी कोणताही अतिरिक्त शुल्क लेखी स्वरूपात निश्चित केले आहे

सपोर्ट एस्केलेशन

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

कंत्राटामध्ये या गोष्टी समाविष्ट करा:

• स्पष्टपणे व्याख्या केलेल्या तीव्रतेच्या पायऱ्या (severity levels)
• प्रत्येक पायरीसाठी प्रतिसादाची उद्दिष्टे (response targets)
• एका नामांकित पार्टनरचा संपर्क
• साईट-डाऊन (site-down) घटनेसाठी इंजिनिअरिंग टीमपर्यंत थेट मार्ग

Article 33(2) नुसार डेटा प्रोसेसरने कोणत्याही डेटा ब्रीचची माहिती डेटा कंट्रोलरला विनाविलंब देणे आवश्यक आहे. तुमच्या व्हेंडर कंत्राटाने तुम्हाला तुमच्या क्लायंटप्रती हे कर्तव्य पूर्ण करण्यासाठी पुरेशा वेगाने सूचना दिली पाहिजे.

स्केलचा पुरावा देखील मागा. Purple ने 2024 मध्ये 90 पेक्षा जास्त देशांमधील 80,000+ लाईव्ह व्हेन्यूंमध्ये 440 दशलक्ष लॉगीन्स हाताळले (Purple चा स्वतःचा डेटा).

पूर्णपणे मल्टी-टेनंट व्हाईट लेबल प्लॅटफॉर्म निवडणे कधी योग्य ठरते

जेव्हा तुमचे क्लायंटसोबतचे नाते पूर्णपणे तुमचे स्वतःचे असते, तेव्हा पूर्ण व्हाईट लेबल निवडा. याचा सामान्यतः अर्थ असा होतो की तीन गोष्टी सत्य आहेत:

• तुम्ही सर्व्हिस डेस्क चालवता
• तुम्ही क्लायंटना दरमहा बिल पाठवता
• तुमच्याकडे विविध क्षेत्रांमधील अनेक व्हेन्यू क्लायंट आहेत

त्यानंतर गेस्ट WiFi हा तुमच्या स्वतःच्या इनव्हॉईसवरील एक नियमित आवर्ती भाग बनतो.

हे मिश्र हार्डवेअर असणाऱ्या प्रॉपर्टीजसाठी देखील सोयीचे आहे. एक हार्डवेअर-ॲग्नोस्टिक प्लॅटफॉर्म अनेक व्हेंडर-विशिष्ट कन्सोलची जागा घेतो. तुमचे इंजिनिअर्स एकच सिस्टम शिकतात, आणि प्रत्येक क्लायंटचा रिपोर्ट एकसारखाच दिसतो.

प्रत्यक्ष उदाहरण: दोन हार्डवेअर व्हेंडर्स असलेली एक प्रादेशिक हॉटेल साखळी

परिस्थिती. एका MSP ने 14 हॉटेल्सच्या प्रादेशिक ग्रुपसाठी गेस्ट WiFi व्यवस्थापित केले. नऊ हॉटेल्स Cisco Meraki वापरत होती. मागील वर्षी विकत घेतलेली पाच हॉटेल्स, त्यांच्यात असलेल्या 210 ॲक्सेस पॉईंट्ससह Ruckus वापरत होती. MSP ने शॉर्टलिस्ट केलेला Captive Portal फक्त Meraki ला सपोर्ट करत होता.

काय करण्यात आले. MSP ने आपली शॉर्टलिस्ट हार्डवेअर-ॲग्नोस्टिक प्लॅटफॉर्मवर हलवली आणि दोन्ही व्हेंडर्स समाविष्ट असलेल्या दोन-हॉटेलचा पायलट प्रोजेक्ट चालवला. त्यांनी ग्रुपसाठी एक टेनंट तयार केला, ज्यामध्ये प्रत्येक हॉटेल एक व्हेन्यू म्हणून होते. जनरल मॅनेजर्सना फक्त व्हेन्यू पुरत्या भूमिका मिळाल्या. ग्रुप मार्केटिंग लीडला सर्व 14 हॉटेल्सचे रिपोर्टिंग पाहण्यासाठी रीड-ओन्ली ॲक्सेस मिळाला.

निकाल (प्रातिनिधिक आकडेवारी). सर्व 210 Ruckus ॲक्सेस पॉईंट्स बदलण्याऐवजी सेवेतच राहिले. ग्रुपने प्रत्येक प्रॉपर्टीमध्ये एकच लॉगिन डिझाइन, एकच संमती मजकूर (consent wording) आणि एकच मासिक रिपोर्ट चालवला.

या क्षेत्राबद्दल अधिक माहितीसाठी, Hotels आणि WiFi in restaurants: a UK guide to coverage and security पहा.

सह-ब्रँडेड (co-branded) किंवा थेट कंत्राट निवडणे कधी योग्य ठरते

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

थेट कंत्राट हे इन-हाउस IT असणाऱ्या मोठ्या एकल क्लायंटसाठी योग्य ठरते, जसे की एखादी राष्ट्रीय Retail साखळी. त्यांची प्रोक्युरमेंट टीम थेट व्हेंडरशी कंत्राट करणे पसंत करू शकते. Healthcare सारख्या नियमन केलेल्या क्षेत्रातील क्लायंट बऱ्याचदा स्वतःची सप्लायर ॲश्युरन्स प्रक्रिया देखील चालवतात.

तुम्ही अजूनही इन्स्टॉलेशन, नेटवर्क व्यवस्थापन आणि साइट सर्वेक्षणांवर कमाई करता. WiFi Site Surveys: A Practical Planning Guide यामध्ये त्या पायाभूत कामाचा समावेश आहे.

व्हाईट लेबल Captive Portal सॉफ्टवेअरची किंमत कशी ठरवली जाते

तीन बिलिंग युनिट्स मुख्य आहेत: प्रति साइट, प्रति ॲक्सेस पॉइंट आणि प्रति गेस्ट. बहुतेक विक्रेते घाऊक विक्री करतात आणि तुम्ही किरकोळ किंमत ठरवता. तुमचा मार्जिन सवलतीपेक्षा तुमचे बिलिंग युनिट विक्रेत्याच्या युनिटशी जुळण्यावर अधिक अवलंबून असतो.

बिलिंग मॉडेल	तुम्ही कशासाठी पैसे देता	खर्चाची अंदाजक्षमता	तुमच्यासाठी मुख्य जोखीम	सर्वात योग्य
प्रति साइट	प्रत्येक ठिकाण, आकार काहीही असो	उच्च: केवळ जेव्हा एखादे ठिकाण जोडले जाते किंवा काढले जाते तेव्हाच बदल होतो	लहान ठिकाणांचा खर्च मोठ्या ठिकाणांइतकाच असतो	समान प्रकारच्या ठिकाणांच्या साखळ्या: पब्स, क्विक-सर्व्हिस रेस्टॉरंट्स, हाय स्ट्रीट रिटेल
प्रति ॲक्सेस पॉइंट	प्रत्येक व्यवस्थापित ॲक्सेस पॉइंट	उच्च: केवळ हार्डवेअर प्रोजेक्ट्ससह बदल होतो	डेन्सिफिकेशन किंवा WiFi 7 रिफ्रेशमुळे लायसन्स वाढतात	स्टेडियम, कॉन्फरन्स सेंटर्स आणि उपस्थितीचे उच्च टप्पे असणारी इतर ठिकाणे
प्रति गेस्ट	प्रति महिना प्रत्येक ऑथेंटिकेट केलेला गेस्ट	कमी: उपस्थितीनुसार बदलते	मर्यादा घातली नसल्यास इव्हेंटच्या गर्दीमुळे बिलाचा धक्का बसतो	पायलट प्रोजेक्ट्स, हंगामी ठिकाणे आणि कमी रहदारी असणाऱ्या साइट्स
विक्रेता तुम्हाला ज्या युनिटमध्ये बिल पाठवतो त्याच युनिटमध्ये तुमच्या क्लायंटला बिल पाठवणे ही सर्वात सुरक्षित रचना आहे. जर तुम्ही प्रति ॲक्सेस पॉइंट पैसे भरत असाल परंतु प्रति साइट आकारत असाल, तर प्रत्येक डेन्सिफिकेशन प्रोजेक्ट तुमचा मार्जिन कमी करतो.

स्वाक्षरी करण्यापूर्वी, पुढील चार अतिरिक्त खर्च तपासा:

• किमान अटी (minimum terms)
• वार्षिक वाढीचे कलम (annual uplift clauses)
• API ॲक्सेस किंवा अतिरिक्त टेनंट्ससाठी शुल्क
• SMS व्हॅरिफिकेशन, जे सहसा लायसन्सच्या बाहेर असते

प्रत्यक्ष उदाहरण: इव्हेंटनुसार गर्दीचे टप्पे असणारे कॉन्फरन्स सेंटर

परिस्थिती. एका रिसेलरने 120 ॲक्सेस पॉइंट्स असलेल्या कॉन्फरन्स सेंटरसाठी गेस्ट WiFi चे कोटेशन दिले. मासिक उपस्थिती कमी गर्दीच्या महिन्यात सुमारे 3,000 अभ्यागतांपासून ते मोठ्या ट्रेड शो दरम्यान 45,000 पर्यंत होती.

काय केले गेले. पहिल्या विक्रेत्याने प्रति गेस्ट किंमत आकारली. रिसेलरने 12 महिन्यांच्या उपस्थितीचे मॉडेल तयार केले आणि इनव्हॉईसमध्ये 15 पट फरक पडत असल्याचे आढळले. त्यांनी प्रति ॲक्सेस पॉइंट बिलिंग करणाऱ्या विक्रेत्याकडे बदल केला आणि त्या ठिकाणासाठी निश्चित मासिक शुल्क आकारले.

निकाल (प्रातिनिधिक आकडे). लायसन्स लाईन दरमहा 120 ॲक्सेस पॉइंट्सवर स्थिर राहिली, त्यामुळे मासिक खर्चातील तफावत शून्यावर आली. कॉन्फरन्स सेंटरने निश्चित वार्षिक रक्कमेचे बजेट ठरवले. रिसेलरचा मार्जिन इव्हेंट कॅलेंडरवर अवलंबून राहणे बंद झाले.

तुमच्या प्रॉपर्टीसाठी निर्णय कसा घ्यावा: RFP प्रश्न आणि धोक्याचे इशारे

प्रत्येक शॉर्टलिस्ट केलेल्या विक्रेत्याला तेच प्रश्न पाठवा आणि लेखी उत्तरे मागा. नंतर ट्रायअल टेनंटमध्ये महत्त्वाच्या उत्तरांची पडताळणी करा.

पाठवायचे RFP प्रश्न

1. प्रत्येक क्लायंट हा स्वतंत्र डेटा, सेटिंग्ज, ॲडमिन खाती आणि API की सह एक वेगळा टेनंट आहे का?
2. कोणते ॲडमिन रोल्स अस्तित्वात आहेत आणि एखादा रोल एकाच ठिकाणापुरता मर्यादित केला जाऊ शकतो का?
3. तुम्ही Microsoft Entra ID, Okta आणि Google Workspace सह SAML 2.0 सिंगल साइन-ऑन, तसेच SCIM प्रोव्हिजनिंगला सपोर्ट करता का?
4. Captive Portal, कन्सोल, पाठवणारा ईमेल, SMS सेंडर ID आणि रिपोर्ट्स या सर्वांवर आमचा ब्रँड असू शकतो का?
5. कस्टम डोमेन्ससाठी TLS सर्टिफिकेट्स कोण इश्यू आणि रिन्यू करते?
6. तुम्ही कोणत्या एक्सेस पॉईंट व्हेंडर्सना सपोर्ट करता, आणि तुम्ही प्रत्येकासाठी इंटिग्रेशन मार्गदर्शिका प्रकाशित करता का?
7. तुम्ही RADIUS ऑथेंटिकेशन आणि अकाउंटिंग, 802.1X, iPSK, Passpoint आणि OpenRoaming ला सपोर्ट करता का?
8. बिलिंग युनिट, किमान कालावधी आणि वार्षिक वाढ किती आहे?
9. तुम्ही SMS, API एक्सेस किंवा अतिरिक्त टेनंट्ससाठी किती शुल्क आकारता?
10. तुम्ही कोणत्याही स्वतःच्या उद्देशासाठी गेस्ट डेटाचा वापर करता का?
11. कन्सेंट रेकॉर्डमध्ये काय समाविष्ट असते आणि आमचा क्लायंट ते कोणत्या फॉरमॅटमध्ये एक्सपोर्ट करू शकतो?
12. करार संपल्यावर तुम्ही डेटा कसा आणि कधी परत करता किंवा हटवता?
13. तुमची सब-प्रोसेसर यादी कुठे आहे आणि तुम्ही बदलांची सूचना कशी देता?
14. तुमचे गंभीरतेचे स्तर (severity levels) आणि रिस्पॉन्स टार्गेट्स काय आहेत, आणि डेटा ब्रीच झाल्यास तुम्ही आम्हाला किती वेगाने सूचित कराल?
15. तुमच्या ISO 27001 प्रमाणपत्राची व्याप्ती (scope) काय आहे?

रेड फ्लॅग्स ज्यांच्यामुळे स्वाक्षरी थांबवली पाहिजे

क्षेत्र	चांगले स्वरूप कसे असते	रेड फ्लॅग
मल्टी-टेनेन्सी	आयसोलेटेड डेटा आणि API की सह प्रत्येक क्लायंटसाठी स्वतंत्र टेनंट	क्लायंट एकाच सामायिक खात्यातील फोल्डरमध्ये असतात
ब्रँडिंग	पोर्टल, कन्सोल, ईमेल, SMS आणि रिपोर्टवर तुमचा डोमेन	ईमेल, कन्सोल URL किंवा रिपोर्टच्या फुटरमध्ये व्हेंडरचे नाव
हार्डवेअर	नामांकित व्हेंडर्स, प्रत्येकाची प्रकाशित इंटिग्रेशन मार्गदर्शिका	कोणतीही नामांकित यादी नसलेले "सर्व प्रमुख व्हेंडर्स"
बिलिंग	बिलिंग युनिट तुम्ही क्लायंटकडून आकारत असलेल्या शुल्काशी जुळते, मर्यादित वाढीसह	अमर्यादित प्रति-गेस्ट किंमत, किंवा फक्त सर्वोच्च स्तरावर API एक्सेस
गेस्ट डेटा	क्लायंट हा कंट्रोलर आहे; व्हेंडर फक्त सूचनेनुसार प्रक्रिया करतो	व्हेंडर स्वतः गेस्ट डेटा वापरण्याचा अधिकार राखून ठेवतो
एक्झिट	संमतीच्या नोंदी मान्य केलेल्या कालावधीत CSV किंवा JSON मध्ये एक्सपोर्ट केल्या जातात	केवळ विनंतीनुसार, शुल्कासाठी किंवा मालकीच्या (proprietary) फॉरमॅटमध्ये एक्सपोर्ट
सपोर्ट	गंभीरतेचे स्तर, रिस्पॉन्स टार्गेट्स आणि एक नामांकित एस्केलेशन संपर्क	कोणताही निश्चित रिस्पॉन्स वेळ नसलेला फक्त तिकीट फॉर्म

व्यावहारिक उदाहरण: रीसेलर बदलणारी एक परिषद (council)

परिस्थिती. एका रीसेलरने 22 ग्रंथालये आणि मनोरंजन केंद्रांमध्ये कौंटी कौन्सिलसाठी गेस्ट WiFi चालवले. पुन्हा टेंडर काढताना, कौन्सिलने वेगळा सप्लायर निवडला. त्याच्या इव्हेंट टीमकडे अपडेट्स प्राप्त करण्यासाठी सुमारे 38,000 अभ्यागतांची संमती होती.

काय केले गेले. रीसेलरच्या व्हेंडर करारात Article 28(3)(g) अंतर्गत एक्झिट क्लॉज समाविष्ट होता. या क्लॉजमध्ये टाइमस्टॅम्प, वर्डिंग व्हर्जन आणि चॅनेलसह 30 दिवसांच्या आत प्रत्येक कन्सेंट रेकॉर्डचे JSON एक्सपोर्ट आवश्यक होते.

निकाल (प्रातिनिधिक आकडे). कौन्सिलने सर्व 38,000 कन्सेंट रेकॉर्ड्स त्यांच्या नवीन प्लॅटफॉर्मवर इम्पोर्ट केले. पुन्हा-परवानगी मोहीम न राबवता त्यांनी अभ्यागतांना ईमेल पाठवणे सुरू ठेवले. रीसेलरने त्यांच्या डेटाची प्रत हटवल्याच्या लिखित पुष्टीकरणासह करार समाप्त केला.

वारंवार विचारले जाणारे प्रश्न

व्हाईट लेबल Captive Portal म्हणजे काय?

व्हाईट लेबल Captive Portal हे गेस्ट WiFi लॉगिन सॉफ्टवेअर आहे जे MSP किंवा रीसेलर स्वतःच्या ब्रँडखाली विकतात. व्हेंडर प्लॅटफॉर्म चालवतो, तर तुमचा लोगो, डोमेन, सेंडर ईमेल आणि रिपोर्ट्स क्लायंटसमोर प्रदर्शित होतात. सर्वात मजबूत प्लॅटफॉर्म्स खऱ्या मल्टी-टेनेन्सीची जोड देतात. त्यानंतर प्रत्येक क्लायंट स्वतःच्या आयसोलेटेड टेनंटमध्ये असतो, ज्यामध्ये व्हेन्यू मॅनेजर आणि मार्केटिंग टीमसाठी नियुक्त केलेल्या ॲडमिन भूमिका असतात.

MSP Captive Portal ला स्वतःचे ब्रँडिंग देऊ शकते का?

होय, जर प्लॅटफॉर्म पूर्ण ब्रँडिंगची सुविधा देत असेल तर. लॉगिन पेज तुमच्या डोमेनवरून वैध TLS प्रमाणपत्रासह लोड झाले पाहिजे. ईमेल तुमच्या डोमेनवरून SPF, DKIM आणि DMARC अलाइनमेंटसह पाठवले जावेत. ॲडमिन कन्सोल आणि रिपोर्टमध्ये कोणत्याही व्हेंडरचा संदर्भ नसावा. जर ब्रँडिंग फक्त लॉगिन पेजपुरतेच मर्यादित असेल, तर तुमच्या क्लायंटला दरमहा व्हेंडरचे नाव दिसेल.

व्हाईट लेबल Captive Portal सॉफ्टवेअरची किंमत कशी ठरवली जाते?

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

व्हाईट लेबल पोर्टलने कोणत्या ॲक्सेस पॉईंट्सना सपोर्ट केला पाहिजे?

याने तुमच्या क्लायंटच्या नेटवर्कमधील प्रत्येक व्हेंडरला वैयक्तिकरित्या सपोर्ट केला पाहिजे: Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet. प्रत्येकासाठी, एक्सटर्नल Captive Portal रिडायरेक्ट, RADIUS ऑथेंटिकेशन आणि अकाउंटिंग, आणि वॉल्ड गार्डन सपोर्टची खात्री करा, ज्याला प्रकाशित इंटिग्रेशन मार्गदर्शकाचा पाठिंबा असेल. Purple चे Guest WiFi हे हार्डवेअर - ॲग्नोस्टिक क्लाउड ओव्हरले म्हणून या आठही सिस्टीमवर चालते.

रिसेलर प्लॅटफॉर्मवर गेस्ट डेटाचा मालक कोण असतो?

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

नवीन Captive Portal प्लॅटफॉर्मवर जाण्यासाठी क्लायंटला नवीन हार्डवेअरची आवश्यकता आहे का?

नाही, जर प्लॅटफॉर्म हार्डवेअर - ॲग्नोस्टिक असेल तर नाही. क्लाउड ओव्हरले एक्सटर्नल Captive Portal रिडायरेक्ट आणि RADIUS चा वापर करून तुमच्या क्लायंटच्या विद्यमान ॲक्सेस पॉईंट्सशी कनेक्ट होते. तुम्ही उपकरणे बदलण्याऐवजी नवीन प्लॅटफॉर्मकडे पॉइंट करण्यासाठी नेटवर्क पुन्हा कॉन्फिगर करता. कटओव्हरचे वेळापत्रक ठरवण्यापूर्वी तुमचे क्लायंट प्रत्यक्षात वापरत असलेल्या फर्मवेअर व्हर्जनवर चाचणी घ्या.

तुम्ही दुसऱ्या Captive Portal प्लॅटफॉर्मवरून विद्यमान क्लायंटचे मायग्रेशन करू शकता का?

होय, जर तुमचा सध्याचा व्हेंडर प्रत्येक क्लायंटच्या संमतीच्या नोंदी आणि गेस्ट डेटा वापरण्यायोग्य फॉरमॅटमध्ये एक्सपोर्ट करत असेल. GDPR आर्टिकल 28(3)(g) चा संदर्भ देऊन टाईमस्टॅम्प, संमतीचे शब्द आणि चॅनेलसह CSV किंवा JSON एक्सपोर्टची विनंती करा. नवीन टेनंटमध्ये पोर्टल टेम्पलेट्स पुन्हा तयार करा आणि पायलट व्हेन्यूमध्ये दोन्ही प्लॅटफॉर्म चालवा. त्यानंतर जोखीम मर्यादित करण्यासाठी उर्वरित साईट्स बॅचमध्ये स्विच करा.