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 > +

Only Member Name and Phone Number are required. The phone is one box with its own country picker (Malaysia and Singapore at the top), and no company setting makes it optional on this screen, so a walk-in who will not give a number cannot be registered here without one. Member ID, E-mail, Verification Status (it starts as Unverified), Branch and, where your company shows it, Sales Agent are optional.

The card number is made for you, and your company’s settings decide from what. By default it is a random six-digit number. If your company uses the IC or passport number as the card number, an IC / Passport box appears and is required, and that number becomes the card. If it uses the phone number, the phone without the leading + becomes the card. Card numbers must be unique, so under the phone setting a second family member sharing one phone is refused at CREATE; register them with their own number, or decide as a team that the programme is one card per household.

Membership End Date starts at Lifetime, and the box appears only for staff whose role may change end dates, so most people creating members never see it and every member they create is a lifetime member. For a paid annual programme, have someone with that right set the date, or sell the membership as an item at the counter. Where your company runs the follow-on job for membership items, a renewal counted in days moves the end date on by that many days, but one counted in months sets an end date only for a member who has none, and every member created here already has one (Lifetime is stored as a date in the year 9999). That second point is read from the code, not tried: sell one monthly renewal to a test member and look at the end date afterwards.

Card Type is not on this screen. Set it afterwards on the member’s Details tab, where it is a pick-list of your company’s card types (or free text if none are defined) and is not required. In what we read, Card Type is used for filtering, the membership report and exports, and neither pricing nor points reads it. If a tier should change the price or the points, put it in the class (Step 2).

Check the customer link. If you give an e-mail, the screen tries to link the member to the customer record that carries the same address, but it sends the new member without waiting for that look-up to answer, so the link may not be made (read from the code, not tried). Open the new member, look at Customer Name on the Details tab, and if it is blank, pick the customer there.

Press CREATE. 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

Click the member > Point Transaction tab > +

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. If there is no + on the tab, your company has limited point corrections to certain roles; ask your administrator who holds that right.

The form needs a Branch, an Item Code & Name and the Point Adjustment itself; a positive number adds points and a negative one deducts. The branch also decides which company the adjustment is recorded under, so for a group like GadgetSphere pick the branch of the company that runs the programme the points belong to. The item is recorded with the adjustment and nothing else reads it here: agree one item your team always uses for corrections, so they are easy to find later. Remarks / Reason is the only record of why, so write it every time. Reference Number becomes the movement’s description. Display Type decides whether the member sees the movement in their own history (Display) or not (Hidden).

Three fields change more than they appear to:

• Point Currency. Leave it empty and the adjustment is recorded in the default point currency, which may not be the one your members collect at the till. Choose it every time.
• Valid Date From / To. An adjustment that adds points becomes its own batch of points, valid between those dates. Leave them empty and those points never expire. A deduction is taken from the batches that expire soonest first.
• The deduction check. Before saving, the form compares a deduction with the Current Point Balance the Point Transaction tab loaded when you opened the member, for the currency the tab showed at that moment, not the currency you pick on the form. With more than one point currency this can refuse a valid deduction or let through one larger than the balance (read from the code, not tried). So read the balance for the right currency yourself and deduct no more than it. A refused deduction also clears the form, so you type it again.

Each adjustment is saved with the transaction type ADJ and a record of who saved it, which is how an audit tells your corrections apart from points earned at the till.

Where the balance comes from. Current Point Balance is a stored figure: the sum of every active movement for that member in that currency, whatever their dates, recalculated by a follow-on job after each movement is saved. If it has not moved straight after you save, reopen the member. Expired points leave the balance only when the expiry job writes a deduction for them. The Points Expiry tab lists each batch with its start, end and next expiry-check dates; its Balance Amount column shows the batch’s original size, not what is left after redemptions (read from the code, not tried). If the tab still lists a batch whose end date has passed and the balance has not dropped, the expiry job has probably not run for your company: ask whoever manages your scheduled jobs whether it is switched on.

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:

1. Search for them on the Member Listing by mobile number. They are there, with the class you set.
2. Open their Labels tab. The segments you intended are on it.
3. 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

Related documentation