Skip to content

Tiered Membership Design

GadgetSphere wants its best customers — corporate buyers through GSD and repeat smartphone buyers — to get better prices and more points than a walk-in. The product gives you member classes and everything that can read them; it does not give you a tier engine. This page is for the programme owner designing the tiers, and shows a three-class design that works without one.

What a class is

A member has exactly one class, set on the member form, imported from the CSV’s MEMBER CLASS column, or pre-filled for counter-created members by the POS default class (POS_DEFAULT_MEMBERSHIP_CLASS). Nothing in the product reads spend, visits or points to change it. Member Classes and Labels says what the class record holds.

What reads a class

These parts of BigLedger use a member’s class: the Pricebook price-set rule, the Commission Scheme rule, a voucher’s doc-header rule, the birthday-gift schedule’s class list, CP Commerce Admin’s default class and spending limit, and the counter’s default class. Member Classes and Labels: what reads the class says what each does with it. This design leans on the first: a Pricebook price set with a Member Class rule is where “GOLD pays RM 3,040, STANDARD and SILVER pay RM 3,200” and “GOLD earns 2 points per ringgit” live, as a discount treatment and a POINT treatment.

The Member Label rule is different: on the price book the counter calculator ignores it, and on a commission scheme it passes for any member with any label. Put tier logic on the class.

The GadgetSphere design

  1. Three classes: STANDARD on joining, SILVER from RM 2,000 spent in a year, GOLD from RM 5,000.

  2. One price book, selected as the POS default at every branch, with four price sets, each with its own Priority Level: Gold price (Member Class = GOLD, the laptop and smartphone categories, a 5 % discount treatment that sells the RM 3,200 laptop at RM 3,040; priority 30), Gold points (Member Class = GOLD, every item, a POINT treatment 2 per ringgit; priority 20), Silver points (Member Class = SILVER, every item, a POINT treatment 1.5 per ringgit, no member price; priority 15) and Retail points (Member Class = STANDARD, a POINT treatment 1 per ringgit; priority 10).

    The caution that decides this build: only the first treatment on a price set is read. Put the Gold discount and the Gold points on one price set, discount first, and Gold members get the price and no points at all — no message at the till, no error on the bill.

    “Every item” has to be written as a rule. A price set with no Single Line rule matches no line at all — at the till and on the server — so give each points set a Single Line item-code pattern that matches every code, such as .*. Leave it out and none of the three points sets ever awards a point, with no message anywhere.

    A bill line takes one price set, not one of each. The till lines up the price sets that match the member and the item, highest priority first, and uses the first one — for the price and for the points — and reads only that set’s first treatment. So a Gold member’s laptop comes out at RM 3,040 and earns nothing, while the RM 150 earbuds on the same bill earn 300 points. A SILVER member pays RM 3,200 and earns 4,800. The server’s own pass, which fills in points the till left off a line, makes the same choice, so it does not rescue the laptop. That split — Gold price on the big categories, double points on everything else — is the most the book does by itself.

    If Gold must get both on the same laptop, swap the first two priorities (Gold points 30, Gold price 20) and switch on manual promotion selection in POS General. The laptop line then earns points automatically, the cashier applies Gold price from the item’s promotion list, and the points are recomputed on the new price: RM 3,040 earns 6,080. The cost is that no discount in the book applies by itself any more — every one becomes the cashier’s choice, and a missed click is a Gold member charged RM 3,200. Either way, finalise a test bill per class on a laptop and an accessory before go-live, and read each point line.

  3. A monthly review, by a person, not a job: the accounts clerk changes the class of members over the agreed threshold on the member form (Member Classes, Step 4). The API’s transaction-lines query (GET …/membership-points-txn/lines/query, type REWARD) gives each card’s points for the period, but points are not spend: rates differ by class and campaign. Measure the RM 2,000 and RM 5,000 thresholds on sales, or put a points threshold in your terms. (Sales Report’s member-reward-redemption route shows sales rows and no points.)

  4. A birthday gift schedule for GOLD only — 500 points valid for 3 months.

What does not happen

  • No rolling-12-month qualification, no automatic upgrade or downgrade, no grace period, no “lifetime status after five years”, no anniversary reward — the old page’s YAML for these matched nothing in any applet or processor.
  • No “tier multiplier” as a member attribute; the multiplier is a POINT treatment on a price set that has a Member Class rule.
  • No per-class booking priority, complimentary-service counters or communication sequences.
  • No physical card or e-mail is produced when a class changes; the change is a field on the row, recorded in the Audit Trail.

Read next