Skip to content
Registering a Loyalty Member

Registering a Loyalty Member

“Member” here means a customer in your loyalty programme, not a user of BigLedger. If you came looking for staff logins and access control, you want teams and permissions.

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.

Two settings decide whether a new member works the way you expect, and both are hard to put right afterwards:

  • The card-number rule. Pick it before you key anyone, because the card number is the key every points call and every till lookup uses (Member Creation → Before the first member).
  • The company’s member-point setting. At its default, points are awarded on finalised sales orders. Have it set to the document your counter sells on before the test sale in What success looks like (Setting Up the Programme).

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 which customer it linked. If you give an e-mail, the screen looks for the customer with that address but sends the new member without waiting for the answer. When the member arrives with no customer, BigLedger attaches one itself: the first record of any kind with the same phone (a supplier or staff record counts too), else the first with the same e-mail, else a new individual customer made from the member (Member Creation: the customer record does not have to exist first). Open the new member and read Customer Name on the Details tab; if it is a relative sharing the phone, or a new customer where you meant an existing one, pick the right 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; at the till and on a sales document a rule on Member Label is not — it is treated as satisfied, so it widens the rule instead of narrowing it. Only the web store and the OCR receipt processor compare labels (Member Labels: who reads a label). If you want members priced differently at the counter, 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. It is a pause the member does not lose: saving it moves the membership end date out by its duration, and deleting it moves the date back. It does not stop the member earning or redeeming points, and the till treats them as before (Membership Admin: Member Create and Membership Edit). Use it for a member who has asked for a pause. For a member under investigation, the control that stops redemption is the verification status, with the till’s verified-only setting on (Cash Conversion).

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 or label that is not there is skipped while the rest of the file goes in, and the file still ends DONE — the listing shows the file’s status, not its rows, so count the members afterwards. A row with no end date fails the whole file, and a row whose name and mobile number exactly match a live member updates that member.

There is a matching Upload Member Point Transaction for bulk point movements, with its own sample format and a Checking tab that lists its rows.

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

What goes wrongWhat you seeThe fix
Using labels where a class was meantAt the till, price rules keyed on the label apply to everybodyMember Class rules are evaluated; at the till, Member Label rules are not
Uploading before classes and labels existThose rows are skipped and the file still ends DONECreate classes and labels by code first, then count the members
Deleting a member to stop them tradingThe card is marked DELETED; its points lines and Audit Trail stay, but the member is out of useFor a pause, use Member Suspension; to stop redemption, the verification status (Three statuses)
E-Invoice tab left emptyNobody notices until an invoice is neededFill it at registration
A point adjustment with no remarksUnauditableWrite why, every time
Assuming this applet awards pointsIt does notPoints are earned at the counter; this applet configures and corrects
Reading “member” as “user”Confusion about access controlMembers are loyalty customers; staff access is teams and groups

Related documentation

Last updated on