Guest Wi-Fi is a separately entitled preview, implemented for the web. Its source and configuration screens do not establish a live venue replacement. UniFi supplies and enforces internet access; Soupy hosts registration, verifies contact details and supplies permission-controlled reports. The operator selects the exact Legal Entity and Site for each network. A Group never implicitly shares a guest identity or marketing permission between businesses.
Screens and setup
The workspace at /app/[orgSlug]/guest-wifi has Overview, Connections and
Reports. Settings at /app/[orgSlug]/guest-wifi/settings manages controller
connections, credentials, Site/network mapping, portal text and notices, access
duration, pending-evidence retention and pilot readiness. Credential entry is
write-only. Saving credentials or passing a read-only controller check does not
prove that a phone can connect.
The Guest Wi-Fi product page, product directory card and first-controller empty state use the approved After Roam from the Hullo and Roam Illustrator pair, with worn shoes and a winking expression. All use one shared artwork reference; the earlier trainer-clad study remains a historical design source. The artwork is static and transparent in both themes. Native apps have no new placement, and venue branding continues to lead the guest portal.
New built-in read-only profiles include View Guest Wi-Fi for the Overview and Connections screens. This permission grants no reports, exports or settings access; those capabilities remain separate. New business administrator profile revisions include the same view permission alongside their existing configuration access. Existing frozen assignments are unchanged and need an explicit access change when they lack the module or capability. Entitlement and current Site scope still apply; Group administrator profiles do not add Guest Wi-Fi authority. A module appearing in an access summary does not mean full access.
An administrator records the actual controller Site ID, network ID and SSID. The supported transport uses UniFi's official cloud connector or a separately approved direct HTTPS controller endpoint. Unsupported controller evidence blocks authorisation. A pilot network requires a recent successful connection check, confirmed controller inventory, a prepared staff emergency network and a documented rollback. Keep the existing provider available during the pilot.
The following references show actual shared components with fictional data. The approved Roam captures use the local Development Environment on 16 October 2026; the report capture uses the isolated synthetic browser harness from 15 October. They establish component appearance only, not authenticated tenant, controller or physical-device acceptance.
| Synthetic reference | What the capture shows |
|---|---|
| Approved Roam, desktop light · dark | Historical Connections reference (16 October): shows the former character treatment and setup instructions. The prepared 28 October icon-only empty-state change supersedes that artwork placement. |
| Approved Roam, mobile light · dark | Historical Connect your first Site reference (16 October): the former artwork and instructions at a 390px viewport; current prepared empty-state composition uses one Wi-Fi icon. |
| Product page, desktop · mobile | Welcome guests online: approved After Roam introduces the product; the Preview notice continues to govern availability. |
| Directory card, desktop · mobile | Guest Wi-Fi: the ordinary product link uses the same approved export. |
| Reports and source timezone | The fictional Demo House daily report: 124 authorisations, 86 verified guests, 52 consent requests, 31 new marketable contacts and a 52/124 request rate (41.9%). The scrollable table retains its Europe/London source timezone. |
Guest registration and contact verification
The public portal at /guest-wifi/[networkKey] uses a short-lived network session,
without a staff or Clerk account. Guests supply an email address; name and age
band are optional. Email marketing is a separate, initially unchecked choice.
Declining marketing still permits access. Terms and privacy notices identify the
venue's responsible business.
The controller client, mapped network and access point are checked before authorisation. The portal distinguishes pending, authorised and failed states; controller authorisation alone does not establish usable internet connectivity. Repeated submissions reuse the existing operation. Simultaneous captive windows for one network client share an authorisation lease, and an unchanged controller grant counts once even if another session completes its consent choice. Returning access retains the controller's actual expiry. The guest can request an email verification code after authorisation. An expired, undelivered or abandoned code does not revoke internet access.
Unverified submissions remain pending portal evidence. They do not reveal an existing customer, update a profile or grant marketing permission. Successful proof resolves the existing business-owned customer; ambiguous matches need review. A selected marketing choice is promoted through the canonical consent service only after proof and current eligibility checks. A later withdrawal wins over an earlier pending choice. An unchecked box grants nothing new and does not withdraw a previous permission. Existing preference management remains the route for withdrawal.
Reports and migration evidence
Reports distinguish confirmed authorisations, distinct verified guests, marketing requests and newly marketable contacts. The request rate divides marketing selections by successfully authorised sessions shown the choice. It is not the legacy provider's new-user opt-in rate. Existing marketable CRM contacts are not counted as new acquisitions. Late verification belongs to its verification/consent date, attributed to the originating Site in the session's frozen timezone. Daily, monthly and Site views retain their actual grouping timezones even after later configuration changes. A connection is not a verified visit, ticket attendance, purchase or loyalty event.
CSV and PDF exports show the selected period, timezone and definitions. Access to reports and exports is separate from configuration access. Oversized reporting periods are refused explicitly instead of presenting partial totals.
Historical migration stages customer/consent exports with source provenance, recorded wording and suppression evidence for review. Reviewing staged evidence does not import it into CRM or send communications; CRM retains its reviewed import and consent boundaries. Aggregate report PDFs cannot supply individual identities or permission evidence. Pending portal evidence and staged import data have bounded retention; canonical customer and consent records retain their existing lifecycle. A reviewed account-deletion request includes a separate Wi-Fi erasure step for raw sessions, staged contacts and identifiable proof links. Historical verified-guest counts are anonymised; the do-not-contact suppression remains effective. Completing this step alone does not complete account deletion.
Availability and acceptance
Physical iOS/Android captive-browser, internet-access, reconnect, outage and rollback checks are required before a venue cutover. Staff operate the prepared emergency guest network when the portal is unavailable. Existing authorised sessions continue under the controller's own limits. The initial implementation does not provide native-mobile operator screens, cross-business single sign-on, automatic fallback, campaign journeys or revenue attribution.