Building a Loyalty Program Automation in Xperience by Kentico

The most effective loyalty programs reward customers and recognize them at the right moment. A tier upgrade email that arrives the day after a qualifying purchase lands differently than one that arrives weeks later because someone finally ran a report.

This article walks through how Dancing Goat's GoatRewards program uses a set of developer-provided activity hooks and five marketer-owned automations to make every tier-transition moment feel intentional without requiring hands-on management.

The architecture

This is the most developer-assisted scenario in the series, and understandably so. The intelligence for the behavior required to run a loyalty program belongs in code:

• Tracking a contact's running points total

• Evaluating numeric thresholds

• Handling edge cases like a first order that qualifies for multiple tiers

Automations work best as condition-check and respond tools, not calculation engines.

The pattern that makes this work cleanly is the same one introduced in Chaining Automations in Xperience by Kentico: A Multi-Part Content Drip: the developer logs a custom activity at the right moment, and a dedicated automation responds to it.

The developer is responsible for deciding when to fire each activity. The marketer is responsible for everything that happens after, like communicating reward program value to the customer.

The five custom activity types:

Code name	Moment
dg_first_purchase	Contact's first completed order
dg_approaching_roaster	Cumulative points cross 400
dg_tier_roaster_reached	Cumulative points cross 500
dg_approaching_master_roaster	Cumulative points cross 900
dg_tier_master_roaster_reached	Cumulative points cross 1500

All five are created in Contact Management → Activity types.

The type alone is the signal in every case, so no value payload is required. The developer's order completion code evaluates the contact's cumulative points total and fires only the most meaningful activity for that purchase.

A customer who buys five expensive grinders as their first order and crosses 1500 points in one transaction triggers dg_tier_master_roaster_reached only. They won't experience the awkward event of all five activities in sequence.

The two contact fields:

• DG_GoatRewardsTier (text): written by Set contact field value steps in the tier-achievement automations. Values: "Brewer", "Roaster", "MasterRoaster". This field is the guard that prevents duplicate upgrade emails on subsequent purchases.

• DG_GoatRewardsPoints (integer): written by the developer's order completion code. Reflects the contact's current cumulative total.

Both fields are added to the Contact class via Modules → Contact data management → Classes → Contact management - Contact → UI Forms, following the same process described in How to Build a Product-Specific Post-Purchase Automation in Xperience by Kentico.

Setting the values for these fields is also handled by code in the checkout process.

Reward tier progression through automations

Each of the 5 automations below handles a different transition from one point total to the next through the custom activity signals triggered during checkout.

1. First purchase: Welcome to GoatRewards

Trigger: dg_first_purchase

Steps:

1. Custom activity trigger: dg_first_purchase
2. Wait 1 hour: allows transactional purchase emails to land first
3. Send email: "Welcome to GoatRewards": This email explains how points work, what Brewery, Roaster, and Master Roaster tiers offer, and reminds the customer they are on their way to some great benefits.
4. Finish: "GoatRewards welcome sent"

This automation runs once per contact. Because the dg_first_purchase activity is only ever logged once by the developer code, recurrence isn't a concern.

2. Approaching "Roaster" tier

Trigger: dg_approaching_roaster

Steps:

1. Custom activity trigger: dg_approaching_roaster
2. Wait 1 hour: allows transactional purchase emails to land first; gives developer code time to settle contact state
3. Condition: is DG_GoatRewardsTier equal to "Brewer"? If the customer made another purchase during the wait and crossed the Roaster threshold, the upgrade email from Automation 3 is already on its way and this nudge is no longer relevant
4. Send email (YES):"You're closer than you think": product recommendations to encourage the next purchase, a small incentive (e.g. free shipping on the next order), reminder of what the Roaster tier unlocks
5. Finish (YES): "Roaster nudge sent"
6. Finish (NO): "Skipped: already Roaster"

This email automation is important. Customers who made an initial purchase or two might not yet be Dancing Goat enthusiasts. The GoatRewards Welcome email might have been lost in their inbox.

If a customer is getting close to the Roaster rewards tier, it's a good opportunity for us to reach out to the customer with a contextual and helpful nudge that will either drive another conversion to reach the benefits of the next rewards tier or plant a seed in the customer's mind.

Note that the calculation to determine if the customer's DG_GoatRewardsPoints is greater than 400 but less than 500 is done in code, not in the automation.

3. Roaster achieved: Congratulations

Trigger: dg_tier_roaster_reached

Steps:

1. Custom activity trigger: dg_tier_roaster_reached
2. Wait 1 hour: allows transactional purchase emails to land first
3. Condition: is DG_GoatRewardsTier equal to "Roaster"? If the customer made another purchase during the wait and crossed the Master Roaster threshold, the developer code has already updated the tier field and the Roaster upgrade email wouldn't be relevant.
4. Send email (YES):"You've hit Roaster status 🐐🔥": what the tier means, current perks (early access to limited roasts, 10% loyalty discount), how many points to Master Roaster, early invitation to the next Brew Lab event
5. Finish (YES): "Roaster email sent"
6. Finish (NO): "Skipped: already at Master Roaster"

Including the DG_GoatRewardsTier check is a customer experience decision. If you want customers to receive the benefit at each tier, no matter how quickly they progress, you could remove the condition check.

As it stands, failing the check implies they've already reached Master Roaster tier through additional purchases.

4. Approaching Master Roaster: One more push

Trigger: dg_approaching_master_roaster

Steps:

