Why Your Loyalty Program Only Lives In-Store (And How to Fix It)

The CMO tells you, convinced: they have a loyalty program and it works. Points, a card, tier-based discounts, the usual. Everything in order, apparently. Then you ask something very simple: can that customer who earns points in-store see their balance in the app?

There is usually no answer.

It is not that the program is broken, exactly. It is that it only works in one of the places where the customer shops, and these days almost nobody sticks to a single sales channel. A card that lives in-store but does not exist on the website, or the other way around, which also happens, is probably the most common mistake in mid-sized retail. And the hardest one to catch in time, because it does not show up in any report until someone decides to actually look, without rushing, at what is going on.

This is the first case in the Loyalty Autopsy series: the diagnosis, the real cause, and the prescription for why your program lives split in two without anyone ever deciding it that way on purpose. Because, at the end of the day, nobody designs a program to work only half the time.

 

 

The diagnosis: a program the customer cannot touch

Picture a regular customer of a fashion chain. Two years earning points in-store. Physical card, member number, the vague but real feeling that they have something saved up there.

They shop on the website one random Sunday, reach checkout, and there is no trace of the balance. They open the app, and there is nothing there either. They call customer service, and the agent cannot really help, because that data lives only in the physical store’s cash register.

That customer effectively has two loyalty programs from the same retailer that do not talk to each other. One for the store, and another, considerably poorer, for everything else. And that “everything else” is, year after year, where they spend the most.

 

This is not new, really. It has a well-known precedent: the classic loyalty card, the stamp-and-discount-at-checkout kind, never captured all of a customer’s activity.

 

Today’s points program inherits that same limit, with one twist: now the invisible channel is not “what never got recorded,” but “what got recorded in the wrong place.” The customer does earn points, just not where they later want to use them.

And here is the curious part: the symptom does not show up on any sales dashboard. Revenue keeps flowing, the program looks alive, no alarm goes off. The problem only becomes visible once someone sits down to measure real participation: how many enrolled customers redeemed something in the last twelve months, how many bought through more than one channel. That is when the numbers suddenly stop adding up.

And the strangest part, this really is surprising once you stop to think about it, is that nobody is lying in the process. The store sees the program working because, in that channel, it is. Ecommerce does not even count it in its metrics because, from where they sit, that program simply does not exist: it does not show up at their checkout, it does not factor into their conversion numbers.

Each team is right about the data it manages, and that is exactly the trap. The problem does not live in any single report; it lives in the gap between reports.

 

Why it happens: loyalty as a system bolted onto checkout

The cause is rarely negligence; it is architecture, and an old one.

The loyalty program was born, in most retailers, as a module of the cash register system: an add-on to the POS terminal to add up points when someone paid in-store. At the time, it made complete sense, because almost the entire business ran through there. The problem is the business changed, and the program stayed still. Ecommerce arrived, then the app, then WhatsApp as a channel for both buying and support, and the loyalty module kept living exactly where it was born: on the POS.

It is a design flaw, not a lack of intent, and this is worth stating clearly, because it usually gets read the wrong way around. Nobody woke up one day and decided “let’s only reward in-store customers.” Simply put, the system that manages the benefit was never built to talk to the online checkout, and connecting that afterward, on top of a system that was not built for it, turns out expensive, slow, and, often, never quite gets done properly.

And this is where many retailers get stuck for years: the “obvious” solution, manually integrating the current points system with ecommerce, usually means touching the POS, the ERP, and the online store’s pricing engine. It is not that nobody wants to fix it. It is that doing it this way turns into a project competing for budget and IT time against other, more urgent priorities. And in the meantime, the patch never arrives.

The real paradigm shift goes another way: the benefit is not calculated or applied in an isolated module, but by checking the customer’s data in real time, right at the moment of payment, whatever channel that payment happens on. When loyalty lives in the transactional gateway at checkout, and not in some corner of the cash register system, it stops mattering whether the customer pays in-store, on the web, or from their phone: the engine checks the same data. It applies the same benefit in any of the three places.

 

The silent cost of a fragmented program

The most expensive part of this mistake is not technical, it is about trust, and this is more serious than it sounds.

