In brief
7- and 30-day remembered-device windows, returning-guest assumptions and a worked credit calculation, including the MAC randomisation caveat.
Every SMS code spends a credit. In a business with regulars, a phone that asks for a code three times a week burns through credits fast. Device remembering reduces that: a verified device does not see the portal again for the period you set. This post explains how the window works, how to calculate the saving, and where it can break. All figures are assumptions; replace them with your own.
What device remembering does
When a guest verifies with an SMS code, the box pairs the device's MAC address with the verified session. If the same MAC returns within the remembering period, the portal does not appear; the session opens directly. The record side does not change: every new session is written with MAC, assigned internal IP, session start and end, and linked to the phone number from the first verification. Daily records are chained with SHA-256 digests and time-stamped.
The window is set per plan. In our lab templates the staff plan uses 30 days and the lodging plan 7 days. For a café, 7 days is a sensible start.
The logic of the calculation
Your monthly SMS need depends on three things:
Monthly SMS = daily verifications × days × (1 − remembered share)
The remembered share is the portion of a day's logins that come from devices returning within the window. You have to assume this before you can measure it. The login funnel report in the panel shows the real value after a few weeks.
Example: neighbourhood café
Assumptions (not measurements):
- 100 verifications a day with remembering off
- Open 30 days
- 40% of daily logins are from guests who visited in the last 7 days
- 55% from guests who visited in the last 30 days
- 1 credit per SMS
| Scenario | Monthly SMS | Months per 2,000 pack | Months per 10,000 pack |
|---|---|---|---|
| Remembering off | 100 × 30 = 3,000 | 0.7 | 3.3 |
| 7-day window | 3,000 × 0.60 = 1,800 | 1.1 | 5.6 |
| 30-day window | 3,000 × 0.45 = 1,350 | 1.5 | 7.4 |
Under these assumptions a 7-day window cuts 40% of SMS and a 30-day window 55%. The difference looks modest at first, but over a year 7 days saves roughly 14,000 credits and 30 days roughly 20,000.
Where the returning share is low (a tourist area, a transit point) the gain shrinks: with 10% returns a 7-day window saves only 300 SMS a month. Do not decide without knowing the share; treat the first month as a measurement month.
Example: hotel
The logic differs in a hotel. Guests stay 2 to 3 nights; without remembering they would be asked for a code every time a 24-hour session expired. With a 7-day window one code covers the whole stay.
Assumptions: 120 rooms, 80% occupancy, 1.8 people per room, 85% connect, 2.5 nights on average, 1.5 devices per person, each device gets its own code.
- Guest devices logging in per month: (120 × 0.8 × 1.8 × 0.85 × 1.5) × (30 / 2.5) ≈ 220 × 12 ≈ 2,640 devices
- Remembering off, 24-hour sessions: 2,640 × 2.5 ≈ 6,600 SMS
- 7-day window: 2,640 SMS (one per device)
Remembering cuts a hotel's SMS by about 60% and improves the guest experience. Hotels that use coupons already avoid part of this SMS volume.
Which window for which venue
| Venue | Suggested window | Reason |
|---|---|---|
| Café, restaurant | 7 days | Weekly regulars |
| Hairdresser, gym | 30 days | Regular but infrequent visits |
| Hotel, serviced apartment | 7 days (close to stay length) | One code per stay |
| Dormitory | Whole term (long window) | The same people every day |
| Office visitors, staff | 30 days | Repeat visitors |
| Event, trade fair | Event duration | Pointless afterwards |
| Shop, mall footfall | 7 days or off | Low return rate |
The cost of a longer window: while a device stays known there is no fresh verification. Records are still kept for every session, but the verification detail rests on the date of the first code. That is a balance your business must be comfortable with; if unsure, start with a short window.
MAC randomisation: what upsets the sums
Modern phones join Wi-Fi networks with a random address instead of their real MAC. Most phones keep the same random address for the same network, and remembering works. But some settings refresh the address from time to time or change it on every connection. That device looks new to the box and is asked for a code again.
Consequences:
- The savings above are upper bounds. The real saving depends on how many guests keep their address stable. Leave a 10 to 20% margin in your calculation.
- No problem for the guest: a new code arrives and they connect. No problem for the records either: the new MAC is recorded with a new session.
- You can add a line to your portal text: "If you are asked for a code on every visit, turn off the random address for this network in your phone's Wi-Fi settings." Not mandatory; guests who wish to can do it.
Gains beyond credits
SMS credits are not the only gain. With remembering on:
- Guests connect directly on their second visit; the "a code again?" complaint goes away.
- The portal carries less load and staff field fewer questions.
- The login funnel report shows your returning-guest share, which is business data in its own right.
How to start
- Set remembering to 7 days for the first month and watch daily SMS counts and the login funnel in the panel.
- Read your returning share. Above 30%, consider moving to 30 days.
- Keep the SMS credit alarm (<100) on so a pack running out does not catch you unprepared.
- If you use your own SMS provider account, the same arithmetic applies; put in your own unit price.
SMS credit packs (1,000 / 2,000 / 10,000) and the own-provider option are on the products page. To run the numbers with your own figures, write to us; during the 7-day trial the panel report gives your real return rate.