Three conclusions from this guide
- Evaluate on what has to be true in production, not on the demo. Every claim should come with a definition, a scope and a date.
- Migration is the highest-risk decision in the project and the least examined line in most RFPs. Make the vendor prove it.
- The architect's veto is silent. If a vendor has no public documentation, the shortlist is being decided without a conversation.
Start from the three questions, not the feature list
Loyalty platform evaluations tend to split three ways. Marketing wants to launch a challenge next month without an engineering ticket. IT wants to know what the register does when the platform is slow to answer. Finance wants any balance on the books traced to the rule that created it. Few platforms answer all three convincingly, and the shape of your program decides which weak answer you cannot afford.
A single-brand e-commerce business can wait until tomorrow morning for balances to update. A fuel and convenience operator cannot, because the pump needs an answer in milliseconds and the discount has to land in the right brand's ledger.
The evaluation framework
| Criterion | What to ask | Evidence to require |
|---|---|---|
| Move fast | How does a marketer take an idea to production, and what waits on engineering? | A live configuration session; time from request to production for a typical change; self-service scope |
| Change safely | How does a change reach production, who approves it, what is logged, how is it rolled back? | Environments, versioned configuration, approval workflow, audit trail, rollback demonstrated |
| Operate with certainty | What is the response time at the transaction, what is the availability record, how is throughput proven? | Governed metrics with definitions and as-of dates; named references at comparable scale |
| Migration proof | How are the two systems compared before cutover, on what share of the member base, and what happens to differences? | A parallel-run method; reconciliation on the full base; rollback armed after cutover; migration references |
| Financial controls | Can finance reproduce the liability rollforward from the platform's records? | Point-level lineage, burn-order control, partner settlement outputs, transaction-level exports |
| Governance of AI | What governs an AI-prepared change before it reaches production? | AI operates inside the same approvals, environments and audit as human operators |
| Integration and extensibility | What happens when a requirement exceeds the configuration UI? | APIs, events and batch; a programmable core with versioning; reference integrations |
| Documentation | Can our architects read the API, events and architecture without a sales call? | Public documentation with concepts, API reference, event catalog and reference flows |
| Security and assurance | Which attestations and certifications exist, what do they cover, and who issued them? | Reports and certificates with scope and dates; questionnaire answers from evidence |
| Accountability | Who owns the outcome when the problem is between the product and an integration? | The delivery model: who builds, who implements, who operates in production |
This framework is expanded into thirty scored questions in the RFP template.
How to weight the criteria
Weight by the cost of a weak answer for your program shape. Programs where transactions happen at a physical lane, across several brands, or with partners funding rewards should weight real-time decisions, financial controls and migration proof most heavily. Programs launching for the first time can weight marketer velocity higher, because there is no live ledger to move. Every program should weight governance and documentation, because those decide how the platform behaves in year three, when the people who chose it have moved on.
Where evaluations go wrong
- Scoring the demo
- Demos show the happy path on synthetic data. Ask to see a reversal, a mixed-brand basket, and a rule change moving from stage to production with its audit entry.
- Accepting unqualified numbers
- A member count without a definition, or an uptime claim without a start date and a scope, is marketing. Ask what each number means, over what period, as of when.
- Leaving migration to the SI
- If the platform vendor's migration answer is "your integrator handles that", the risk has been moved, not removed.
- Skipping the architect
- Enterprise architects rarely raise a veto in a meeting. They read the documentation, or find there is none, and the platform drops off the list quietly.
- Confusing AI features with AI governance
- Every vendor will show a copilot. Ask what stops an AI-prepared change from reaching production without a human approval and an audit entry.
A note on how ReactorCX scores
Loyalty Methods built ReactorCX for the programs where the weak answers cost the most: multi-brand, high-volume, financially sensitive, and usually migrating from something. The migration method is on Safe Migration, the financial model on Financial Integrity, and the technical detail in the documentation. Score it against the same table.
Velocity
How long from idea to live rule, and who has to be involved. Ask to watch it, not hear it.
Control
Environments, versioning, approval and rollback. Ask to see a change reverted.
Certainty
What the register does when the platform is slow, and how often that happens.
Migration proof
How a live program moves, and how the two systems are shown to agree before cutover.
Financial integrity
Whether one balance can be taken apart into the rules that built it.