How to Create Event-Triggered Customer Rewards With Shopify Flow and Klaviyo

How to Create Event-Triggered Customer Rewards With Shopify Flow and Klaviyo

A lot of reward programmes start with the promo code.

Someone creates THANKS10, decides who should get it, builds a campaign around it, then repeats the same process again next month.

That’s fine for a broad promotion.

It’s less useful when the reward should only exist because a customer has done something specific.

Maybe they’ve:

  • placed a high-value order;
  • made their second purchase;
  • bought a particular product;
  • reached a VIP threshold;
  • hit a loyalty milestone;
  • come back after a long period of inactivity.

In those cases, the better question is:

Can the customer behaviour itself create the reward?

With Shopify Flow, yes.

The logic is:

CUSTOMER EVENT

↓

CHECK ELIGIBILITY

↓

CREATE UNIQUE REWARD

↓

SEND REWARD TO KLAVIYO

↓

TRIGGER LIFECYCLE MESSAGE

That gives you something evergreen. The reward is created because the customer qualifies, rather than because someone remembered to build another campaign.

Want the workflow already built?

The Event-Triggered Customer Reward → Klaviyo tool includes the ready-to-import Shopify Flow workflow behind this setup.

Get the workflow →


The use case

Let’s use a simple example.

You want to reward customers who place an order worth more than €100.

You could export those customers, generate codes, upload them somewhere, build an email, then keep doing that forever.

Or you can let Shopify handle it as the order happens.

The workflow we built does this:

Order created

↓

Wait 5 minutes

↓

Is the order value greater than 100?

↓

Calculate a 30-day expiry

↓

Create a unique 10% Shopify discount

↓

Restrict it to that customer

↓

Send Customer Reward Created to Klaviyo

That €100 threshold and 10% reward are just defaults.

The useful bit is the structure.

You can swap the eligibility rule for something much more relevant to your own retention programme.


When this is useful

This pattern works well when Shopify already knows the thing that should trigger the reward.

For example:

Customer behaviour Possible reward
Order over €100 10% thank-you reward
Second order placed Next-purchase incentive
Customer reaches VIP tier VIP benefit
Customer buys Product A Reward for Product B
Customer reaches spend threshold Loyalty reward
Customer returns after lapsing Reactivation incentive
Referral completes Referral reward

The logic stays the same:

Trigger → Qualify → Create → Communicate

Only the qualifying rule changes.


When you probably don’t need this

If your use case is simply:

Subscribe to email → get 10% off

then I wouldn’t build this.

Klaviyo can handle that more simply.

Shopify Flow becomes more useful when the reward depends on commerce behaviour or customer state, for example:

  • order value;
  • order count;
  • products purchased;
  • customer tags;
  • Shopify segments;
  • customer metafields;
  • customer lifecycle state.

That’s really the distinction.

If Shopify knows why the customer deserves the reward, let Shopify make that decision.

Then let Klaviyo handle the messaging.


The default workflow

The commercial workflow ships with a simple starting point:

Trigger

Order created

Eligibility

Order total > 100

Reward

10% off

Expiry

30 days

Usage

1 redemption

Customer eligibility

Only the customer who triggered the workflow.

Klaviyo event

Customer Reward Created

You can import it as-is, then change the parts that matter to your programme.

Prefer to configure rather than build?

The Event-Triggered Customer Reward → Klaviyo workflow gives you the structure already built.

Get the Shopify Flow workflow →


Step 1: Start with the event

Every workflow needs a trigger.

For this one, we use:

Order created

That gives Shopify Flow access to the order and customer data needed for the next steps.

You could build the same idea around other Shopify events, but Order created is a useful starting point because it gives you a lot to work with immediately.

The important question is:

What behaviour should cause the customer to become eligible?

That should determine the trigger.


Step 2: Decide who qualifies

This is where the commercial logic lives.

In the default workflow:

Order total > 100

If no:

Stop

If yes:

Continue

That’s deliberately simple.

You could replace it with:

Second purchase

Customer order count = 2

Product reward

Order contains SKU X

VIP reward

Customer has VIP tag

High-value customer

Lifetime spend > X

Customer-state reward

Customer metafield = specific value

The rest of the workflow doesn’t need to change.

That’s what makes the structure reusable.


Step 3: Calculate the expiry

The workflow then calculates when the reward should stop being valid.

In the supplied version:

Expiry = 30 days after the triggering order

That means each customer gets their own redemption window.

Customer A qualifies today.

Customer B qualifies three weeks later.

Both get 30 days from the moment they earned the reward.

That’s much cleaner than managing one global expiry date.


Step 4: Create the reward in Shopify

Once the customer qualifies, Shopify creates the code automatically.

The format uses customer and order information, so it becomes unique.

For example:

REWARD-12345678-1042

rather than something shared like:

THANKS10

The default reward is:

10% off

and the discount is configured with:

  • a start date;
  • a 30-day expiry;
  • one total redemption;
  • one use per customer;
  • eligibility restricted to the customer who triggered it.

So even if the code gets forwarded to someone else, it isn’t just a public promo code.

It belongs to the customer who earned it.


Why create the code dynamically?

You could pre-generate a huge bank of codes.

Sometimes that works.

But generating them at the moment of eligibility is cleaner for this kind of lifecycle programme.

You only create rewards when they’re needed

No unused code list sitting around.

Each customer gets their own expiry

