In brief
Tie your QR menu and guest Wi-Fi into one flow. Keep the menu reachable before login, redirect to it after the code is verified, and size sessions to table turnover.
A guest sits down and does two things: takes out a phone, scans the code on the table. If the menu does not open, the first question follows: "What's the Wi-Fi password?" The waiter recites it, the guest types it, and now the portal opens while the menu is pushed aside. Two separate steps, two separate waits. This post shows how to collapse them into one flow.
Where the problem starts
A QR menu is a web page. It needs internet to load. If the guest's mobile data is weak, or the guest is from abroad, the menu does not load. Even when the guest joins your Wi-Fi, the captive portal (the login page) shows itself first and the menu falls behind.
What you actually want: the guest connects, sees the menu right away, thinks about the order, and gets internet the moment the code is entered. Two settings on the box are enough.
1. Put the menu in the walled garden
The walled garden is the list of addresses reachable before login. Even without entering a code, the guest can reach anything on this list. Add your menu's domain and the guest connects, scans the code, and the menu opens. Verification comes later, when the guest wants the wider internet.
Things to watch:
- If the menu loads images from a separate domain (a CDN), add that domain too. Otherwise the text appears and the photos stay blank.
- If your menu provider changes domains, update the list. Test once and write it down.
- If ordering or payment goes to a third address, that is your call: leave it open as well, or keep it behind verification.
Result: nobody needs an SMS code just to read the menu. Nobody asks for a "password".
2. Point the post-login redirect at the menu
The box has a post-login redirect address. Once the guest verifies the code, the browser goes there. Put your menu here. The flow becomes:
| Step | What the guest sees | What the box does |
|---|---|---|
| Joins Wi-Fi | Portal page | Opens an unverified session |
| Scans the code | Menu (thanks to the walled garden) | Allows only the menu address |
| Wants internet | Phone number + SMS code | Verifies the code, writes the record |
| Code is correct | Menu opens again | Opens internet, redirects to the menu |
The guest sees the menu twice but does not mind; the second time feels like returning to where they wanted to be. You could redirect to a promotion page instead, but for a café the menu is usually the right choice.
Table turnover and session length
Session length sets how long one verification lasts. Idle timeout says how long after traffic stops the session closes. Both are defined per plan on the box and do not depend on your access point brand.
Our lab suggestion for cafés is the standard template: 10/5 Mbps, 2-hour session, 15-minute idle timeout, 2 devices, 1 GB per day. Treat these as a starting point and tune them to your own turnover.
- A fast-turnover coffee spot where guests stay 40 minutes on average does fine with a 1-hour session. A departing guest's device drops within 15 minutes and stops counting against your concurrent users.
- In a study café, guests stay 3 to 4 hours. Raise the session to 4 hours; otherwise the guest asks for another code and you spend another SMS credit.
- Do not make the idle timeout too short. A guest who pockets the phone and checks again 10 minutes later should not find the session gone.
If you have many regulars, turn on device remembering. The same phone returning within the window you set is not asked for a code again. Random MAC settings on phones sometimes break this; the guest simply gets a new code and nothing else goes wrong.
Designing the table card
One card, two QR codes:
- Wi-Fi code: carries the network name; scanning it joins the network directly. Leave the guest network without a passphrase; verification happens in the portal.
- Menu code: the menu's address.
Add one line underneath: "Join the Wi-Fi first, then scan the menu." Your staff never has to recite a password again.
The record side does not change
Even with the menu in the walled garden, internet access opens only after verification. The box stores the verified phone number in encrypted form, the device MAC, the assigned internal IP and the session start and end. It does not store visited sites, what was chosen on the menu or any message content. Daily records are chained with SHA-256 digests and time-stamped. Nothing in this flow weakens the record-keeping that Law 5651 expects from a public-access provider.
Checklist
- Menu domain and any image/CDN domain in the walled garden
- Post-login redirect set to the menu
- Session length slightly above your average seating time
- Idle timeout 10 to 15 minutes
- Device remembering on or off depending on your share of regulars
- Wi-Fi QR and menu QR together on the table card
To see this in your own café, look at the box page or write to us; during the 7-day trial we set this flow up with you. Sector-specific notes are on the industries page.
This article is for general information and is not legal advice.