How to design loyalty architecture? (not really technical)

In previous articles, we covered loyalty strategy and mechanics. Now, we will discuss how to design loyalty architecture.

Why is this important?

When discussing loyalty plans with clients and prospects, conversations about architecture often lead to a familiar scenario. CMOs, CRM, and Loyalty Managers naturally expect their technical counterparts in IT / tech teams to handle system architecture and integrations.

However, this often doesn't go smoothly, primarily for two reasons:

1. Tech teams must juggle priorities across multiple projects and departments. What's a top priority for the digital marketing team might be a lower priority for IT.
2. Tech teams often have a limited understanding of marketing requirements, particularly for specific initiatives like new or revamped loyalty programs.

For once, we'll avoid going into interdepartmental politics. However, it's important to address the second point. While it's easy to criticize the perception of tech teams being disconnected from marketing realities, the responsibility ultimately lies with the business initiative owner.

As Martech.org emphasizes, marketers should develop an architecture vision as one of the six core competencies for marketing technology initiatives.

This is your tech department when you tell them they need to come up with a system architecture for a loyalty program

Let's clarify: architecture vision is not about diving into the technical weeds. You shouldn't be expected to decide on specific technologies, frameworks, technical design patterns, or protocols; instead, focus on clearly defining your needs. Because without this clarity, tech teams are forced to make assumptions, often leading to less than ideal outcomes for everyone involved. Not to mention the potential for awkward encounters at the next company party.

So, to the point. In this article, I’ll address the following questions:

• How to translate loyalty strategy and mechanics into terms your tech teams will understand?
• Which systems will be involved in your loyalty program?
• What are the typical loyalty processes that require interactions between systems?
• What are the key non-functional considerations when designing loyalty program architecture?

Fasten your architecture seatbelt and let’s goooo!

User stories - way to talk to your tech teams

User stories are my preferred way to describe business requirements to technical teams. While not the only (and not ideal) method, they are highly effective.

The standard format for a user story follows a simple template:

"As a [type of user], I want to [perform an action] so that [the intended result]."

This structure ensures that every feature or function in your loyalty program has a clear purpose tied directly to user needs. For instance, rather than simply stating "The system needs a points calculation function", a well-crafted user story might read: "As a frequent shopper, I want to easily see how many loyalty points I've earned on my purchase so that I can track my progress toward my next reward."

In loyalty contexts, actions might include redeeming points, checking reward status, participating in special promotions, or sharing achievements with friends. All your planned loyalty mechanics should be translated into one or more user stories. The action component of the user story bridges user intent with system functionality—precisely what your tech teams need to start thinking about loyalty ecosystem architecture.

Key Considerations for Creating Loyalty User Stories

Include less-regular use cases to ensure your system can handle various situations:

• What happens if a purchase transaction is reverted or canceled?
• How does the system respond when someone shares a loyalty discount coupon with friends?
• What occurs when multiple people start collecting points on one account?
• How are points handled in case of product returns or exchanges?
• What happens to accumulated points if an account becomes inactive?

How will members interact with the program across different channels (in-store, online, mobile app)?

For global businesses - how will the program adapt to different currencies, languages, and regional preferences?

Ask yourself what kind of data will be needed for you to present loyalty program impact on the wider organizational goals (e.g., loyalty program impact on revenue). What are the metrics that you’ll present to your management once the program is up and running?

Remember, the goal is not to have a user story for every possible scenario. Instead, aim to provide a good high-level overview of loyalty processes with the end users at the center of the conceptual process. This approach will give your tech team a clear understanding of the program's requirements and functionality, enabling them to design an architecture that meets both business and user needs.

Systems involved in loyalty architecture

At the heart of every loyalty architecture is the system that will store and manage loyalty data. Think of tiers, points, loyalty benefits, rewards, and so on. It can either be a dedicated, full-fledged loyalty platform, or it can be done as an extension or a feature set of some other system (e.g., a CRM platform).

In our Integrated Loyalty Report (which, btw, is pretty neat), we go deep into types of loyalty platforms, pros, and cons of building such software in-house or buying it off the market. Make sure to check it out if you haven’t already.

Source: Integrated Loyalty Report 2025

Now, there will be some loyalty processes and user stories that will be fully handled by the loyalty platform. However, others will require interaction with other systems. Sometimes to present a progress bar to the member in the mobile app, other times to send point-related data to accounting software to ensure all of the point-related liability is accounted for.

So, what are typical process areas that require systems to communicate with each other?

Activity capture

You want your loyalty platform to capture customer activity that you’ll then use to incentivize them. Typically, these include transactional data— i.e. purchases. However, more and more often, loyalty programs incentivize non-transactional behavior. For example, submitting preferences, filling out a survey, completing certain achievements, playing a game, etc.

Once you have your loyalty user stories collected, think of all different activities that you’d like to incentivize.

The key question to ask in this area - what events does a loyalty system need to capture to realize loyalty user stories?

Transactional data - e.g., someone buying something

• What specific purchase details need to be captured (e.g., product, price, quantity, payment method, location)?
• How will purchase returns or cancellations be recorded and reflected in loyalty points?
• Do we need to capture online vs. offline transactions differently?