The offer starts when they qualify.

The code is tied to a real event

You can trace the reward back to the order that caused it.

The customer journey can run forever

You don’t need to rebuild the same campaign every month.

That’s the real value here.


Step 5: Send it into Klaviyo

Once Shopify has created the reward, Flow sends a custom event into Klaviyo:

Customer Reward Created

That event can include:


reward_type
discount_code
reward_value
reward_expires_at
reward_source
order_number

For example:


{
  "reward_type": "customer_reward",
  "discount_code": "REWARD-12345678-1042",
  "reward_value": "10%",
  "reward_expires_at": "...",
  "reward_source": "shopify_flow",
  "order_number": "#1042"
}

At that point, Shopify has done its job.

Klaviyo now knows:

  • who qualified;
  • what they received;
  • what the code is;
  • when it expires;
  • which order created it.

That’s everything you need to build the customer message.

Want the Shopify → Klaviyo handoff already configured?

The paid workflow includes the reward creation logic and the Customer Reward Created event setup used here.

Get Event-Triggered Customer Reward → Klaviyo


Step 6: Build the Klaviyo flow

Your Klaviyo flow can simply trigger from:

Customer Reward Created

Then use the event properties in the email.

For example:

A little something for your next order.

You’ve unlocked 10% off.

Your personal code:

{{ event.discount_code }}

Valid until:

{{ event.reward_expires_at }}

The message can change depending on why the customer qualified.

A high-value-order reward might feel like a thank-you.

A second-purchase reward might push toward a third order.

A VIP reward might feel more exclusive.

The Shopify workflow doesn’t need to know any of that.

It just sends the right data into Klaviyo.


Event properties vs profile properties

This is a useful distinction.

The actual reward belongs to the event.

Things like:


discount_code
reward_value
order_number
reward_expires_at

describe one specific reward that was created at one specific moment.

Profile properties are better for longer-lived customer state.

For example:


has_received_customer_reward = true
last_reward_created_at = ...
last_reward_expires_at = ...

That tells you something about the customer overall.

Keeping those two ideas separate makes the Klaviyo data much easier to reason about later.

Read: Customer Properties vs Event Properties in Klaviyo: What’s the Difference?


How I’d adapt this for other programmes

The default version uses order value because it’s easy to understand and easy to edit.

But the same workflow can support much more interesting retention logic.

Second-purchase reward

Order created

↓

Has customer placed exactly 2 orders?

↓

Create reward

↓

Send to Klaviyo

VIP reward

Order created

↓

Does customer qualify for VIP?

↓

Create reward

↓

Send VIP journey

Product-specific reward

Order contains Product A

↓

Create reward

↓

Klaviyo introduces Product B

High-value thank-you

Order value > €250

↓

Create personal reward

↓

Send thank-you journey

Same workflow.

Different condition.


What you actually need to customise

If you import the ready-made version, there are really only four things to think about.

1. Eligibility

Default:

Order total > 100

Replace that with whatever matters to your programme.

2. Reward value

Default:

10%

Change it if needed.

3. Expiry

Default:

30 days

Make it shorter or longer depending on the use case.

4. Klaviyo setup

Add your Klaviyo details and confirm the event properties are arriving correctly.

That’s the point of the product.

The infrastructure is already built.

You decide the customer logic.

Skip the build

Event-Triggered Customer Reward → Klaviyo includes:

  • Order created trigger
  • Order value > 100 eligibility
  • Unique customer reward code
  • 10% discount
  • 30-day expiry
  • One redemption
  • Customer-specific eligibility
  • Klaviyo Customer Reward Created event

Get the workflow here


Test it properly

Any workflow that creates discounts deserves proper QA.

Before switching it on, test:

  • a qualifying order;
  • a non-qualifying order;
  • the generated code;
  • the discount value;
  • the expiry date;
  • whether someone else can use the code;
  • whether the code can be redeemed twice;
  • whether the Klaviyo event arrives;
  • whether the event properties are populated correctly.

Automation is useful because it removes manual work.

That only helps if you trust it.


The Brutish rule

Don’t automate something just because Shopify Flow makes it possible.

Start with the customer experience.

Ask:

What did the customer do?

Then:

What should happen because of it?

If the answer depends on commerce behaviour inside Shopify, Flow can be the bridge between that behaviour and your Klaviyo lifecycle programme.

In this case:

Customer places a qualifying order

↓

Shopify creates the reward

↓

Klaviyo communicates it

Simple enough for the customer.

Automated underneath.


Get the working workflow

The Event-Triggered Customer Reward → Klaviyo tool gives you the .flow file behind this setup.

It includes:

  • order-triggered reward logic;
  • configurable eligibility;
  • unique customer discount codes;
  • configurable percentage reward;
  • automatic expiry;
  • one-use protection;
  • customer-specific eligibility;
  • Klaviyo event handoff;
  • profile and event properties.

Get Event-Triggered Customer Reward → Klaviyo


Need something more specific?

The supplied workflow is deliberately simple.

If your programme needs more complex logic around:

  • VIP tiers;
  • loyalty;
  • memberships;
  • subscriptions;
  • customer metafields;
  • specific products;
  • Buy X Get Y rewards;
  • multiple reward types;

Brutish can build the Shopify → Klaviyo system for you.

Work with Brutish →



Leave a comment

This site is protected by hCaptcha and the hCaptcha Privacy Policy and Terms of Service apply.