A customer who cannot check their balance, or who finds out that what they earned in-store is worthless online, quickly learns an uncomfortable lesson: this program cannot be relied on, so better not to count on it. They stop checking their balance, stop expecting the benefit, and the business loses exactly what a loyalty program is supposed to generate: a reason to come back.

On top of that, that customer ends up calling customer service to ask something they should be able to solve on their own. “How many points do I have?” should not require an agent on the other end of the phone. And every time it does, there is an operating cost nobody budgeted for the loyalty program.

And then there is the data, which is, perhaps, the least visible damage of all. If the points system lives separate from the rest of the operation, customer behavior also ends up split across two records that do not talk to each other. The marketing team cannot tell whether the same customer who shops in-store also shops online, because the system, literally, does not know.

And this hits exactly where it hurts the CMO most: CLTV and margin. If you cannot see the whole customer, you cannot know how much they are really worth, or how much retention effort they deserve. A customer who buys through both channels can look, in split reports, like two average customers instead of one very good one, and the loyalty investment decisions made with that half picture tend to go wrong almost by definition, no matter how well thought out the strategy looks on paper.

 

The prescription: real omnichannel loyalty

The solution is not “trying harder” with the current program. It is changing where the customer’s data lives.

A unified customer wallet solves this at the root: a single digital space holding the customer’s balance, history, and benefits, accessible from different environments, built into the retailer’s own app, into a white-label app, via Apple Wallet or Google Wallet with Mobile Pass, or directly from the browser, but always showing the same content, the same experience, updated in real time.

In practice, that means points earned in-store can be redeemed on the ecommerce site and vice versa, with no delays or manual syncing involved, with the same balance visible at any touchpoint the customer feels like checking. The person who used to call to ask about their balance stops having that problem: they can check it themselves, instantly, from wherever suits them best.

Take a concrete case: a customer shops in-store on a Saturday and earns points. On Sunday, from the couch, they go to the same retailer’s website and see that balance updated in their account, not a version from a few days ago, the real one. They redeem some of those points on an online purchase. The system deducts them from that same single balance, not from a separate copy. If that person walks back into the physical store the following week, the balance the cashier sees at checkout is, again, the same. There is no “store version” and “web version” of the customer. There is one customer, with one balance, visible from anywhere.

And that continuity is exactly what a customer understands “being enrolled in a loyalty program” to mean. It is not asking for much. It is simply the bare minimum expected of something that carries that name.

You do not even need to touch the e-commerce ERP or pricing engine to make this happen: the benefit is calculated and applied at checkout, via gateway, checking the existing data at the moment of payment. Marketing gains autonomy over the program without depending on a long integration project, and the IT team does not have to open a new development ticket every time a program rule changes.

And this does not require the year-long project many teams fear. Enterprise-grade CDP-plus-loyalty projects typically move in 8-to-18-month cycles. An integration built on a single checkout API, on the other hand, moves in weeks: most cases go live in 4 to 12 weeks, depending on the retailer’s point-of-sale integrator. It is not another marketing promise. It is the difference between rewriting the cash register system from scratch and connecting a gateway on top of it.

How to tell if your program would survive this autopsy

Before assuming this does not apply to you, it is worth asking five specific questions. None of them require deep technical analysis, they are answered by looking at the customer’s real experience, not the current vendor’s product sheet.

• Does a customer see the same points balance in-store, in the app, and on the website, with no differences?

• Can what is earned at the register be redeemed online, and what is earned online be redeemed at the register?

• Can customer service check any customer’s balance without depending on which channel they used to buy?

• Can marketing launch a new benefit without opening an IT ticket to touch the register system?

• Do you know, with real data, what percentage of your enrolled customers has redeemed anything in the last twelve months?

If any of these questions leaves you thinking instead of answering yes right away, your program has, at the very least, a version of this same problem.

And there is nothing wrong with admitting it: it is by far the most common of the four mistakes we will cover in this series, which, looked at another way, is actually good news. It means the solution is already proven. There is nothing to invent from scratch.

 

Loyalty the customer cannot touch does not build loyalty.

This is the first case in the Loyalty Autopsy, the series in which Wapping reviews, case by case and without naming brands, the most common and most silent mistakes in retail loyalty programs. Next up: what happens when a discount goes out to the entire customer base equally, without distinguishing who actually needed it from who did not.