A loyalty app sitting on a separate phone or tablet by the till feels modern. It is usually a step backwards, because of one limitation that undermines the whole point: it can only reward what it can see, and what it can see is rarely the bill.
This is a short argument for a specific design decision, and it is the most important one in loyalty. The full guide is restaurant loyalty that works; this is the part about where loyalty should physically live.
The standalone app only sees a fragment
Picture how a typical loyalty app works during service. The guest checks in, or a code is scanned, and the app records that someone was here. From that it awards a stamp, a point, a reward. What it does not see is the bill. It does not know whether this guest spent six pounds on a coffee or two hundred on dinner for eight, because the bill lives in the till and the app lives on its own.
So the app does the only thing it can: it rewards the visit, equally, regardless of value. The big spender and the quick-coffee guest earn the same. That is not loyalty rewarding your best guests, it is loyalty rewarding footfall, and footfall is a poor proxy for value.
There is a second cost. Because the app is separate, someone has to operate it during service, a scan, a tap, a "are you a member?" at exactly the moment your team is busiest. It adds friction to the one part of the night where friction hurts most, and friction is why so many loyalty schemes quietly stop being used. The card does not get stamped. The member does not get scanned. The scheme dies of inconvenience.
Loyalty in the till sees the whole bill
Now picture loyalty built into the till itself. The bill is right there, because the till is where the bill is. So the scheme can reward the actual spend, automatically, as part of taking the payment. The guest who spent two hundred earns accordingly, the quick-coffee guest earns accordingly, and the difference between them, the thing that matters, is reflected without anyone deciding it on the spot.
Nobody scans anything. The reward, if there is one to redeem, appears on the same screen that takes the payment, applied in the normal flow. There is no separate device, no extra step, no "are you a member?" because the guest is already recognised on the record the till is feeding. The friction that kills schemes is simply gone, because there is no separate thing to operate.
This is also why points should be earned on spend rather than on visits. Spend is the truest measure of what a guest is worth to you, and only the till knows it. A scheme that cannot see the bill is reduced to rewarding the thing it can see, which is the wrong thing.
And it feeds everything else
There is a knock-on benefit that matters as much as the loyalty itself. When loyalty lives in the till and on the guest record, what a guest earns and how they behave is not stranded in a separate app. It joins everything else you know about them: their bookings, their preferences, their visit history. Their loyalty tier reflects real spend, and that tier is visible to the team and useful to your marketing, because it is part of one record rather than a number in a silo.
A standalone app, by contrast, holds its data apart. You end up with loyalty over here and the guest record over there, and the two never quite meet, which is the same fragmentation problem that afflicts every disconnected hospitality system.
Where Grace fits
In Grace, loyalty lives in the same platform as the EPOS, so it sees the whole bill and rewards real spend without anyone scanning a thing. Points are earned on bookings and spend, rewards redeem at the till as part of the normal payment, every guest is classified by behaviour automatically, and all of it feeds the one guest record. You can see how the till works on the EPOS page, and the wider loyalty thinking in the loyalty guide.
The reason it is built this way is simple. A loyalty scheme that asks your team to operate a separate device during a Friday service does not survive that service. If a feature cannot survive a Friday night, it does not ship, and that includes loyalty.
FAQ
Why is a standalone loyalty app a problem?
Because it can only reward what it sees, which is usually a check-in or a scan, not the actual bill. That means it rewards visits rather than value, makes your team do extra work during service, and keeps the data in a silo away from the rest of what you know about the guest. - q: "What does loyalty in the till do differently?" a: >- It rewards real spend automatically, because the till knows the whole bill. Points reflect what someone actually spent, rewards redeem at the point of payment, and nobody has to scan anything. The loyalty also feeds the same guest record as everything else. - q: "Does loyalty in the till slow down service?" a: >- It should speed it up compared with a separate app, because there is nothing extra to scan or open. The reward is applied on the same screen that takes the payment, as part of the normal flow.