Find the first failed step before changing settings. A connected WiFi icon does not prove that internet access has been authorized.
Capture the symptom without collecting secrets
Start with the location, approximate time, device type and what the guest sees. Can the device find the hotel network? Does a login screen appear? Is the credential rejected, or does the page accept it without usable internet? These are different faults and should follow different paths.
Never ask a guest to disclose unrelated passwords, read private messages or hand over personal accounts. If a screenshot is needed, exclude credentials and personal content. Give the guest a clear support route while the technical team investigates.
Check whether the problem is local or widespread
Compare another approved test device in the same location, then test a known-working area. A fault affecting one room may point to a radio, cabling or access-point issue. A fault affecting the whole property may involve the gateway, authentication path or internet circuit. Those are starting hypotheses, not a diagnosis by themselves.
Reception can record the pattern without changing network configuration. IT should review access-point status, addressing and the relevant gateway path. Avoid rebooting an entire property as the first response to one guest report.
Handle a missing login page carefully
Confirm that the device joined the intended guest network. On supported Apple devices, the network settings provide a Join Network path for captive access; follow the current device instructions rather than guessing at a browser address. Detection behaviour varies across operating systems and device settings.
If a certificate warning appears, stop and escalate. Do not advise guests to bypass certificate validation or install an unknown profile. IT should check the portal hostname, certificate, name resolution and access to the resources required before login.
Trace credentials, policy and the session
For rejected vouchers, inspect the assigned plan, credential status and configured validity. For PMS login, check the supported stay lookup. For OTP, review the provider result and entered number without exposing the code. If login succeeds, verify that the session reaches the enforcing network component.
Authentication and session accounting provide different evidence. A successful authentication event should be considered alongside the actual session and observed traffic path. In AirSpot's operational workspace, available active-user, reporting and troubleshooting views can help operators gather context; availability depends on the deployment.
Escalate with a useful evidence packet
Record the affected area, times, number of reports, test-device result and the last known-working step. Share technical identifiers only through the agreed support channel and under your access policy. The escalation should identify who owns the next action: hotel IT, network supplier, PMS provider, SMS provider or ISP.
After a fix, retest the original guest journey and a representative second device. Close the incident with the cause, action and verification, not just a note that the equipment was restarted. Repeated faults deserve a trend review.
Your next-step checklist
- Location, device and time
- First failed step in the journey
- Single guest or wider impact
- Relevant session and provider evidence
- Named owner and retest result