STEP 01 / CONNECT
Tamu memilih jaringan
Pengguna menghubungkan perangkat ke SSID Guest Wi-Fi yang telah disiapkan venue.
Guest Wi-Fi Solution · Captive Portal
Captive Portal untuk Guest Wi-Fi yang lebih terkontrol.
Bentuk halaman login Guest Wi-Fi yang membantu tamu memahami cara terhubung, data apa yang diminta, metode autentikasi yang tersedia, dan kapan akses diberikan—tanpa mengandalkan shared password yang tersebar.
✓Guest-facing login journey
✓Brand & consent touchpoint
✓Authentication handoff
Connect to Guest Wi-Fi
Follow the venue login step before internet access is granted.
Email or mobile number
Verification / token field
Illustrative anatomy only · replace with approved Nimbus screen
Guest-facing access touchpointGunakan screenshot portal Nimbus yang telah dianonimkan untuk hero final.Proof replacement required
Portal menjembatani koneksi tamu dengan proses autentikasi dan pemberian akses.
01Redirect
02Inform
03Authenticate
04Grant access
What a captive portal does
Dari pilihan SSID menuju akses, setiap tahap perlu memiliki fungsi yang jelas.
Captive portal bukan sekadar landing page promosi. Ia berada di dalam alur akses: mengarahkan tamu, menjelaskan proses, menangani consent atau autentikasi, kemudian meneruskan hasil sesuai arsitektur yang telah diuji.
STEP 02 / PORTAL
Portal dibuka
Controller yang kompatibel mengarahkan pengguna ke halaman portal sesuai flow implementasi.
STEP 03 / AUTH
Consent atau autentikasi
Tamu mengikuti metode login dan memberikan informasi yang memang dibutuhkan oleh proses.
STEP 04 / ACCESS
Akses diteruskan
Hasil portal diserahkan ke komponen yang bertanggung jawab memberi akses sesuai desain jaringan.
!
Architecture boundary: captive portal tidak bekerja sendiri. Redirect, callback, session, certificate, DNS, controller, dan policy handoff harus diperiksa dalam technical assessment atau pilot.
01Brand
02Instruction
03Fields
04Consent
05Success
Portal anatomy
Setiap elemen harus membantu tamu menyelesaikan akses, bukan menambah kebingungan.
Anatomi portal perlu dibaca sebagai rangkaian fungsi. Kehadiran logo, form, login method, terms, bantuan, dan success state harus mengikuti kebutuhan venue serta kemampuan yang tersedia pada build Nimbus.
01
Identitas venueLogo, nama, warna, dan pesan pembuka yang memang dapat dikonfigurasi.
02
Instruksi aksesTamu memahami jaringan yang dipilih, langkah berikutnya, dan bantuan bila proses gagal.
03
Form atau metode loginHanya meminta field dan menampilkan metode yang benar-benar dibutuhkan.
04
Terms dan consentInformasi disajikan sebelum pengguna mengirim data atau melanjutkan proses.
05
Error dan success statePortal memberi respons yang jelas saat input gagal, verifikasi tertunda, atau akses berhasil.
Visual note: diagram di samping adalah wireframe anatomi, bukan tampilan produk. Ganti dengan screen state Nimbus yang telah disetujui pada proof gallery dan hero.
Customization scope
Sesuaikan portal pada bagian yang benar-benar didukung dan relevan bagi venue.
“Custom captive portal” berarti ruang konfigurasi yang terdefinisi. Hindari klaim white-label, builder tanpa batas, atau perubahan bebas bila belum ada capability dan proses implementasi yang dapat dibuktikan.
Validate options
Brand identity
Gunakan identitas venue agar pengguna mengenali siapa yang menyediakan jaringan dan layanan akses.
Verifikasi logo format, color controls, background, safe area, dan batas desain.Validate template
Layout & content
Atur struktur informasi, instruksi, pesan bantuan, serta CTA sesuai template atau komponen yang tersedia.
Jangan menjanjikan drag-and-drop builder bila capability tersebut belum terdokumentasi.Data review
Fields & consent
Tentukan data yang memang dibutuhkan dan pastikan consent serta terms terhubung dengan kebutuhan operasional.
Field, retention, purpose, required/optional state, dan privacy notice memerlukan review.Build dependent
Language
Sajikan instruksi dalam bahasa yang sesuai dengan karakter venue dan profil tamu.
Publikasikan daftar bahasa hanya setelah pilihan, fallback, dan copy management tervalidasi.Flow dependent
Login method display
Tampilkan metode autentikasi yang tersedia untuk environment tersebut dan hilangkan pilihan yang tidak aktif.
Provider, dependency, error handling, dan fallback harus ikut diuji.Proof required
Screen states
Pastikan loading, validation, error, verification, expiry, dan success state memiliki pesan yang dapat dipahami.
Gunakan screen dari build yang sama agar journey tidak terpotong atau menyesatkan.Canonical guardrail: seluruh intent “custom captive portal” diserap oleh halaman ini. Jangan membuat landing page custom captive portal terpisah yang mengulang brand, layout, field, language, atau flow yang sama.
Authentication methods
Pilih metode login berdasarkan kebutuhan identitas, kecepatan, dan operasional.
Metode autentikasi adalah bagian dari journey portal, bukan daftar fitur yang berdiri sendiri. Evaluasi harus mencakup user effort, dependency, provider, consent, delivery, fallback, dan support.
Documented method
Self-registration
Tamu mengisi data yang dibutuhkan melalui portal sebelum melanjutkan ke proses akses.
Periksa field, verification requirement, duplicate handling, consent, error, dan success state pada build aktif.Documented method
Guest token
Token dapat digunakan untuk membentuk journey yang melibatkan issuance atau bantuan operator venue.
Periksa pembuatan, delivery, validity, reuse, expiry, revoke, dan fallback sebelum diterapkan.Verify providers
Social login
Social login dapat disediakan bila provider, credential, consent, dan implementasi tersedia pada build yang digunakan.
Jangan menampilkan logo provider yang belum aktif, belum diuji, atau belum memiliki prerequisite jelas.Verify integration
SMS, email, atau WhatsApp API
Messaging dapat mendukung pengiriman token atau informasi autentikasi setelah integration flow tervalidasi.
Konfirmasi provider, biaya, consent, delivery status, retry, fallback, dan data handling.MethodBest evaluated forKey dependency
Self-registerLow-friction venue formField, consent, verification
TokenOperator-assisted accessIssuance, expiry, support
Social loginProvider-based identityProvider and credentials
MessagingToken or verification deliveryAPI provider and fallback
01
Guest devicePerangkat memilih SSID dan memulai koneksi.
Connect02
Compatible controllerMengarahkan perangkat ke external captive portal sesuai prerequisite.
Redirect03
Nimbus captive portalMenampilkan journey, field, consent, dan metode autentikasi.
Authenticate04
Authentication resultHasil proses diteruskan sesuai mekanisme integrasi yang telah diuji.
Decision05
Access grantedAkses diberikan berdasarkan desain session dan policy pada environment tersebut.
AccessCONCEPTUAL FLOW · VALIDATE CONTROLLER & BUILD
Access policy handoff
Portal selesai bukan berarti seluruh proses jaringan selesai.
Setelah tamu menyelesaikan portal, hasil autentikasi harus diteruskan ke komponen yang memberi akses. Karena itu, evaluasi captive portal wajib melibatkan controller compatibility, redirect, callback, session, dan failure state.
01
Controller compatibilityVendor, model, version, redirect method, DNS, certificate, dan callback perlu diuji.
02
Session behaviorValiditas, expiry, reconnect, roaming, logout, dan penggunaan ulang perlu dibahas.
03
Failure handlingPortal harus tetap memberi arah saat provider, messaging, callback, atau koneksi mengalami gangguan.
04
Operational ownershipTentukan siapa menangani konfigurasi controller, portal, provider, DNS, certificate, dan support tamu.
Compatibility statement: halaman ini tidak menyatakan semua controller atau seluruh versi langsung kompatibel. Gunakan technical assessment dan documented test procedure sebelum rollout.
Venue use cases
Portal yang baik mengikuti ritme venue dan konteks tamu yang berbeda.
Hotel, cafe, mall, dan retail tidak memiliki journey yang sama. Copy, field, metode login, bantuan, dan policy harus dimulai dari environment operasional, bukan dari satu template generik.
Hospitality
Hotel & hospitality
Rancang instruksi dan bantuan untuk lobby, kamar, meeting, serta area publik dengan profil tamu yang beragam.
Explore hospitality →Food & beverage
Restaurants & cafes
Kurangi langkah yang tidak perlu pada venue yang menuntut interaksi cepat dan bantuan sederhana.
Explore restaurants & cafes →
Public venue
Shopping malls
Siapkan journey yang dapat dipahami oleh pengunjung beragam pada area publik dan beberapa titik layanan.
Explore shopping malls →
Retail
Retail & stores
Bentuk portal yang konsisten untuk toko atau cabang sambil menjaga alur bantuan staf tetap sederhana.
Explore retail →
UX & accessibility
Setiap detik kebingungan pada portal berubah menjadi pertanyaan kepada staf.
Pengalaman portal perlu diuji pada perangkat dan kondisi nyata: layar kecil, browser captive, koneksi lambat, keyboard mobile, input salah, provider terlambat, serta pengguna yang tidak memahami istilah teknis.
01
Mobile-first contentJudul, instruksi, field, terms, dan tombol tetap terbaca tanpa zoom atau scroll berlebihan.
02
Clear error languagePesan menjelaskan apa yang salah dan tindakan berikutnya, bukan hanya “error occurred”.
03
Consent before submissionPurpose, terms, dan pilihan pengguna tidak ditempatkan setelah data terkirim.
04
Low-friction formField dibatasi pada informasi yang benar-benar dibutuhkan oleh flow dan operasional.
Portal review checklist
QA
GATE
GATE
Small-screen behaviorLayout, keyboard, orientation, tap targets, and viewport.
ReviewError and retry stateInvalid input, timeout, provider delay, duplicate, and retry.
ReviewContrast and readabilityLabel, text size, focus, link clarity, and status message.
ReviewConsent and termsPurpose, visibility, action, and access to full notice.
ReviewSuccess and next stepConfirmation, access state, destination, and support path.
ReviewDevice/browser testTarget mobile OS, captive browser, and standard browser.
Pilot
Proof gallery
Tampilkan journey portal sebagai bukti, bukan sebagai daftar klaim.
Sebelum halaman dipublikasikan sebagai final, isi galeri dengan screenshot Nimbus dari build yang sama. Anonimkan data, beri caption state, dan hindari stock UI atau screen generatif yang menyerupai fitur produk.
01Portal landing stateReplace with approved Nimbus screen showing brand, instruction, and entry point.
Landing & instruction
Tunjukkan apa yang dilihat tamu sebelum memasukkan data atau memilih metode login.
Caption: build/version, environment, anonymization status.02Authentication stateReplace with actual self-register, token, social, or messaging screen.
Login method
Tampilkan hanya metode yang aktif beserta field, verification, consent, dan dependency yang relevan.
Caption: method, provider if applicable, test date.03Error & retry stateReplace with actual invalid input, timeout, delivery failure, or retry screen.
Error handling
Buktikan bahwa pengguna menerima instruksi yang dapat ditindaklanjuti ketika proses tidak berjalan normal.
Caption: failure scenario and expected recovery path.04Success & access stateReplace with actual confirmation or destination screen after access handoff.
Success state
Tunjukkan bagaimana tamu mengetahui bahwa proses selesai dan apa langkah berikutnya.
Caption: success condition and controller handoff context.Release gate: jangan menghapus label proof slot sampai seluruh gambar berasal dari produk Nimbus, telah diperiksa product/engineer, tidak menampilkan data sensitif, dan konsisten dengan metode serta controller yang dijelaskan.
Captive portal FAQ
Pertanyaan yang perlu dijawab sebelum portal masuk pilot.
Jawaban akhir harus mengikuti build, controller, metode login, provider, data field, serta scope implementasi yang dipilih.
Apa perbedaan captive portal dengan Guest Wi-Fi Management?
Captive portal adalah touchpoint login yang dilihat tamu. Guest Wi-Fi Management mencakup journey yang lebih luas: portal, autentikasi, access handoff, operasional, support, dan reporting sesuai capability yang tersedia.
Apakah tampilan portal dapat mengikuti branding venue?
Branding dapat dibahas pada elemen yang memang didukung oleh build dan proses implementasi, seperti logo, warna, background, pesan, atau layout tertentu. Daftar opsi final harus diperlihatkan dalam demo atau portal builder yang telah divalidasi.
Metode autentikasi apa yang dapat digunakan?
Materi Nimbus mendokumentasikan self-registration, guest token, social login, serta messaging melalui SMS, email, atau WhatsApp API. Ketersediaan aktual, provider, prerequisite, consent, fallback, dan compatibility harus dikonfirmasi untuk environment yang digunakan.
Apakah captive portal kompatibel dengan semua Wi-Fi controller?
Tidak boleh diasumsikan. Controller, model, firmware/version, redirect method, callback, DNS, certificate, session, dan test procedure perlu diperiksa sebelum pilot atau rollout.
Data apa yang sebaiknya diminta dari tamu?
Minta hanya data yang diperlukan oleh flow dan tujuan operasional yang jelas. Required/optional state, purpose, consent, privacy notice, retention, akses internal, dan proses penghapusan memerlukan review organisasi.
Apakah portal dapat memiliki beberapa bahasa?
Kemungkinan penggunaan bahasa perlu dikonfirmasi pada build yang dipakai, termasuk daftar bahasa, fallback, pengelolaan copy, error state, dan konsistensi terms atau privacy notice.
Apa yang diuji dalam pilot captive portal?
Pilot sebaiknya memeriksa connect dan redirect, screen state, field, consent, setiap metode login, provider delivery, invalid input, timeout, success handoff, expiry, reconnect, perangkat/browser target, serta alur bantuan staf.
Bagaimana memulai evaluasi?
Siapkan controller/model/version, SSID dan network flow, target venue, jenis tamu, metode login yang dipertimbangkan, field yang dibutuhkan, branding asset, terms/privacy requirement, serta skenario pilot. Tim Nimbus dapat menggunakan informasi tersebut untuk discovery dan technical assessment.
Next evaluation step
Lihat bagaimana captive portal bekerja pada journey dan environment Anda.
Demo yang baik tidak berhenti pada screen login. Evaluasi redirect, metode autentikasi, consent, error state, controller handoff, serta pengalaman tamu dari awal hingga akses diberikan.
Controller & versionVenue & guest typeLogin methodBrand assetData & consentPilot scenario