Non-transactional data - e.g., someone abandoning the cart in e-commerce or signing up for return-in-stock notifications

• What other e-commerce events should be tracked (e.g., product views, wish list additions, reviews)?
• What non-transactional data should be captured in-store (e.g., event attendance, survey responses via kiosk)?
• How will third-party activity be captured (e.g., activity on partner websites or apps)?

Consent data - e.g., someone giving consent to receive personalized recommendations

• What types of consent need to be tracked (e.g., email, SMS, data sharing)?
• How will consent changes be recorded and propagated across systems?
• How will consent expiration be handled?

Profile update - e.g., someone filling out their preferences

• What specific profile information is important for the loyalty program (e.g., demographics, interests)?
• Will profile completion itself be a trigger for rewards or points?

Telemetry data - e.g., spending more than 10s on a certain product page

• What specific digital behaviors are relevant (e.g., app usage, feature engagement, content consumption)?

CRM data - e.g., someone contacting customer service or inquiring about some product feature

• What CRM interactions are relevant for loyalty (e.g., support tickets, complaints, feedback)?
• Do I need (and can I have) these events processed in real-time and instantly react to them?
• Which events require real-time processing (e.g., immediate points for a purchase)?

Communication

Back in the day, when all-in-one marketing platforms ruled the world, they often combined functionalities from different marketing areas—e.g., promo management and email campaigns.

Modern tools are generally much more specialized, each doing less, but in a better way (or at least they claim to).

The consequence of this process is that very often, a system that will hold your loyalty logic will not be the one pushing out communication to your customers. So, here we have another area where integration between systems is quite important.

Aspects to think about in this area:

Personalization Capabilities

• What kind of dynamic content from the loyalty program you would like to use in your communication (e.g. inserting someone’s points balance in an email)

Segmentation and Targeting

• How will customer segments be defined and used to send targeted communications?

Frequency and Timing

• How will communication frequency be managed to avoid "message fatigue"?
• Should communications be scheduled based on customer behavior or specific events?

Transactional vs. Promotional Communications

• How will transactional messages (e.g., reward confirmations, point balance updates) be handled differently from promotional messages?
• Will different systems be responsible for each type of communication? (we do not recommend this btw)

Consent Management

• How will customer communication preferences and consent be captured and enforced?
• Does the system integrate with a Consent Management Platform (CMP)?

Omnichannel Delivery

• How will consistent messaging be maintained across all channels?

Rewards management

A core function of any loyalty program is the management of rewards. This involves not only defining the types of rewards offered but also the processes and systems required to deliver those rewards to members.

If you rely on 3rd party / partner rewards, this introduces another layer of complexity. Your systems need to communicate with the partner systems to authorize, track, and potentially fulfill those rewards. This exchange of information is critical. Your loyalty system needs to reliably inform the third-party system that a given member has earned and should be awarded a specific reward. This communication must also often flow in the opposite direction, with the 3rd party informing your systems about the reward redemption.

Things to consider here:

How will the 3rd party rewards be billed?

• What billing models are available (e.g., per redemption, monthly fee, volume-based)?
• How will billing cycles and invoices be managed?
• What level of reporting detail is needed for billing reconciliation?

What if a member never actually redeems a reward at your partner? Should you still pay for the reward?

• What is the policy on unredeemed rewards?
• Is there an expiration date for rewards?

If you’re using physical rewards:

• What is the process for reward fulfillment (e.g., shipping, in-store pickup)?
• How will inventory be managed for physical rewards?
• What happens if a physical reward is lost, damaged, or stolen?
• How are returns of physical rewards handled?
• How will reward availability and inventory be communicated to members?

How do you want the process of adding or removing partners to look like?

• What is the process for onboarding new reward partners?
• How will partner agreements and terms be managed within the system?
• What happens to existing rewards or points when a partner is removed?

Reporting and Analytics

One of the most overlooked areas when planning loyalty architecture is pulling the data out of your loyalty ecosystem. It's crucial to think about reporting and analytics from the very beginning, not as an afterthought.

Items to consider in this area:

How will the effectiveness of different loyalty campaigns be measured?

• What specific metrics will be used to evaluate campaign success (e.g., incremental sales, customer engagement, reward redemption rates)?
• How will A/B testing results be tracked and analyzed?
• Will reports be generated automatically, or will manual analysis be required?

What would be a set of information you’d like to review daily / weekly / monthly about your loyalty program?

• What key performance indicators (KPIs) need to be monitored regularly (e.g., enrollment rates, active members, point balances, reward costs)?
• What level of detail is required for these reports?
• Who will be responsible for reviewing these reports, and what actions will they take based on the data?

How will you be able to prove your loyalty program’s impact on the wider org’s goals

• How will loyalty program data be integrated with other business data (e.g., sales, marketing, finance) to demonstrate overall ROI?
• What specific reports or dashboards will be used to communicate the program's value to stakeholders?
• How will you measure the impact of the loyalty program on customer lifetime value, retention, and acquisition?

How will you monitor your program for frauds and anomalies?

