A Voucher Code Isn't Just a Password
Handing out a WiFi password once and using it for a year is what most properties do by default. A voucher is what you use instead, when you actually want the access to end.
Most properties that don’t use OTP for guest login fall back to the same thing: one shared WiFi password, printed on a table or told to guests at check-in, that stays the same for months or years. It works to get people online, but it doesn’t do anything else: it doesn’t expire on its own, it doesn’t tell you who’s using it, and changing it means changing it for everyone at once, guests and staff included.
A voucher code works completely differently. It’s a single code, created as part of a batch, that works for a set amount of time, a number of minutes, hours, or days you choose when you create the batch, and then simply stops working. The real difference isn’t the code itself, it’s that someone decided, in advance, exactly how long this access should last.
What a batch of vouchers actually controls
Creating a batch of vouchers means setting a few things up front: how many codes, how long each one works for, and which location they belong to if you run more than one. Every code in that batch follows the same rules. A batch of 50 vouchers good for 2 hours, made for a conference room booking, behaves completely differently from a batch of 10 vouchers good for 30 days, made for a co-working space’s monthly members. Same basic idea, completely different rules, chosen each time you create a batch rather than fixed once and for all.
This is the part a shared password simply can’t do. A password is one setting for everyone. A voucher batch is a setting you choose each time, which means a property running different kinds of guest access (day passes, event access, temporary staff access) can run all of them at once, each with its own real end date, instead of forcing every use through the same one password.
Where vouchers fit next to OTP and password login
Voucher access isn’t a replacement for phone-based OTP login or a saved password; it’s a third option that solves a problem neither of those handle well. OTP login is great when you want to know who connected and don’t mind a guest needing a working phone number. Password login is great for a returning guest who doesn’t want to log in again every visit. Neither fits 100 people at a one-day event who don’t need any kind of ongoing relationship with your WiFi. That’s exactly what a voucher batch is for: access that’s genuinely meant to be temporary, handed out in bulk, without turning every attendee into a saved contact.
Guests simply pick whichever way a property has turned on: a location running vouchers alongside OTP and password login just shows a voucher-code option next to the others, and it doesn’t require the property to set anything else up in any particular way.
The part that’s easy to get wrong
The most common mistake with vouchers isn’t technical. It’s just not thinking carefully about how long each batch should last. A batch created without much thought about the time limit ends up exactly as loose as a shared password: a voucher good for 90 days, handed out at a single event, isn’t really any different from a password that never changes. It’s just a different set of letters and numbers. Vouchers are only actually useful when the time limit matches the real situation: a day pass that expires the same day, an event code that expires when the event ends.
Where this lives
Creating vouchers lives in its own section of the dashboard, separate from the guest list. Every batch you’ve created, how many codes are left, and when they expire are all visible in one place, so “how many of these 50 codes have actually been used” is a real answer you can check, not something you’d have to guess at the way you would with a password nobody’s tracking.
The honest case for vouchers isn’t that they’re more secure than a password in some abstract sense: a leaked voucher code works just as well as a leaked password until it expires. It’s that they come with a real, chosen end date attached, which a shared password handed out at check-in almost never has.
