Skip to content
Klaviyo loyalty flows & automationKlaviyo, Flows, Points expiry

How to Build a Points-Expiry Win-Back Flow in Klaviyo

Points expiring is the one loyalty event that only hurts you if the customer finds out too late. Handled well, a win-back flow turns an expiring balance into one more order. Handled badly, or skipped, it turns into a support ticket (“where did my points go?”) or a customer who quietly stops trusting the balance shown in their account. This is the full build: the segment, the timing, the copy, and where this specific flow tends to go wrong.

Get the trigger right first

The instinct is to trigger this flow on a “points expired” event. That is the wrong trigger for a win-back; by the time that event fires, the points are already gone and there is nothing left to save. The flow needs to catch customers before expiry, which means triggering on a segment rather than an event.

Build a segment: Points Expiring Soon is greater than 0, combined with Points Balance is at least your smallest reward threshold (no point warning someone about points that would not have covered anything anyway). Trigger the flow on entering that segment, not on any single event.

A true Points Expired trigger still has a place, just not in this flow: use it separately to close the loop after a balance actually lapses, a short, low-pressure “your points expired” note rather than a win-back attempt.

Decide the warning window

How far ahead of expiry the segment should catch someone depends on how the redemption itself behaves. If redeeming and using a reward can happen in one sitting (points to coupon to checkout), a week of warning is enough. If your customers tend to redeem then shop later, wanted or not, give two weeks so there is real time to act on the second email.

There is no universal right answer here; it is a trade-off between “far enough ahead to be useful” and “close enough that it still feels urgent.” Whatever window you pick, keep the segment’s Points Expiring Soon threshold matched to it. Widening the window without adjusting the underlying data means the flow either fires too early to feel relevant or too late to be a genuine win-back.

The two-email structure

One email undersells the flow; three starts to feel like pressure for what is, after all, the customer’s own points. Two works for most stores.

Email one, on segment entry. State three things and nothing else: the balance at risk, what that balance actually converts to (do not make them do the math), and the exact expiry date. If the balance already clears a reward threshold, say so explicitly, “your points cover [reward] right now.”

Email two, a few days before expiry, sent only to people who have not acted. This is where a conditional split on Points Redeemed since the flow started earns its place: exclude anyone who already redeemed, and address only the people who still have something to lose. Keep the second email shorter than the first. It is a reminder, not a re-explanation.

Common mistakes that make this flow backfire

Triggering on the expiry event instead of the segment. Covered above, but worth repeating because it is the single most common version of this flow done wrong: a “win-back” that fires after the points are gone is not a win-back, it is an apology.

Sending to everyone in the segment regardless of balance size. A customer with 40 points expiring, worth nothing redeemable, gets an urgent-sounding email about an amount that was never going to matter to them. The reward-threshold filter in the segment exists specifically to prevent this.

Conflating the points expiry date with a coupon expiry date. If email two follows a redemption made after email one, make sure the copy is warning about the right clock. Points expiry and a redeemed coupon’s own expiry are two separate dates, and mixing them up in an email reads as either wrong or confusing, sometimes both.

Running this flow with points expiry turned off. Points expiry is off by default; if it is not configured, there is no Points Expiring Soon property changing on anyone’s profile and this flow simply never fires. Check the setting before assuming the flow needs debugging.

Measuring whether it works

The flow succeeds if the redemption rate inside the segment (people who redeemed after entering it) beats the redemption rate for the same segment before the flow existed, or beats a holdout group if you can run one. Watch it over a few cycles rather than judging it from one send. If the rolling clock in your loyalty program resets on any activity, not just redemption, a customer who orders again for unrelated reasons also exits the “expiring soon” state, which will look like the flow working even when the email had nothing to do with it. Reading results too early or without accounting for that overstates what the flow actually did.

Where this fits

This is the deep version of one flow from a set of seven; the full list, one flow per Klaviyo loyalty metric, is here. For how the underlying metrics and profile properties work, including Points Expiring Soon itself, see the Klaviyo integration page.

The honest limit

This flow only works if points expiry is configured and if the loyalty tool actually exposes a Points Expiring Soon property to segment on ahead of the expiry event itself. A tool that only sends a single after-the-fact “expired” event cannot support a real win-back, only a post-mortem.

Ten minutes from here to points on live orders

Create an account, install the plugin, connect your store. Free up to 200 orders a month, every feature included, no credit card.

Start free
Featured onLaunched on kind-loyaltyFeatured on EasyLaunchkind loyalty - Featured on Startup Famekind loyalty on Nick LaunchesFeatured on EasyDoFollowFeatured on Findly.toolsListed on MarketingDB