1. Custom activity trigger: dg_approaching_master_roaster
2. Wait 1 hour: allows transactional purchase emails to land first
3. Condition: is DG_GoatRewardsTier equal to "Roaster"? If the customer crossed the Master Roaster threshold during the wait, the upgrade email from Automation 5 is already on its way and a "you're almost there" nudge arriving right before a "you made it" email feels like automation, not personalization.
4. Send email (YES): "Master Roaster is within reach": lighter touch than the Roaster nudge, calibrated for a customer who already knows and trusts the brand, a small promo discount to encourage one more purchase
5. Finish (YES): "Master Roaster nudge sent"
6. Finish (NO): "Skipped: already at Master Roaster"

5. Master Roaster achieved: The top tier

Trigger: dg_tier_master_roaster_reached

Steps:

1. Custom activity trigger: dg_tier_master_roaster_reached
2. Wait 1 hour: allows transactional purchase emails to land first
3. Condition: is DG_GoatRewardsTier equal to "MasterRoaster"? Confirms the developer code has written the expected state. In practice, this should always be true, but the condition makes the automation's assumption explicit and prepares the flow for additional reward tiers in the future.
4. Send email (YES): "You're a Master Roaster now 🐐🏆": exclusive perks (free shipping, invite to annual tasting event), CTA to claim a Dancing Goat latte cup via a short form.
5. Finish (YES): "Master Roaster email sent"
6. Finish (NO): "Skipped: Already at next tier"

The latte cup claim form submission can itself trigger a fulfilment confirmation automation. The chain continues beyond what's described here, using the same form-submission trigger pattern from Scenario 1.

GoatRewards tier condition checks and Skipped finish steps

In the automation's Statistics view, a high count on any "Skipped" finish step is a signal worth investigating. It means customers are moving through the loyalty program faster than the automation expected.

That's good news for the business, but it might also mean the approaching-tier thresholds (400 and 900 points) are set too conservatively and could be moved closer to the actual tier boundaries to make the nudge emails more timely.

It could also indicate that the tier thresholds need to be spaced more effectively.

The automation gives the marketing team data they otherwise couldn't easily access.

Marketer and developer collaboration

We already established that marketers can extend contact fields and define custom activity types themselves, but collaboration with a software developer can lead to more manageable and focused marketing responsibilities.

Level up the marketer's capabilities

The goal of automations is to give marketers autonomy where it matters most: customer experiences. Here are two additional investments developers can make to further build on that idea:

Product card Email Builder widget: this allows marketers to select products from the Content hub when authoring recommendation emails (Automations 2 and 4) without developer involvement. Built once using the Email Builder widget development documentation, reusable across any automation or campaign email indefinitely.

Extending the administration UI for program thresholds: the 400, 500, 900, and 1500 point breakpoints are currently hardcoded in the order completion logic. Extending Xperience's administration interface gives marketers a form to adjust these thresholds without touching code.

Alternatively, the program's configuration could live as a dedicated content item in the Content hub, treating GoatRewards as a blend of structured data and messaging that editors can manage alongside other content.

If the content item had fields for the reward program messaging, developers could display it on the order confirmation page as another reminder of the customer's program status.

---

Both are optional enhancements. The five automations work without them. But they're the difference between a loyalty program that requires a developer for every adjustment and one that a marketer can evolve independently.

Why separate responsibilities?

We've already seen scenarios where developers manage complexity for marketers with easy-to-use tools like the Conditional Activity Widget.

In this scenario, the GoatRewards tier limit checks, running points total calculation, and updates to each customer's current tier are performed in code instead of automations for the same reason.

Code can be easily tested when AI agents quickly generate automated test code, giving teams confidence the reward program activities are logged at all the right times.

Automations - especially those with Wait steps - are much more difficult to test.

Our recommendation is that marketers avoid this logic ownership and validation responsibility and instead focus on crafting the compelling email subject lines, reward program education, purchase nudge messages, and decide what kinds of promotions are needed to drive conversions based on automation and customer journey data.

A future full of collaboration

Is it possible to build complex logic into an automation? Yes, but we've already seen that it doesn't always scale well.

Upcoming Xperience by Kentico roadmap improvements will bring richer conditions, more powerful automation triggers, and fully extensible actions, leading to greater marketer autonomy for the kinds of features highlighted throughout this series.

• Marketing Automation Extensibility - Custom Actions

• Marketing Automation Extensibility - Custom Triggers

• Marketing Automation Extensibility - Custom Conditions

At the same time, I believe these features will significantly increase the value of collaboration between marketers and developers.

Extending the scenario

Here are a few more points of inspiration you can adapt to your automation scenarios like this one.

Connect event attendance to points: as noted in How to Automate Event Registration and Attendance Follow-Up in Xperience by Kentico, the dg_brewlab_converted activity logged after the Brew Lab thank-you email can signal the developer's points logic to award attendance points. The loyalty automations respond automatically when the threshold activities fire.

Use tier data across the platform: DG_GoatRewardsTier written to the contact record is available everywhere in Xperience. A contact group called 'GoatRewards Roasters' can use this field and become a segment you can target in campaigns, personalization rules, and customer journeys without any additional automation work.

Don't forget to connect your automation to Campaigns and Customer Journeys, giving you the power to iterate and optimize your work with the help of AIRA agents.

What to build next

The GoatRewards scenario is the most complex in this series, but every technique it uses was introduced in an earlier article.

• Scenario 1 - Automation best practices

• Scenario 2 - Contact field conditions

• Scenario 3 - Custom activity triggers

• Scenario 4 - Custom activity as a clear business signal

This series was designed to build on itself and now you've seen the whole thing!

If you want to read everything, starting from the beginning, check out Xperience Automations: You've Been Meaning to Explore Them. Here's What's Been Waiting.

Look for updates to these posts when Xperience's new automation features are released, along with new articles showing how to take advantage of custom triggers, conditions, and actions.