CRM Star Reward
Loyalty System

Business Context & Problem

The school runs a Star Reward loyalty programme: supervisors award stars to students for behaviour, participation and achievement, and the school turns accumulated stars into certificates and prizes that keep students motivated to learn (a Starbucks-style loyalty loop, applied to education). My remit on XeerSoft Cloud ERP was to help design, build, harden and roll out the system that runs it: the Commendation workflow, rank tiers, parent notifications over LINE, and a bulk Excel import so staff can award stars at school scale.

I worked as the Business Analyst / Implementation Consultant: shaping requirements and the functional spec with the XeerSoft development team, designing the import standard every staff member now uses, then leading 5 iterative UAT cycles that caught a critical silent-failure defect before launch. The system went live for the January term and rolled out to 100+ staff school-wide.

My Role & Accountability

The programme lives inside a School Management workspace on XeerSoft Cloud ERP. I worked across two modules: Activity (the Star Reward / Commendation engine) and a companion Leave & Online Learning module, with the Commendation list as the daily driver for every supervisor.

The Commendation List is the heart of it: a searchable student roster where any supervisor finds a student, opens the commendation panel, and awards stars in seconds. Below is a faithful recreation of that screen (student data anonymised):

Solution Design · Recognition Loop

A commendation is never just a number. Awarding stars also writes the reason, notifies the student and their parent over LINE, and re-computes the rank — closing the loop between the classroom and home. Each message has two LINE targets (student + parent), and delivery is tracked per target.

Every commendation is auditable as a message record: who sent it, how many stars, the message, and whether each LINE target was delivered. Recreation below:

Lifetime stars roll up into rank tiers. Ranks are what the school recognises at assembly and converts into certificates and prizes, so the tier ladder is the motivation engine of the whole programme:

Note: Bronze → Silver → Gold → Platinum is the live rank ladder; lifetime stars roll a student up the tiers, and the school recognises each tier with certificates and prizes.

Solution Design · Bulk Star Import

The feature I'm most proud of designing. Awarding stars one student at a time is fine for a single class, but at school scale a supervisor might log hundreds of stars after an event, a term, or a competition. Clicking ＋ on each student, one by one, doesn't scale. So I designed a single standard Excel format that every staff member uses to import stars in bulk — straight into the Cloud ERP.

The win of a single standard format is consistency: every supervisor across the organisation prepares the file the same way, so imports are predictable and validatable. Columns, types and which fields are required:

One row = one star. A student's star total is the number of rows carrying their Email (the match key); Reason categorises each star (Assignment · Q&A · Engagement · Activity) while Year and Class carry the curriculum context. Above, student.a earns 2 stars (2 rows) and student.c earns 2 Activity stars. Every field is required; emails anonymised here.

How the import runs end-to-end once the file is uploaded:

Live Import Simulation

An interactive model wired to a representative class roster (anonymised). For each row pick a Year → Track → Class → Student (Year 8–9 have no track; Year 10 splits Science / Business; Year 11–13 split into the five tracks) and the student's e-mail auto-fills; set the star count and the reason, then run Validate & Import. Rows are grouped by student e-mail and each balance & rank updates live (saved in your browser) — the specified behaviour I designed, not the proprietary XeerSoft UI.

Validation Risk · Critical Defect

Validation Outcome · Build Cycles

I structured UAT into 5 build cycles, each with explicit entry criteria, test scenarios, and exit gates. The defect log was the central artifact: every defect tracked from OPEN → IN-DEV → RETEST → RESOLVED with reproduction steps, severity, and regression test status.

Cycle	Total Defects	Go-Live Blockers	Regression Count	Reduction %
Cycle 1	16	7	0	baseline
Cycle 2	12	2	5	▼ 25%
Cycle 3	12	2	2	▼ 25%
Cycle 4	10	0	2	▼ 37.5%
Cycle 5	10	0	1	▼ 37.5%

Validation Evidence · Defect Log

The central UAT artifact: every defect tracked with ID, area, severity, the cycle it surfaced in, and status. DEF-001 (the silent bulk-assign failure) was the entry blocker; the rest span the validation scope below.

XeerSoft Module Flow

The loyalty process as built in the XeerSoft CRM module: module → function paths.

#	Process Step	XeerSoft Function
1	Teacher assigns stars (multi-select)	Loyalty › Bulk Assign
2	Update per-student balance	Loyalty › Star Balance
3	Log every transaction	Loyalty › Transaction Log
4	Student views balance & history	Student Portal › Balance & History
5	Redemption + voucher validation	Loyalty › Redemption / Voucher

Functional Spec & Data Model

The logical entities I specified for the loyalty module in the FSD: field design defined by me, physical implementation by the development team.

Entity: Student Star Balance	Type	Description
Student ID (key)	Char(10)	Unique student identifier
Branch (key)	Char(4)	1100 / 1200 / 1300
Academic Year	Char(4)	e.g. 2024 / 2025
Current Balance	Dec(7,0)	Stars available now
Lifetime Earned	Dec(7,0)	Total ever earned
Total Redeemed	Dec(7,0)	Total ever redeemed
Last Updated / By	Date / Char	Audit of last change

Entity: Star Transaction Log	Type	Description
Log ID (key)	Numeric(10)	Auto-increment
Student ID (key)	Char(10)	Student reference
Action	Char(1)	A = Assign · R = Redeem
Stars	Dec(5,0)	Stars in this transaction
Reason	Char(50)	Teacher’s reason
Assigned By / Timestamp	Char	Who & when

Functional Spec & Fix Logic · DEF-001

My defect report specified the corrected expected behaviour for the bulk-assignment routine: it must iterate over every selected student, not stop after the first.

// FSD-P3-02 · DEF-001 corrected behaviour: iterate ALL selected students FUNCTION assign_stars(selected[], stars, reason, user): FOR EACH student IN selected: // defect stopped after the 1st record bal = find_balance(student, current_year) IF bal not exists → create_balance(student, stars) ELSE → bal.current += stars; bal.earned += stars write_log(student, action = A, stars, reason, user) COMMIT all updates atomically // all-or-nothing

Live Spec Simulation

An interactive simulation that runs the FSD logic above directly in your browser: it reproduces the specified behaviour I designed, not the proprietary XeerSoft UI.

Validation Scope

Beyond the bulk assignment fix, UAT validated:

Measured Results

The measurable result was a controlled UAT burn-down rather than a lucky launch. Across 5 build cycles, I tracked 60 defects, drove go-live blockers from 11 to 0, managed 10 regressions, and reached zero critical post-launch incidents. The blocker trend moved 7 → 2 → 2 → 0 → 0, with defect reduction up to 37.5%.

Tools & Deliverables

Consultant Takeaway

The biggest takeaway: UAT isn't just confirming what works: it's hunting for what fails silently. The bulk-assignment bug would have been invisible in production for months because there was no error message. Finding it required deliberately testing the edge case (multi-student selection) rather than the happy path (single student). Every UAT plan I write now starts with "what could fail without anyone noticing?"

The second lesson was about design for scale: a feature that works for one user can still fail an organisation. Awarding stars one click at a time was correct but unusable at 100+ staff, so the real win was the one standard import format everyone follows — turning a per-click chore into a single, validated, auditable upload. Good ERP work is as much about the standard you set as the screen you build.