Loyalty Program Software: Buy for Requirements, Not Features

The short version: Loyalty program software should pass your mandatory workflows and financial controls at an acceptable three-year cost. Score observed execution, reconcile the pilot ledger, verify complete exports, then force integration failures before signing.

Key takeaways

• Build a 100-point scorecard around 5–10 workflows tied to revenue, expected loss, frequency, or operator time.
• Require every mandatory financial and security control to pass; use weighted scores only to rank survivors.
• Compare 36-month cost, including implementation, usage, staff time, messaging, migration, and exit work.
• Reconcile the full pilot population when feasible; random spot checks cannot reliably expose rare or clustered defects.
• Test 3–5 end-to-end scenarios, including retries, refunds, suppression, exports, and forced failures.

Score loyalty program software against real workflows

Feature grids reward vendors for accumulating boxes. They do not show whether a refund reverses points correctly or whether support can repair an account without corrupting the ledger. Start with 5–10 workflows used by customers, operators, finance, and service teams.

Assign 100 total points using company-specific exposure. Weight each workflow by transaction frequency, revenue affected, plausible financial loss, customer harm, and weekly operator time. One workable starting allocation is 20 points for earn and refund accuracy, 15 for redemption, 15 for liability reporting, 15 for service adjustments, 10 each for targeting, suppression, and exports, then 5 for permissions.

Define the trigger, expected ledger entries, customer message, operator action, error state, and recovery path for every workflow. Score what the vendor demonstrates in your scenario, not a claim that the feature is supported. Require every mandatory control to pass; rank the remaining vendors by weighted score and three-year cost rather than using an arbitrary aggregate cutoff.

The classic failure: an 80-feature checklist lets cosmetic features offset a broken reversal flow. They are not substitutes. A theme editor cannot repair duplicated points after an order refund.

Calculate three-year cost, not subscription price

Model 36 months because implementation work, usage tiers, migrations, and recurring administration rarely appear in the headline price. Include subscription fees, transaction or member charges, email and SMS, integration work, premium support, sandbox access, data migration, internal administration, and exit assistance.

Run low, expected, and high cases for active members, monthly transactions, messages, and redemptions. Price internal work at a loaded hourly cost. Ten operator hours per week equals roughly 1,560 hours over three years, before holidays or volume growth.

Keep platform cost separate from reward economics. A 2% earn rate on $5 million of eligible sales issues $100,000 of face value before redemption and expiration assumptions. Contract treatment of unused points, vendor-funded rewards, expiration, and breakage affects cash planning and accounting.

Price the pilot from required vendor hours, environments, integrations, migration volume, and support coverage. Set its duration from the cycles the test must observe. A 30–45 day window can fit routine purchase, refund, messaging, and reporting tests, but it is too short when acceptance depends on quarterly tiers or longer expiration rules.

The classic failure: a $2,000 monthly platform appears cheap while requiring weekly CSV repair, custom middleware, and paid escalation. Put every recurring manual task into the cost model before comparing licenses.

Test the ledger and exports across the full pilot population

Points require ledger discipline. Opening balance plus earns, adjustments, and reversals minus redemptions and expirations must equal closing balance for every account and for the aggregate program. Arithmetic, duplicate detection, referential integrity, and row-count comparison belong in queries or deterministic rules, not operator judgement.

Test partial and full refunds, negative balances, delayed events, duplicate delivery, retries, expired points, reinstatement, account merges, and manual adjustments. Every mutation needs a timestamp, reason, source event, actor, and immutable identifier. Finance should reproduce period-end balances without a vendor-built private report.

Reconcile every pilot ledger event when volume permits. Compare source-event counts, ledger-entry counts, unique identifiers, control totals, and closing balances. Test every forced retry, timeout, refund, import, and merge because duplicate defects cluster around those mechanisms; a random sample may never touch them.

If full-population reconciliation is impractical, define the defect rate the sample should detect and the required confidence before sampling. Under independent random sampling, detecting a 0.1% defect with about 95% probability requires roughly 2,995 observations. Then stratify by event type, integration, day, refund state, latency, and retry status; report exceptions against the denominator in each stratum.

Demand exports for customers, accounts, transactions, rewards, consent, tier history, expiration dates, and source references. Verify fields including customer_id, transaction_id, source_order_id, timestamps, currency, and status. Compare complete export row counts and control totals with the application, then reconstruct balances in your warehouse or spreadsheet.

The classic failure: “100% of sampled events reconciled” sounds conclusive without sample size, selection method, population coverage, or a detectable-defect target. A clean sample of 100 has only about a 9.5% chance of finding an independently distributed 0.1% defect. Use the control framework in Loyalty Points Liability: Build Controls Before Campaigns.

Force integrations and recovery paths to fail

An integration badge proves that two systems exchanged something. Test 3–5 production-like scenarios covering enrollment, purchase and earn, redemption, refund or cancellation, and lifecycle suppression. Record expected events in every system, acceptable latency, retry behavior, failure ownership, and operator recovery.

Financial events should reconcile exactly. Set marketing latency from the business deadline: a suppression must arrive before the next scheduled send, not within an arbitrary vendor benchmark. Force one timeout, one duplicate delivery, one missing identifier, and one permission failure; confirm idempotency, alerting, recovery, and audit history.

Use representative products, customer states, returns, consent records, and transaction volumes. Synthetic data covers destructive edge cases safely. If real customer data enters a vendor environment, document the disclosed identifiers, purchase history, balances, and consent fields, plus storage location, access, retention, and deletion terms.

Define acceptance before configuration starts: all mandatory controls pass, all pilot ledger events reconcile or meet the documented sampling design, required export fields are complete, forced failures recover correctly, and operator time stays below your cost-model ceiling. Routine CSV patches count as failed automation.

The classic failure: a vendor-led happy-path demo proves enrollment, then launch exposes missing refund reversals and promotions sent during service disputes. Define that second control with Lifecycle Suppression Rules: Stop Marketing Through Service Failures.

Frequently asked questions

How many vendors should make the shortlist?

Score 4–6 vendors from documented evidence, invite 2–3 to scripted workflow demonstrations, then pilot the highest-ranked candidate that passes every mandatory control. Pilot a second vendor only when scores and three-year costs remain materially close.

Which conditions increase migration risk?

Missing transaction history, unstable customer identifiers, undocumented expiration rules, duplicate accounts, and unreconciled balances increase cutover uncertainty. Profile each defect as both a count and percentage of its relevant population before migration.

When should a company build instead of buy?

Build when distinctive loyalty logic creates enough economic value to justify continuing ownership of the ledger, security, support, compliance, and migrations. Buying transfers baseline product maintenance to a vendor; custom integrations and company-specific rules remain your responsibility.