व्हाइट लेबल 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 सॉफ़्टवेयर आपको उस लॉगिन पेज को अपने ब्रांड के तहत बेचने की अनुमति देता है। इसके पीछे का कंसोल और रिपोर्ट भी आपका ब्रांड प्रदर्शित करते हैं।

तीन कमर्शियल मॉडल रीसेलर मार्केट में हावी हैं। वे तीन बिंदुओं पर भिन्न हैं:

• क्लाइंट अनुबंध किसके पास है
• आपका ब्रांड कहाँ तक पहुँचता है
• प्रत्येक क्लाइंट का डेटा कितनी सफाई से अलग किया गया है

पहले मॉडल चुनें, फिर उसके भीतर वेंडरों को अंक दें।

मॉडल	आपका ब्रांड किस पर दिखाई देता है	क्लाइंट डेटा अलगाव	क्लाइंट अनुबंध किसके पास है	विशिष्ट बिलिंग	इनके लिए उपयुक्त
फुल white label, मल्टी-टेनेंट	लॉगिन पेज, कस्टम डोमेन, एडमिन कंसोल, ईमेल, SMS और रिपोर्ट	स्कोप्ड एडमिन भूमिकाओं और API कुंजियों के साथ प्रति क्लाइंट अलग टेनेंट	आप	प्रति साइट या प्रति एक्सेस प्वाइंट थोक, आप खुदरा मूल्य तय करते हैं	सर्विस डेस्क और वेन्यू क्लाइंट्स के पोर्टफोलियो वाले MSPs
सह-ब्रांडेड रीसेलर	केवल लॉगिन पेज और ईमेल; कंसोल और रिपोर्ट वेंडर दिखाते हैं	एक साझा खाते के भीतर सब-खाते या फ़ोल्डर	आप या वेंडर	वेंडर सूची मूल्य माइनस रीसेलर छूट	हार्डवेयर बिक्री में गेस्ट WiFi जोड़ने वाले रीसेलर
रेफरल या प्रत्यक्ष अनुबंध	पूरे में वेंडर ब्रांड; आप इंस्टॉलर के रूप में दिखाई देते हैं	क्लाइंट का अपना वेंडर खाता	वेंडर	वेंडर सूची मूल्य; आप रेफरल शुल्क या सेवा आय अर्जित करते हैं	बिना किसी सपोर्ट डेस्क के एक-बारी की परियोजनाएं चलाने वाले पार्टनर

सपोर्ट डेस्क और कई वेन्यू क्लाइंट्स वाले अधिकांश MSPs पहले मॉडल को चुनते हैं। इस गाइड का शेष भाग उसी मॉडल को मानता है और आपको दिखाता है कि इसके लिए वेंडर के दावे का परीक्षण कैसे करें।

जहाँ white label Captive Portal प्लेटफॉर्म वास्तव में भिन्न होते हैं

प्रत्येक वेंडर डेमो एक ब्रांडेड लॉगिन पेज दिखाता है। वास्तविक अंतर छह क्षेत्रों में नीचे छिपे होते हैं। वे मिलकर आपके मार्जिन, आपकी अनुपालन जोखिम और आपके सपोर्ट लोड का निर्णय लेते हैं।

वास्तविक मल्टी-टेनेंसी और डेलिगेटेड एडमिन

वास्तविक मल्टी-टेनेंसी का अर्थ है प्रति टेनेंट एक क्लाइंट। डेटा, सेटिंग्स, एडमिन खाते और API कुंजियाँ प्लेटफॉर्म स्तर पर अलग की जाती हैं। एक साझा खाते के भीतर एक फ़ोल्डर एक टेनेंट नहीं है। यदि एक गलत कॉन्फ़िगर की गई भूमिका एक क्लाइंट की गेस्ट सूची को दूसरे के सामने उजागर करती है, तो आप उल्लंघन की जिम्मेदारी उठाते हैं।

