Asking a customer to install an app to earn a stamp is asking them to do, standing at your till, something they would not do sitting at home. The full chain runs: open the app store, find the right one, download several tens of megabytes, open it, create an account, choose a password, confirm an address. There is a queue behind them.
The Kanz loyalty card is added to Apple Wallet or Google Wallet. There is nothing to install, nothing to create, no password. The customer scans a code, gives their number, and the card is on their phone.
A pass holds no permissions, by construction
This is the argument most people do not know, and it is the sturdiest one.
An installed app can ask for access to your location, your contacts, your photos,
notifications, the camera. It can ask later, after the update nobody reads. A wallet pass
cannot: it is not an app, it is a data object in the standard format of the two systems, a
storeCard at Apple and a
loyalty card at Google. It has
no code to run, so it has nothing to ask for.
So this is not a promise made by Kanz, it is a property of the format. The difference between the two counts: a promise holds as long as nobody changes their mind, a property of the format holds because there is no way of doing it otherwise.
What the customer gives, and what is never asked for
A phone number. That is the only required field.
First name, email address and birthday are optional, and the birthday stops at the day and month. The year of birth is never asked for and never stored, because it is no use for wishing somebody a happy birthday and it is one of the most sensitive things anyone can collect without noticing.
A sign-up page that fits in one field gets filled in at the counter. A page asking for six gets filled in at home, which is to say never.
Why the scan is quick
The code printed on the card is signed. It carries the identifier of the business, the identifier of the customer, and a signature only your server can produce:
KANZ1.<your business>.<the customer>.<signature>
The benefit is very concrete at the counter. The scanner can check the code is genuine without querying a database to do it, so the operation does not hang on the connection quality of the phone doing the scanning. The target the product holds itself to is under two seconds between the code and the stamp, and a queue must never wait on something loading.
A signed code has a second virtue: it does not copy usefully. A screenshot of another customer's code does not turn into a stamp, because the signature names one specific person at one specific business.
And phones with no wallet
Some are still about, and they must not run into a closed door.
Those customers get a plain link that opens in their browser. Their card lives there, their stamps are counted there, and they can keep it as a bookmark or on their home screen. It is less convenient than a card in the wallet, and it is infinitely better than "your phone is not supported" while the person behind them adds theirs in two seconds.
What still needs a device, on your side of the counter
It is worth being honest about the asymmetry: it is the customer who has nothing to install, not you.
On your side you need a device that reads a code, which is to say a phone. The scanning tool opens in the browser and is added to the home screen, so there is no app to download there either, but you do need a charged phone at the counter and somebody who knows how to use it. That is the real entry price, and it is better to know it beforehand than on the day the queue starts building.
The simple test
Count the gestures between "go on then" and "done". Three, with Kanz: scan, type a number, add the card. Every extra gesture costs you a slice of the sign-ups, and that slice is not spread at random: the customers in the biggest hurry are the ones who give up, and the customers in the biggest hurry are often the most regular.
How the whole thing works, from the first scan to the reward, is described here.