Registering a Loyalty Member
A customer wants to join your loyalty programme. By the end of this page they will be registered, in the right tier, carrying the right segments, and able to collect points at the counter. Two minutes each — or one upload for the whole existing list.
Meet GadgetSphere
GadgetSphere Sdn Bhd runs a loyalty programme across its 22 branches. Members collect points at the till, and the programme has three tiers. Today you are registering a walk-in customer at GS-KV-01 who has just bought a phone.
Before you start
Three things have to exist, by code, before a member can be given them:
- Member classes — the tiers. See member classes.
- Member labels — the segments. See member labels.
- Point currencies — what members actually collect, and what a point is worth. Set up under PTS CCY Module and PTS to CCY Config in the same applet.
Step 1: Create the member
Membership Admin > Member Listing > +
| Field | Required? |
|---|---|
| Member Name | Yes |
| Country Code and Mobile No. | Yes, unless your company has turned the requirement off |
| Membership End Date — or mark it Lifetime | Yes |
| Card Type | Yes, if your company has defined card types |
| IC / Passport, Email, Member ID, Verification Status, Branch, Sales Agent | Optional, and some appear only if your company has enabled them |
Save. The member appears in the listing, which shows card number, member ID, name, e-mail, mobile, referral code, date of birth, class, join and end dates, card type, branch and sales agent.
Step 2: Set the class and the labels
Click the member > Details tab for the class; Labels tab for the labels.
A member belongs to exactly one class at a time, and can carry any number of labels. The distinction is not cosmetic:
- The class is what the rest of BigLedger reads. Price-set rules and commission schemes key off member class.
- Labels are for your own segmentation — who to include in a campaign, who joined at which event.
Worth knowing while you are here: a price-book rule on Member Class is evaluated; a rule on Member Label is not — it is treated as satisfied, so it widens the rule instead of narrowing it. If you want members priced differently, use the class.
Step 3: Fill in the e-Invoice details, if you invoice them
E-Invoice tab
Buyer name, ID type and number, TIN, SST registration, tourism tax ID, MSIC code, contact, e-mail and address — or the skip e-Invoice toggle for a member you will never issue one to.
Do this at registration rather than at the moment somebody needs an invoice. It is five fields now and an interrupted transaction later.
Step 4: Adjust points, when you have to
Details tab > Add Point Adjustment
Points are earned and redeemed at the counter — in POS and on sales invoices — and posted by BigLedger. This applet is where you correct them.
| Field | Note |
|---|---|
| Branch | Required |
| Item Code & Name | Required |
| Point Adjustment | Required. Positive adds, negative deducts |
| Point Currency, Transaction Date, Valid Date From / To, Reference Number, Remarks | Fill the remarks in properly — this is the record of why |
| Display Type | Display or Hidden from the member’s own history |
The adjustment is recorded as a manual administrator assignment, which is how an audit tells your corrections apart from points the system awarded.
The Point Transaction tab shows every movement; Points Expiry shows balances with their start, end and next expiry-check dates.
Step 5: Suspending rather than deleting
Member Suspension tab
A suspension takes a start date, an end date, a duration and remarks. Use it for a member under investigation or one who has asked for a pause. It is reversible and it leaves the history intact — which deleting does not.
Loading an existing list
Membership Admin > Upload Membership
Download the Sample Format and fill it in. The columns are: member name, gender, date of birth, country code, mobile number, IC or passport, e-mail, member class, join date, start date, end date, membership status, remarks, and up to three labels.
Member classes and labels must already exist, by code. A row naming a class that is not there fails, and the Checking tab tells you which row and why. Fix and re-upload.
There is a matching Upload Member Point Transaction for bulk point movements, with its own sample format and the same Checking-tab validation.
What success looks like
Two minutes after registering somebody:
- Search for them on the Member Listing by mobile number. They are there, with the class you set.
- Open their Labels tab. The segments you intended are on it.
- Ring a test sale for them at the counter and open their Point Transaction tab. The points have landed — which proves the class, the point currency and the till are all connected.
Common mistakes
| What goes wrong | What you see | The fix |
|---|---|---|
| Using labels where a class was meant | Price rules keyed on the label do nothing | Member Class rules are evaluated; Member Label rules are not |
| Uploading before classes and labels exist | Rows fail validation | Create classes and labels by code first |
| Deleting a member to stop them trading | Their history goes too | Use Member Suspension, or set the status |
| E-Invoice tab left empty | Nobody notices until an invoice is needed | Fill it at registration |
| A point adjustment with no remarks | Unauditable | Write why, every time |
| Assuming this applet awards points | It does not | Points are earned at the counter; this applet configures and corrects |
| Reading “member” as “user” | Confusion about access control | Members are loyalty customers; staff access is teams and groups |