एक ट्रायल टेनेंट में डेलिगेटेड एडमिन का परीक्षण करें, न कि किसी स्लाइड पर। आपको कम से कम चार भूमिकाओं की आवश्यकता है:

• आपका अपना सुपर एडमिन
• एक क्लाइंट एडमिन
• एक स्थल प्रबंधक जो केवल एक साइट तक सीमित है
• एक रीड-ओनली मार्केटिंग भूमिका

एक होटल के जनरल मैनेजर को केवल अपना होटल देखना चाहिए और कुछ नहीं।

SAML 2.0 के माध्यम से सिंगल साइन-ऑन का अनुरोध करें, जो फेडरेटेड लॉगिन के लिए OASIS मानक है। यह Microsoft Entra ID, Okta और Google Workspace के साथ काम करना चाहिए।

SCIM 2.0 (क्रॉस-डोमेन पहचान प्रबंधन के लिए सिस्टम, RFC 7643 और RFC 7644) एडमिन खातों को बनाने और हटाने को स्वचालित करता है। इसके बिना, आपके क्लाइंट का कोई पूर्व कर्मचारी तब तक कंसोल एक्सेस रखता है जब तक कि किसी को याद न आए। यह जांचें कि ऑडिट लॉग प्रति टेनेंट रखे जाते हैं और निर्यात किए जा सकते हैं, ताकि आप क्लाइंट को दिखा सकें कि किसने क्या बदला है।

ब्रांडिंग की गहराई: डोमेन, प्रेषक ईमेल, पोर्टल और रिपोर्ट

ब्रांडिंग की गहराई वह जगह है जहाँ अधिकांश "व्हाइट लेबल" दावे कम पड़ जाते हैं। हर उस सतह को स्कोर करें जिसे कोई अतिथि या क्लाइंट देख सकता है:

• लॉगिन पेज डोमेन। Captive Portal आपके डोमेन या आपके क्लाइंट के डोमेन से लोड होना चाहिए। वेंडर को अपने TLS प्रमाण पत्र को स्वचालित रूप से नवीनीकृत करना चाहिए।
• एडमिन कंसोल। साइन-इन स्क्रीन पर आपका लोगो, रंग और URL होना चाहिए। वेंडर-ब्रांडेड कंसोल आपके क्लाइंट को ठीक-ठीक बताता है कि नवीनीकरण के समय किसे कॉल करना है।
• प्रेषक ईमेल। सत्यापन कोड और मार्केटिंग ईमेल आपके डोमेन से भेजे जाने चाहिए। इसके लिए आपके डोमेन से संरेखित SPF (RFC 7208), DKIM (RFC 6376) और DMARC (RFC 7489) की आवश्यकता होती है, अन्यथा संदेश स्पैम में चले जाते हैं।
• SMS प्रेषक ID। सत्यापन टेक्स्ट संदेशों में आपका या स्थल का नाम दिखना चाहिए, न कि वेंडर का।
• रिपोर्ट। निर्धारित निर्यात और डैशबोर्ड में आपकी ब्रांडिंग होनी चाहिए, जिसमें कोई वेंडर वॉटरमार्क न हो। यदि आप WiFi Analytics को फिर से बेचते हैं, तो मासिक रिपोर्ट ही वह उत्पाद है जिसे आपका क्लाइंट वास्तव में देखता है।
• सहायता लिंक और स्थिति पृष्ठ। कंसोल के लिंक आपके ज्ञान आधार की ओर इंगित करने चाहिए, या कहीं नहीं।

प्रति-टेनेंट टेम्पलेट भी महत्वपूर्ण हैं। एक पब समूह और एक परिषद अलग-अलग लॉगिन फ़्लो, सहमति शब्द और भाषाएं चाहते हैं।

आपके इंस्टॉल किए गए बेस में हार्डवेयर कवरेज

