Best Practices
Each item in this section is a consequence of something recorded on an applet page or in the backend. If the product changes, the item goes with it. The previous version of this section was a loyalty-programme playbook — value-return percentages, tier maturity models, RFM segments, session timeouts, incident-response plans — none of which described a control in the product.
| Page | What it covers |
|---|---|
| Program design | Decisions that map onto records the product has: classes, price sets, point currencies and their validity, vouchers, the company configuration |
| Data management | What a member record holds, how members are created from four places, the CSV uploads, duplicates, and what the wiki says about PDPA |
| Security and compliance | The permissions and settings that actually gate points edits, redemptions and end dates; what is audited; what is not a certification |
| Troubleshooting | Symptom, cause, fix — gathered from the applet pages’ own troubleshooting tables |
The five things most worth knowing before go-live, in one place:
- The company member-point configuration has no screen and defaults to FINAL sales orders. Set it through the company API to the document type you actually sell on, or cash bills earn nothing.
- Points expire per lot, and only if the lot has an end date. A POINT treatment without a Validity Period, an adjustment without a Valid Date To, or a CSV row without one creates points that never expire. Then schedule the elimination processor, or nothing expires anyway.
- Nothing posts. There is no points liability, voucher liability or breakage journal. Reports for Finance come from the balance and transaction queries.
- Member Label rules do not filter — on the price book the counter calculator ignores them, on a commission scheme they pass for any labelled member. Tier logic goes on the class.
- Redemption of a voucher does not check its dates. Schedule the expiry-checking call.