• What types of fraudulent activity need to be detected (e.g., account fraud, point abuse, reward theft)?
• What automated alerts or reports will be used to identify suspicious activity?
• What processes will be in place to investigate and address fraud?
• What data visualization tools would you like to use to present loyalty program data - if you’re using one already, it’s probably better not to re-invent the wheel.

Drafting an architecture diagram

Okay, that was a lot of questions to ask yourself! Moving forward, something that will make the architecture discussions much easier is to sketch an architecture diagram. Even if you're coming from a business owner perspective, a simple, high-level diagram can be incredibly helpful.

A good practice is also to visualize key user stories on a diagram like that, showing what kind of events and data should flow between different systems. This helps to illustrate the connections and dependencies within your loyalty ecosystem.

Here’s our very simple outline to depict a typical setup for retail (and most other) industries - you can use it as a starting point:

If you’d like to learn more about each of these systems, we actually cover each area in detail in our Composable Tech Stack for Fuel Retail Loyalty whitepaper. You can find descriptions and our vendor recommendations there.

Non-functional loyalty requirements

If you reached this point and have your loyalty user stories and answered questions regarding system integrations -you’re in a very good position.

The last item on the agenda is to have a very brief overview of non-functional requirements that you should consider when designing your loyalty setup. Here - the ball really should be on the tech teams’ side, but again, without business input, they will start to design a system for themselves and not for you.

There are 6 key areas of non-functional requirements when it comes to designing a loyalty ecosystem:

Availability & Scalability

Availability refers to the system's uptime and reliability. It ensures that the loyalty program is accessible to members when they need it. This includes considerations like planned maintenance, disaster recovery, and the system's ability to handle unexpected spikes in traffic.

Useful business input:

• What kind of traffic can you expect as regular and peak? Are there any cycles that your business is following (e.g. peaks on weekends)
• How should temporary loyalty program unavailability be communicated to your customers and site staff?

Performance

Performance focuses on the system's responsiveness and efficiency. It covers aspects like response times for transactions, the ability to handle concurrent user activity (especially during peak times or promotions), and the overall speed of the loyalty program.

Useful business input:

What are the expected performance benchmarks for critical user actions? For example:

• How quickly should a customer be able to view their points balance after logging in?
• How long should it take to process a point redemption at the POS?
• What is the expectation around communication send-out - what is the acceptable delay between performing an action and customer receiving a notification
• How many concurrent promotions / campaigns are you planning to run?

Integrability

Integrability concerns the system's ability to connect and exchange data seamlessly with other systems, such as Point of Sale (POS) systems, CRM, e-commerce platforms, marketing automation tools, and data platforms - all things I talked about in the previous part of this article.

Here - an important aspect is to go slightly beyond the here and now. Think about other projects and initiatives you have in place and what are the systems you will want the loyalty platform to be integrated in the future.

Security & Compliance

Security and compliance focus on protecting sensitive customer data and ensuring that the loyalty program adheres to relevant regulations and industry best practices.

Useful business input:

Clearly define the sensitivity of the data that will be handled by the loyalty program (e.g., Personally Identifiable Information (PII), payment data, transactional data)

• What compliance standards or regulations apply to our loyalty program, and how do these vary across the countries in which we operate (e.g., GDPR in Europe, CCPA in California, other local data protection laws)? What features or functionalities are needed to ensure compliance in each region?
• Specify which countries' data will be handled by the loyalty solution. Are there any specific data residency requirements or restrictions on cross-border data transfers that need to be addressed?
• What are the requirements for user authentication and authorization? How will access to the loyalty system be controlled and managed for both internal users and customers, and how will these controls adapt to different regional requirements?

Tests

This area covers the testing strategies, procedures, and documentation used to ensure the quality, reliability, and functionality of the loyalty program. The best kind of input you can provide here is a couple of end-to-end testing scenarios. They can be used as a success metric for the tech teams when they work on the implementation of the loyalty program.

Useful business input:

• Provide detailed end-to-end testing scenarios that represent critical customer journeys and business processes.
• These scenarios should cover typical use cases as well as edge cases.

For example:

• A customer joins the loyalty program, makes a purchase, earns points, and redeems those points for a reward, both online and in-store.
• A customer returns a product, and the associated loyalty points are adjusted correctly and the used discount coupons are rolled-backed and available for use once again.

Define clear acceptance criteria for each test scenario. What are the expected outcomes, and what constitutes a successful test from a business perspective?

Conclusions

Let's face it - designing loyalty architecture might sound intimidating, but it doesn't have to be.

The key is bringing your business vision and tech needs together in a way everyone understands. By turning your loyalty strategy into clear user stories, mapping out how your systems will talk to each other, and thinking ahead about things like performance and security, you're setting yourself up for success.

The best loyalty programs don't happen when marketing and IT teams work in separate bubbles - they happen when everyone's on the same page. This approach doesn't just give you a technical system that works; it creates a loyalty ecosystem that can grow and change as your business does.

At the end of the day, it's not about building complex architecture - it's about creating experiences that keep customers coming back and showing real value for your business. Get this right, and you'll not only have happy customers but also much smoother conversations with your tech team at the next company party!