Customer and Member
When a shopper at branch GS-KV-01 says “I’m a member”, the cashier looks up a membership card,
not a customer account. The two are different records, and the difference decides what you have to
create before points can be earned. Nothing more.
The member record
A member is one membership card record. What it holds, in the words the Membership Admin form uses:
| On the form | What it is |
|---|---|
| Card No | The business key, unique per tenant. Every points API call takes it. Generated by the applet’s running number, or taken from the IC / passport or mobile number, depending on Field Settings — and a random six-digit number when none of the three is on |
| Member ID, Referral Code | Two more identifiers; the referral code is what another member enters to name their referrer |
| Member Name, Mobile No., Email, IC / Passport, Date of Birth, Gender | Identity as the loyalty programme knows it — independent of any customer record |
| Member Class | The one tier the member is in (classes and labels) |
| Labels | Any number of tags, linked on the Labels tab |
| Verification Status | UNVERIFIED, VERIFIED, REVIEWED or EXPIRED. A member created at the till stores none, which Membership Admin displays as UNVERIFIED. POS can be set to let only verified members redeem points |
| Member Status, custom statuses | ACTIVE / INACTIVE plus up to two tenant-defined header statuses; labels only |
Join / Start / End Date, or LIFETIME | The membership period, kept as a history of periods; the applet exposes the dates on the Details tab |
| Customer Name | The optional link to a customer entity |
| Branch, Sales Agent | Shown when the tenant switches them on |
Suspensions (a date range with a reason) and the member’s point transactions, point lots, referrals and MLM links are tabs on the same form.
The link to a customer
A member may point at a customer entity, and three things can make the link:
- You pick the customer on the member form — or, if you leave it empty, the backend picks one when the card is saved: the first entity with the member’s phone number, then the first with the member’s e-mail, and if neither exists it creates a customer from the member’s name, IC, phone and e-mail.
- The API’s with customer route — the path an integration or a migration uses — matches the customer by customer code only, creates one if there is none, and writes the member’s name, IC, phone, e-mail and address onto it, overwriting what the customer record held.
- A scheduled job back-fills it:
ENTITY_LINKING_FOR_MEMBER_PROCESSOR(in the Scheduler applet’s processor picker) creates one new customer for each member whose customer is empty. It does no matching, and the customer it makes is named from the part of the e-mail before the@, without the member’s name or IC. It is not a default clock; nothing runs it unless you schedule it.
A member with no customer is still a valid state — points are awarded to the member on the bill,
not to a customer — but the ordinary routes rarely leave one. The Membership Admin form, the
Upload Membership CSV, the counter’s member panel and the API’s plain create all go through step 1,
so a walk-in enrolled at GS-KV-01 comes out with a customer record: an existing one that shares
the phone number, or a new one. The storefront’s create membership without customer option is the route
that leaves a member without one. The customer record
is what the finance side reads — credit terms, credit limit, addresses, tax identity, statement of
account. The card is what the loyalty side reads.
Seen from the customer’s side, Customer Maintenance has a Membership tab (membership plan and points, with the points field permission-gated) and a Payment Config tab that can allow membership point currency as one of the customer’s settlement methods.
Who else creates members
- The e-commerce storefront. CP Commerce Admin’s post-registration configuration can create membership and customer or create membership without customer the moment a shopper registers, with the website’s default membership class. That is how GadgetSphere Online’s sign-ups arrive as members of the same programme the branches use.
- The contact centre. Contact Merging in the Unified Contact Center attaches an inbound contact to a membership card, so an agent chatting with a member sees the card’s history.
- A CSV upload in Membership Admin (Upload Membership), where the class and labels must already exist by code.
- The API — see API reference.
One card, one member
The tables model one member per card. The old version of this page described a customer holding several memberships in several “programs” with separate balances; nothing in the member table, the card controller or the points tables carries a program identifier on the card. What does vary per member is the point currency: one card holds a running balance and a set of lots in each currency it has earned in, which is where the “several balances” idea comes from.
The other direction is looser than it looks: several cards can point at one customer. The phone match in step 1 is the usual way it happens — a second member keyed with a phone number the customer list already holds is attached to that customer. The member API’s query can be filtered by customer and returns every card linked to it, which is the check to run when a customer’s statement shows bills from people you do not recognise.
Related
- Membership Admin — the member form, field by field.
- Point currencies and balances — what the card accumulates.
- Member setup — creating members in the right order.