Blog
Product Updates
Tesco and Magneds: Inside a Global Loyalty Award Win
Flip Kloet
Tesco's loyalty programme, run on NeoDay's platform with Magneds, won Best Loyalty Program 2025 at the International Loyalty Awards. If you run loyalty, CRM or digital for a retail or consumer brand with 50 or more locations, that result matters less as a trophy and more as proof: a programme built on an API-centric platform, launched in weeks rather than years, can still beat global competitors on judged criteria like member growth, engagement and commercial impact.
This piece looks at what the judges actually rewarded, what Tesco and Magneds did differently, and what a brand your size would need to copy it. If you want the detail behind the headline, the case study walks through the mechanics; if you'd rather talk it through, book a short demo and we'll map it to your own store footprint.
What did Tesco and Magneds actually win
Tesco and Magneds picked up the 2025 award together for a loyalty programme built on NeoDay's platform, with Magneds acting as NeoDay's implementation partner on the build. The International Loyalty Awards judge entries on member engagement, measurable business outcomes and innovation in programme design, not just scale. Tesco is one of the largest grocery chains in Europe, and that's exactly why the win mattered: the programme had to perform at that scale without years of custom development.
NeoDay is also a finalist for the 2026 International Loyalty Awards, which suggests the 2025 result was not a one-off.
Why a grocery chain the size of Tesco needed a new loyalty engine
Large grocery retailers usually have the opposite problem to a challenger brand: too much existing infrastructure, not too little. Loyalty data sits across point-of-sale systems, e-commerce, a data warehouse and sometimes a legacy CRM built a decade ago. Adding a new programme on top of that stack, without ripping anything out, is the actual engineering problem.
NeoDay's platform is cloud-agnostic and API-centric. That's what made the Tesco and Magneds build work on a realistic timeline.
Loyalty logic such as earning rules and redemption tiers runs independently from the retailer's existing data infrastructure, connected through defined interfaces rather than a full system migration. That's also the answer to a question IT leads ask us a lot when they look at a platform like this: how should real-time events and batch data split between a warehouse such as Snowflake and the loyalty engine itself?
In practice, transactional events that trigger an immediate reward, a stamp or a point redeemed at the till, need to run through the loyalty engine in real time. Everything used for segmentation and personalisation modelling can run on a batch or near-real-time feed from the warehouse instead. Separating those two paths early, rather than forcing one data pipe to do both jobs, is usually what keeps the Snowflake access model and event schema clean.
Get the schema wrong at this stage and every later campaign change turns into a change request instead of a config update.
What the Tesco and Magneds build changed in practice
With that backend and frontend split in place, the campaign layer could change week to week without ever touching the core points engine, and that's where the design choices below actually show up.
Gamified mechanics (collectible elements, tiered rewards, time-boxed campaigns) sat on top of the core points engine rather than replacing it, so the base loyalty logic stayed simple while the campaign layer carried the engagement work.
Personalisation ran through NeoDay's AI-driven engine rather than static segments, so reward relevance improved without the CRM team manually rebuilding rules every quarter.
The frontend was ready-to-use rather than custom-built from scratch, which is usually where a loyalty build loses its first three months.
That last point is worth dwelling on. A lot of retailers assume the frontend (the app screens, the wallet, the redemption flow) is the fast part and the backend is the slow part. In our experience it is usually the reverse: a ready-to-use frontend with configurable branding can launch in days once the backend logic is agreed, while backend decisions around data access and campaign rules take the real time.
What this means for your own timeline and budget
Whether a result like this is realistic for your brand comes down to what you're integrating against: your POS stack, your existing app, your legacy CRM, not the platform itself.
Factor | Typical range |
|---|---|
Standalone app or SDK inside existing app | SDK is usually faster: no new app store listing, no fresh user acquisition |
Launch timeline | As little as 10 weeks for a standard build; longer if POS integration is incomplete |
Setup cost structure | Varies by location count and whether reward fulfilment is in-house or outsourced, see [neoday.com/pricing](/neoday-loyalty/) for current ranges |
Annual cost per member | Scales down per member as the programme grows past the first few hundred thousand members |
One question we hear a lot from QSR and convenience retailers without full POS integration: how do you identify a customer for loyalty at the counter, when the till doesn't talk to the loyalty system at all? The usual workaround is a scannable code at checkout, a QR on the receipt or in the app, that the till doesn't need to understand. The loyalty engine reconciles the transaction afterwards. It's slower to build reporting granularity this way, but it avoids a POS integration project that can add months to a launch.
If you're the one deciding whether this is worth pursuing for your own chain, request a copy of the Tesco and Magneds case study and compare the numbers against your own store count and member base before you commit to a build.
Where a points programme like this fits against the alternatives
Not every retailer needs the same mechanic.
A fuel retailer with high visit frequency and low basket value needs different earning caps than a fashion retailer with low frequency and high basket value. For more on how this plays out across sectors, see our breakdown of loyalty programme examples across industries and, for grocery specifically, retail loyalty programme examples.
On earning caps and expiry tiers specifically: a common structure for stamp or chili-style campaigns sets a weekly earning cap per member (to stop bulk-buying abuse), a tiered expiry window (unredeemed stamps lapse faster than points, to keep the campaign feeling live), and a floor reward that's always reachable within a single campaign period. Retailers that skip the floor reward tend to see early drop-off once members realise the top tier is out of reach.
FAQ
How long does it actually take to launch a loyalty programme the size of Tesco's? Tesco and Magneds launched their programme on NeoDay's platform in a matter of weeks rather than years, because the loyalty logic ran separately from the existing data infrastructure. A standard build on NeoDay runs in as little as 10 weeks; a build with incomplete POS data or a custom frontend will run longer.
What does winning a global loyalty award actually prove to a CMO evaluating platforms? It proves the programme performed against judged criteria like member engagement and measurable business outcomes at a scale comparable to your own estate, not just that it looked good in a pitch deck. For Tesco, that scale means millions of transactions and a grocery footprint spread across the UK.
Is NeoDay only suited to grocery retailers the size of Tesco? No. NeoDay works across food retail, QSR, fuel retail and fashion retail, and the platform scales down in cost and complexity for smaller estates. See what a loyalty programme is and how it works for the basics if you're starting from scratch.
Does a gamified mechanic like the one in the Tesco build risk fatiguing members over time? It can, if the mechanic never changes; that's a known risk in gamified loyalty design. Time-boxing campaigns (a few weeks, not an open-ended points balance) and rotating the mechanic between seasons is the usual fix.
How does NeoDay's role differ from Magneds' role in a build like this? NeoDay supplies the platform (the API layer, the engine, the frontend components); Magneds acted as the implementation partner handling the specific build and integration work for Tesco. Not every client needs an implementation partner; some retailers build directly with NeoDay's own team.
If you want the full breakdown of how the programme is structured, request the Tesco and Magneds case study or book a short demo to see the same platform configured for your own store count.
More questions about retail loyalty? Find the answers in our loyalty FAQ.