आपके क्लाइंट्स के पास पहले से ही एक्सेस पॉइंट हैं, और वे शायद ही कभी किसी एक वेंडर से आते हैं। नाम से और प्रबंधन प्लेटफॉर्म द्वारा समर्थित सूची मांगें: Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks और Fortinet। "सभी प्रमुख वेंडर" एक चेतावनी का संकेत है, उत्तर नहीं।

समर्थन का अर्थ केवल एक रीडायरेक्ट से अधिक है। प्रत्येक वेंडर के लिए, चार क्षमताओं की पुष्टि करें:

• बाहरी captive portal रीडायरेक्ट
• RADIUS (रिमोट प्रमाणीकरण डायल-इन उपयोगकर्ता सेवा, 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 भी कहा जाता है, लौटने वाले मेहमानों को बिना किसी पोर्टल के स्वचालित रूप से फिर से कनेक्ट करने की अनुमति देता है। OpenRoaming, जो Wireless Broadband Alliance फ़ेडरेशन है, भाग लेने वाले नेटवर्क पर भी यही करता है। इनके बिना एक प्लेटफॉर्म आपकी भविष्य की बिक्री क्षमता को सीमित कर देता है।

GDPR सहमति रिकॉर्ड जो आपके ग्राहक के स्वामित्व में हैं

GDPR के तहत, आपका ग्राहक, जो वेन्यू ऑपरेटर है, आमतौर पर गेस्ट डेटा का कंट्रोलर होता है (अनुच्छेद 4(7))। आप प्रोसेसर के रूप में कार्य करते हैं, और प्लेटफॉर्म विक्रेता आपके सब-प्रोसेसर के रूप में। अनुच्छेद 28 उस श्रृंखला की प्रत्येक कड़ी पर एक लिखित अनुबंध की आवश्यकता रखता है। अनुच्छेद 28(2) प्रोसेसर को कंट्रोलर के पूर्व लिखित प्राधिकरण के बिना किसी सब-प्रोसेसर को शामिल करने से रोकता है।

अनुच्छेद 7(1) के अनुसार कंट्रोलर को सहमति प्रदर्शित करना आवश्यक है। इसका मतलब है प्रति गेस्ट एक पूर्ण रिकॉर्ड:

• टाइमस्टैम्प
• दिखाया गया सटीक पाठ
• गोपनीयता सूचना संस्करण
• चैनल
• स्वीकृत उद्देश्य

एक "मार्केटिंग ऑप्टेड-इन" फ़्लैग पर्याप्त नहीं है। रीसाइटल 32 जोड़ता है कि पहले से टिक किए गए बॉक्स सहमति के रूप में नहीं गिने जाते हैं। UK ईमेल और SMS मार्केटिंग के लिए, सहमति को Privacy and Electronic Communications Regulations (PECR) को भी संतुष्ट करना होगा।

हस्ताक्षर करने से पहले अनुबंध के तीन बिंदुओं की जांच करें:

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

Purple लॉगिन फ़्लो में सचेत-पसंद ऑप्ट-इन्स का निर्माण करता है, ताकि प्रत्येक गेस्ट सक्रिय रूप से मार्केटिंग का चयन करे। Purple ISO 27001 प्रमाणित और GDPR अनुपालनकर्ता है।

API और वेबहुक एक्सेस

APIs यह तय करते हैं कि आप अपनी खुद की सेवा का कितना हिस्सा बना सकते हैं। एकल टेनेंट तक सीमित कुंजियों के साथ एक प्रलेखित REST API मांगें। तब एक समझौता की गई कुंजी हर ग्राहक तक नहीं पहुंच सकती। टेनेंट्स, वेन्यू और पोर्टल टेम्पलेट्स के लिए बल्क एंडपॉइंट्स आपको क्लिक करने के बजाय ऑनबोर्डिंग को स्क्रिप्ट करने की अनुमति देते हैं।

वेबहुक घटनाओं को पुश करते हैं, जैसे कि एक गेस्ट लॉगिन या एक नया ऑप्ट-इन, आपके ग्राहक के CRM में जैसे ही वे घटित होते हैं। तीन चीजों की जांच करें:

• पेलोड हस्ताक्षरित हैं, ताकि प्राप्तकर्ता प्रेषक को सत्यापित कर सके
• विफल डिलीवरी स्वचालित रूप से पुनः प्रयास करती हैं
• API एक्सेस के लिए दर सीमाएं और कोई भी अतिरिक्त शुल्क लिखित रूप में पुष्ट किया जाता है

सहायता में वृद्धि (सपोर्ट एस्केलेशन)

व्हाइट लेबल प्लेटफॉर्म पर, आप पहली पंक्ति की सहायता (फ़र्स्ट-लाइन सपोर्ट) हैं। वेन्यू आपको कॉल करता है, और विक्रेता को कभी भी सीधे आपके क्लाइंट से संपर्क नहीं करना चाहिए। यह विक्रेता के दूसरी पंक्ति के मार्ग (सेकंड-लाइन रूट) को आपकी सबसे महत्वपूर्ण सेवा शर्त बनाता है।

इन्हें अनुबंध में लिखें:

• परिभाषित गंभीरता के स्तर
• प्रत्येक स्तर के लिए प्रतिक्रिया लक्ष्य
• एक नामबद्ध पार्टनर संपर्क
• साइट-डाउन घटना के लिए इंजीनियरिंग का एक सीधा मार्ग

Article 33(2) के अनुसार प्रोसेसर को बिना किसी अनुचित देरी के नियंत्रक को उल्लंघन की सूचना देना आवश्यक है। आपका विक्रेता अनुबंध आपको इतना तेज़ नोटिस प्रदान करने वाला होना चाहिए कि आप अपने क्लाइंट के प्रति उस कर्तव्य को पूरा कर सकें।

पैमाने (स्केल) के प्रमाण भी मांगें। Purple ने 90 से अधिक देशों में 80,000+ लाइव वेन्यू के माध्यम से 2024 में 440 मिलियन लॉग इन संभाले (Purple का अपना डेटा)।

पूरी तरह से मल्टी-टेनेंट व्हाइट लेबल प्लेटफॉर्म चुनना कब सही निर्णय है

जब आप क्लाइंट संबंध को शुरू से अंत तक स्वयं प्रबंधित करते हैं, तब पूर्ण व्हाइट लेबल चुनें। इसका आमतौर पर मतलब है कि तीन बातें सच हैं:

• आप एक सर्विस डेस्क चलाते हैं
• आप ग्राहकों को मासिक बिल भेजते हैं
• आपके पास विभिन्न क्षेत्रों में कई वेन्यू क्लाइंट हैं

फिर गेस्ट WiFi आपके स्वयं के चालान पर एक आवर्ती लाइन बन जाता है।

यह मिश्रित हार्डवेयर संपत्तियों के लिए भी उपयुक्त है। एक हार्डवेयर-अज्ञेय (hardware-agnostic) प्लेटफॉर्म कई विक्रेता-विशिष्ट कंसोल को बदल देता है। आपके इंजीनियर एक सिस्टम सीखते हैं, और प्रत्येक क्लाइंट की रिपोर्ट एक जैसी दिखती है।

व्यावहारिक परिदृश्य: दो हार्डवेयर विक्रेताओं के साथ एक क्षेत्रीय होटल समूह

स्थिति। एक MSP ने 14-होटल वाले क्षेत्रीय समूह के लिए गेस्ट WiFi का प्रबंधन किया। नौ होटल Cisco Meraki चलाते थे। पिछले वर्ष अधिग्रहित पांच होटल, उनके बीच 210 एक्सेस पॉइंट्स के साथ Ruckus चलाते थे। MSP का शॉर्टलिस्ट किया गया Captive Portal केवल Meraki का समर्थन करता था।

क्या किया गया। MSP ने अपनी शॉर्टलिस्ट को हार्डवेयर-अज्ञेय प्लेटफॉर्म पर स्थानांतरित किया और दोनों विक्रेताओं को कवर करते हुए दो-होटल पायलट चलाया। इसने प्रत्येक होटल को वेन्यू के रूप में रखते हुए समूह के लिए एक टैनेंट बनाया। जनरल मैनेजरों को केवल वेन्यू-स्तरीय भूमिकाएं दी गईं। ग्रुप मार्केटिंग लीड को सभी 14 होटलों में केवल पढ़ने योग्य (रीड-ओनली) रिपोर्टिंग प्राप्त हुई।

परिणाम (उदाहरण के आंकड़े)। सभी 210 Ruckus एक्सेस पॉइंट्स को बदलने के बजाय सेवा में बनाए रखा गया। समूह ने प्रत्येक संपत्ति में एक लॉगिन डिज़ाइन, एक सहमति शब्द और एक मासिक रिपोर्ट चलाई।

क्षेत्र के बारे में अधिक जानकारी के लिए, Hotels और WiFi in restaurants: a UK guide to coverage and security देखें।

सह-ब्रांडेड (co-branded) या प्रत्यक्ष अनुबंध चुनना कब सही निर्णय है

पूर्ण व्हाइट लेबल हमेशा ओवरहेड के लायक नहीं होता है। आप किसी हार्डवेयर प्रोजेक्ट के लिए वन-ऑफ़ एड-ऑन के रूप में गेस्ट WiFi बेच सकते हैं। उस स्थिति में सह-ब्रांडेड खाता या रेफ़रल अधिक सरल होता है, और आप उस उत्पाद के लिए प्रथम-पंक्ति सहायता से बचते हैं जिसे आप नहीं चलाना चाहते हैं।

एक प्रत्यक्ष अनुबंध इन-हाउस IT वाले बड़े एकल ग्राहकों के लिए उपयुक्त है, जैसे कि एक राष्ट्रीय Retail श्रृंखला। उनकी खरीद टीम सीधे विक्रेता के साथ अनुबंध करना पसंद कर सकती है। विनियमित क्षेत्रों में ग्राहक, जैसे Healthcare, अक्सर अपना स्वयं का आपूर्तिकर्ता आश्वासन भी चलाते हैं।

आप अभी भी इंस्टॉल, नेटवर्क मैनेजमेंट और साइट सर्वे से कमाई करते हैं। WiFi साइट सर्वे: एक व्यावहारिक योजना गाइड उस बुनियादी काम को कवर करता है।

वाइट लेबल कैप्टिव पोर्टल सॉफ़्टवेयर की कीमत कैसे तय की जाती है

तीन बिलिंग यूनिट सबसे प्रमुख हैं: प्रति साइट, प्रति एक्सेस पॉइंट और प्रति गेस्ट। अधिकांश वेंडर थोक में बेचते हैं, और आप खुदरा मूल्य तय करते हैं। आपका मार्जिन छूट से अधिक इस बात पर निर्भर करता है कि आपकी बिलिंग यूनिट वेंडर की बिलिंग यूनिट से कितनी मेल खाती है।

बिलिंग मॉडल	आप भुगतान करते हैं	लागत की भविष्यवाणी	आपके लिए मुख्य जोखिम	सबसे उपयुक्त
प्रति साइट	प्रत्येक स्थान, आकार की परवाह किए बिना	उच्च: केवल तब बदलता है जब कोई स्थान जुड़ता है या हटता है	छोटे स्थानों की लागत बड़े स्थानों के समान होती है	समान स्थानों की श्रृंखलाएं: पब, त्वरित सेवा वाले रेस्तरां, हाई स्ट्रीट रिटेल
प्रति एक्सेस पॉइंट	प्रत्येक प्रबंधित एक्सेस पॉइंट	उच्च: केवल हार्डवेयर प्रोजेक्ट के साथ बदलता है	डेंसिफिकेशन या WiFi 7 रिफ्रेश नए लाइसेंस जोड़ता है	स्टेडियम, सम्मेलन केंद्र और उपस्थिति शिखर वाले अन्य स्थान
प्रति गेस्ट	प्रति माह प्रत्येक प्रमाणित अतिथि	कम: उपस्थिति के साथ बदलता है	जब तक सीमित न हो, इवेंट के दौरान बिल का झटका लगता है	पायलट, मौसमी स्थान और कम ट्रैफ़िक वाले स्थान

सबसे सुरक्षित संरचना आपके क्लाइंट को उसी यूनिट में बिल भेजती है जिसमें वेंडर आपको बिल भेजता है। यदि आप प्रति एक्सेस पॉइंट भुगतान करते हैं लेकिन प्रति साइट शुल्क लेते हैं, तो हर डेंसिफिकेशन प्रोजेक्ट आपके मार्जिन को कम कर देता है।

हस्ताक्षर करने से पहले, चार अन्य लागतों की जांच करें:

• न्यूनतम शर्तें
• वार्षिक वृद्धि खंड
• 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. क्या कैप्टिव पोर्टल, कंसोल, प्रेषक ईमेल, SMS प्रेषक आईडी और रिपोर्ट सभी पर हमारा ब्रांड हो सकता है?
5. कस्टम डोमेन के लिए TLS प्रमाणपत्र कौन जारी और नवीनीकृत करता है?
6. आप किन एक्सेस प्वाइंट विक्रेताओं का समर्थन करते हैं, और क्या आप प्रत्येक के लिए एक एकीकरण गाइड प्रकाशित करते हैं?
7. क्या आप RADIUS प्रमाणन और लेखांकन, 802.1X, iPSK, Passpoint और OpenRoaming का समर्थन करते हैं?
8. बिलिंग इकाई, न्यूनतम अवधि और वार्षिक वृद्धि क्या हैं?
9. आप SMS, API पहुंच या अतिरिक्त टैलेंट के लिए क्या शुल्क लेते हैं?
10. क्या आप किसी भी अपने उद्देश्य के लिए अतिथि डेटा का उपयोग करते हैं?
11. सहमति रिकॉर्ड में क्या शामिल है, और हमारा ग्राहक इसे किन प्रारूपों में निर्यात कर सकता है?
12. अनुबंध समाप्त होने पर आप डेटा कैसे और कब वापस करते हैं या हटाते हैं?
13. आपकी उप-प्रॉसेसर सूची कहाँ है, और आप परिवर्तनों की सूचना कैसे देते हैं?
14. आपके गंभीरता के स्तर और प्रतिक्रिया लक्ष्य क्या हैं, और आप हमें उल्लंघन की सूचना कितनी तेजी से देंगे?
15. आपके ISO 27001 प्रमाण पत्र का दायरा क्या है?

रेड फ्लैग जो हस्ताक्षर को रोक देने चाहिए

क्षेत्र	अच्छा कैसा दिखता है	रेड फ्लैग
मल्टी-टेनेंसी	पृथक डेटा और API कुंजियों के साथ प्रति ग्राहक अलग टेनेंट	ग्राहक एक साझा खाते के अंदर फ़ोल्डरों में स्थित हैं
ब्रांडिंग	पोर्टल, कंसोल, ईमेल, SMS और रिपोर्ट पर आपका डोमेन	ईमेल, कंसोल URL या रिपोर्ट फ़ुटर में विक्रेता का नाम
हार्डवेयर	नामित विक्रेता, प्रत्येक एक प्रकाशित एकीकरण गाइड के साथ	बिना किसी नामित सूची के "सभी प्रमुख विक्रेता"
बिलिंग	बिलिंग इकाई इस बात से मेल खाती है कि आप ग्राहकों से शुल्क कैसे लेते हैं, सीमित वृद्धि के साथ	अनकैप्ड प्रति-अतिथि मूल्य निर्धारण, या केवल शीर्ष श्रेणी पर API पहुंच
अतिथि डेटा	ग्राहक नियंत्रक है; विक्रेता केवल निर्देश पर प्रक्रिया करता है	विक्रेता स्वयं अतिथि डेटा का उपयोग करने का अधिकार सुरक्षित रखता है
निकास	सहमति रिकॉर्ड एक सहमत अवधि के भीतर CSV या JSON में निर्यात किए जाते हैं	केवल अनुरोध पर निर्यात, शुल्क के लिए, या किसी मालिकाना प्रारूप में
सहायता	गंभीरता के स्तर, प्रतिक्रिया लक्ष्य और एक नामित एस्केलेशन संपर्क	केवल टिकट फॉर्म, बिना किसी परिभाषित प्रतिक्रिया समय के
सहायता	गंभीरता स्तर, प्रतिक्रिया लक्ष्य और एक नामित एस्केलेशन संपर्क	बिना किसी परिभाषित प्रतिक्रिया समय के केवल टिकट फॉर्म

कार्य किया गया परिदृश्य: एक परिषद द्वारा पुनर्विक्रेता बदलना

स्थिति। एक पुनर्विक्रेता ने 22 पुस्तकालयों और अवकाश केंद्रों में एक काउंटी परिषद के लिए अतिथि WiFi चलाया। फिर से निविदा निकालने पर, परिषद ने एक अलग आपूर्तिकर्ता चुना। इसकी कार्यक्रम टीम के पास अपडेट प्राप्त करने के लिए लगभग 38,000 आगंतुकों से सहमति थी।

क्या किया गया था। पुनर्विक्रेता के विक्रेता अनुबंध में एक अनुच्छेद 28(3)(g) निकास खंड शामिल था। खंड में टाइमस्टैम्प, शब्दावली संस्करण और चैनल के साथ, 30 दिनों के भीतर प्रत्येक सहमति रिकॉर्ड के JSON निर्यात की आवश्यकता थी।

परिणाम (उदाहरणात्मक आंकड़े)। परिषद ने अपने नए प्लेटफॉर्म में सभी 38,000 सहमति रिकॉर्ड आयात किए। इसने पुन: अनुमति अभियान के बिना आगंतुकों को ईमेल भेजना जारी रखा। पुनर्विक्रेता ने लिखित पुष्टि के साथ बाहर निकल गया कि उसके डेटा की प्रति हटा दी गई थी।

अक्सर पूछे जाने वाले प्रश्न

व्हाइट लेबल Captive Portal क्या है?

व्हाइट लेबल Captive Portal एक अतिथि WiFi लॉगिन सॉफ़्टवेयर है जिसे एक MSP या पुनर्विक्रेता अपने स्वयं के ब्रांड के तहत बेचता है। विक्रेता प्लेटफॉर्म चलाता है, जबकि आपका लोगो, डोमेन, प्रेषक ईमेल और रिपोर्ट ग्राहक के सामने होती हैं। सबसे मजबूत प्लेटफॉर्म सच्चे मल्टी-टेनेंसी जोड़ते हैं। प्रत्येक ग्राहक फिर अपने स्वयं के पृथक टेनेंट में बैठता है, जिसमें स्थल प्रबंधकों और विपणन टीमों के लिए प्रत्यायोजित व्यवस्थापक भूमिकाएं होती हैं।

क्या कोई MSP किसी Captive Portal को अपने रूप में ब्रांड कर सकता है?

हाँ, बशर्ते प्लेटफ़ॉर्म पूर्ण ब्रांडिंग गहराई प्रदान करता हो। लॉगिन पेज को एक मान्य TLS प्रमाण पत्र के साथ आपके डोमेन से लोड होना चाहिए। ईमेल SPF, DKIM और DMARC संरेखित होकर आपके डोमेन से भेजे जाने चाहिए। एडमिन कंसोल और रिपोर्टों में किसी भी विक्रेता का संदर्भ नहीं होना चाहिए। यदि ब्रांडिंग केवल लॉगिन पेज तक सीमित रहती है, तो आपका क्लाइंट हर महीने विक्रेता का नाम देखता है।

White label Captive Portal सॉफ्टवेयर की कीमत कैसे तय की जाती है?

अधिकांश विक्रेता प्रति साइट, प्रति एक्सेस पॉइंट या प्रति गेस्ट के आधार पर थोक (wholesale) कीमत तय करते हैं ताकि आप खुदरा (retail) मूल्य निर्धारित कर सकें। प्रति साइट मॉडल समान प्रकार के स्थानों की श्रृंखलाओं के लिए उपयुक्त है। प्रति एक्सेस पॉइंट मॉडल बड़ी भीड़ वाले स्थानों के लिए उपयुक्त है। प्रति गेस्ट मॉडल पायलट प्रोजेक्ट्स और कम-ट्रैफिक वाली साइटों के लिए उपयुक्त है, लेकिन यह मांग के साथ बदलता रहता है। अपने मार्जिन की सुरक्षा के लिए, अपने क्लाइंट से उसी यूनिट में बिल लें जिसमें विक्रेता आपसे बिल लेता है।

White label पोर्टल को किन एक्सेस पॉइंट्स का समर्थन करना चाहिए?

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

रीसेलर प्लेटफॉर्म पर गेस्ट डेटा का मालिक कौन होता है?

आपके क्लाइंट, यानी वेन्यू ऑपरेटर को GDPR के तहत नियंत्रक (controller) के रूप में गेस्ट डेटा का मालिक होना चाहिए। आप प्रोसेसर के रूप में और प्लेटफॉर्म विक्रेता सब-प्रोसेसर के रूप में कार्य करते हैं, जो प्रत्येक अनुच्छेद 28 अनुबंध से बंधे होते हैं। उन विक्रेता शर्तों को अस्वीकार करें जो विक्रेता को अपने स्वयं के उद्देश्यों के लिए गेस्ट डेटा का उपयोग करने की अनुमति देती हैं। सहमति रिकॉर्ड मांग पर निर्यात होने चाहिए और अनुबंध समाप्त होने पर आपके क्लाइंट को वापस लौटा दिए जाने चाहिए।

क्या क्लाइंट्स को नए Captive Portal प्लेटफॉर्म पर जाने के लिए नए हार्डवेयर की आवश्यकता है?

नहीं, यदि प्लेटफ़ॉर्म हार्डवेयर-स्वतंत्र है तो नहीं। एक क्लाउड ओवरले बाहरी Captive Portal रीडायरेक्ट और RADIUS का उपयोग करके उन एक्सेस पॉइंट्स से जुड़ता है जिन्हें आपका क्लाइंट पहले से चला रहा है। आप उपकरणों को बदलने के बजाय नए प्लेटफ़ॉर्म की ओर इंगित करने के लिए नेटवर्क को पुनर्गठित करते हैं। कटओवर निर्धारित करने से पहले उन फर्मवेयर संस्करणों पर परीक्षण करें जिन्हें आपके क्लाइंट वास्तव में चलाते हैं।

क्या आप मौजूदा क्लाइंट्स को किसी अन्य Captive Portal प्लेटफॉर्म से माइग्रेट कर सकते हैं?

हाँ, यदि आपका वर्तमान विक्रेता प्रत्येक क्लाइंट के सहमति रिकॉर्ड और गेस्ट डेटा को उपयोग योग्य प्रारूप में निर्यात करता है। GDPR अनुच्छेद 28(3)(g) का हवाला देते हुए टाइमस्टैम्प, सहमति शब्द और चैनल के साथ CSV या JSON निर्यात का अनुरोध करें। नए किरायेदार (tenant) में पोर्टल टेम्प्लेट को फिर से बनाएं और एक पायलट स्थान पर दोनों प्लेटफॉर्म चलाएं। फिर जोखिम को सीमित करने के लिए शेष साइटों को बैचों में स्विच करें।