Buyer guide · Tiers
Design loyalty tiers around real repeat behavior.
Status should reward the loyalty the ledger already shows. Set thresholds from your own member distribution, price the multiplier before promising it, and decide how status changes before the first upgrade email.
- Qualification
- Lifetime points, spend, or purchases
- Core benefits
- Points multiplier and tier vouchers
- Evaluation
- Checked after every transaction
Short answer
Design tiers members can reach.
Add membership tiers when regulars already return and you want to reward the difference. Qualification uses lifetime points, recorded spend, or purchase count; a member reaches a tier by meeting a configured threshold and keeps the status unless you restructure the levels or correct the transactions behind it. Set thresholds from your own transaction data, price the points multiplier as a higher earn rate you will fund on every purchase, and reserve select vouchers for upper tiers. Publish only levels you can afford at full uptake.
Decision criteria
Decide whether tiers earn their complexity.
Tiers add a second promise on top of the earning rule. Take them on when repeat data supports the thresholds and the margin can fund the benefits.
Whether tiers fit
Skip tiers when visits are rare or the program is new. Status works when a regular can reach the second level within a believable number of purchases and the top level stays scarce.
Qualification metric
Pick the measure that matches the behavior you want to reward: lifetime points for spend-linked earning, recorded spend for basket value, purchase count for visit frequency. A member qualifies by meeting any threshold you set on a tier.
Benefit budget
A multiplier raises the points you owe on every future purchase at that tier. Price it against the reward threshold before publishing, and keep the top tier affordable with every eligible member inside it.
Structure
Set thresholds from the ledger, not from examples.
Your own member distribution makes better tier borders than a copied bronze-silver-gold table.
Read the distribution first
Aggregate the transaction history export per member to see lifetime points and spend. Natural gaps in that distribution mark defensible borders; a threshold no real member is near motivates nobody.
Keep the base level at zero
The lowest active level is the automatic starting point and needs no thresholds. Members see a tier in the wallet after they earn their first points, so the base level costs nothing to publish.
Use three or four levels
Each added level needs a distinct believable benefit and enough members to matter. When one tier holds almost everyone, merge levels or move a border instead of inventing a new perk.
Design for the club, not one card
Tiers operate per club and cover every loyalty card in it. A member holds one status in each club you run, so thresholds should reflect combined activity across that club's programs.
Economics
Price the multiplier before you promise it.
These numbers show the method. Replace them with your own card values and margins.
Multiplier cost
Illustrative example: a card pays 1 point per currency unit and a reward threshold sits at 500 points. With a 1.5 times multiplier, a member reaches the reward after about 333 units of spend instead of 500, so reward cost per qualifying member rises by about half. Fund that from the extra visits the tier should create, and check the assumption after launch.
Ceilings still apply
A card's maximum points per purchase applies after every multiplier, tiers and bonus hours included. Use the ceiling to keep one large basket from converting into an outsized points grant.
Tier-exclusive vouchers
A voucher targeted at a tier is delivered to eligible members and stays theirs even when status later changes. Treat each tier voucher as a committed cost for everyone who ever reaches the tier, and give it dates or usage limits.
Not everything multiplies
Achievement rewards pay their configured points without tier multipliers, and online store orders earn at the card's normal rate. Check which earning paths multiply before promising members more points on everything.
Operating policy
Decide status changes before the first upgrade email.
The system evaluates tiers after every transaction. Your policy decides how the changes feel.
-
1
Write the downgrade policy
Status rests on lifetime activity, so members do not lose a tier by redeeming points or pausing visits. A downgrade happens when you deactivate or restructure levels, or when staff correct the transactions behind the status. Decide how you will honor existing status before tightening a threshold.
-
2
Configure the messages
Tier upgrade and downgrade emails are separate per-club switches. Keep the upgrade message on, and decide whether a demotion after a restructure deserves an email or a quieter explanation at the counter.
-
3
Give staff one sentence per level
The member's points history marks multiplied rows with a tier badge, so customers can ask why two visits earned different points. Staff should be able to state each level's benefit without a manual.
-
4
Review the distribution on a cadence
Analytics show a member count per tier. Check it after launch, move a border when the top level fills with everyone, and extend the observation window before calling the structure proven.
Product and operating limits
Product boundaries that shape the design.
- Each club runs one tier ladder that covers all its loyalty cards. Reward Loyalty does not run separate tier systems per card or share tier status across different businesses.
- Status does not expire on a calendar by itself. Lifetime totals only fall when transactions are corrected or removed, so a spend-it-or-lose-it status year is not a built-in behavior.
- The product multiplies points earning and can reserve vouchers per tier. Perks that live outside the software, such as priority service or early access, need a staff routine to fulfil.
- The points multiplier applies to loyalty card earning. Stamp progress and prepaid pass uses do not multiply, and voucher benefits reach a tier only through tier targeting.
Implementation guides
Use current documentation for changing details.
Requirements, interfaces, settings, limits, and release behavior belong in the maintained product documentation.