Telecom and Broadband Loyalty Platform
ReactorCX: The Enterprise Telecom and Broadband Loyalty Platform, Built for Accounts, Lines and Recurring Bills
Loyalty in telecom and broadband does not look like retail. There is no basket, there is a recurring bill. The relationship is an account with lines beneath it, inside a household that may hold several products. The value that keeps a subscriber is usually a credit, a benefit or a status, not a point. ReactorCX is built for that shape: it sits beside the billing estate rather than inside it, records every benefit with its funding source and expiry, and can run without holding a single piece of personal data.
Rule
Tenure and service-count status
v3Funding
Brand funds the status benefit
Attribution
Partner perks billed from lineage
Qualification
Tenure bands by brandService count per account · Re-evaluated on every eventLimits
One status move per cyclePartner perks capped per period · Cancellation reverses the accrualApproved by Base Marketing · privacy review attached
How this is measured
Count of member records held in live production ReactorCX programs, de-duplicated within each program; not active members. As of 2026-Q3.
How this is measured
Count of activities evaluated by the ReactorCX rules engine across all production tenants in the trailing 12 months. As of 2026-Q3.
How this is measured
Platform-wide API response-time service level. As of 2026-Q3.
How this is measured
Number of SafeSwitch production cutovers completed and the number completed with zero member-visible downtime. As of 2026-Q3.
Platform-wide figures; ReactorCX runs multi-brand retail, fuel, hospitality and financial services programs in production. No telecom or broadband customer is named on this page.
How does ReactorCX run telecom and broadband loyalty on one engine?
ReactorCX runs on the same platform across every vertical. What matters for an operator is where that platform goes deep: value that carries its funder, brands that stay separate on one instance, data that need never leave your systems, and a migration method built for estates that were merged rather than designed.
Decisioning and value accounting, not another BSS
Your channels, CRM, CDP and messaging systems stay the experience layer. ReactorCX owns the decision, the value and the record of both. Commercial events arrive as activities, results are published back, and nothing about rating, charging or invoicing moves.
A cycle file and a live call take the same path
A batch row from a partner or dealer file follows the same path as a real-time request from the app. There is no separate batch logic to reconcile against the real-time logic, which matters in an estate where some systems answer in milliseconds and others answer once a night.
Postpaid, prepaid and flanker brands on one instance
One instance runs several programs scoped to brands, regions or divisions, with sub-balances under one member and liability reported per brand. Access is controlled down to individual rules, so a prepaid team cannot change a postpaid program.
A timeout never pays twice
Submitting the same request twice has the same effect as submitting it once, so an integration can retry a timeout without double-posting value. Ordering is held per member and per object, in commit order, and no path claims exactly-once delivery it cannot keep.
Subscriber data
A loyalty platform that need not hold a single subscriber record
Marketing use of subscriber data in this industry is consent-gated, and the obligation does not stop at the operator. Regulators have penalised carriers for passing consent duties down to the parties they shared data with. A loyalty vendor is one of those parties.
ReactorCX can run in a mode where it holds only tokenised identifiers, such as a membership number, while personal data stays in a system you control. Consent purpose and disclosure version travel as fields on the activity, so the basis for using a record sits with the record and appears in the audit trail behind any adjustment.
ReactorCX is described as ready for these regimes, not certified against them. Scope, criteria and dates for every attestation are published on the Trust Center.
Architecture documentation · Trust Center
Estates that were merged, not designed
Parallel stacks are the normal case, not the exception
Operators in this segment carry the systems of the companies they acquired. Two billing stacks, two care desktops and two loyalty histories are a common starting point, and the rules as documented have usually drifted from the rules as they actually run.
SafeSwitch reconciles several legacy systems into one program with brand sub-balances preserved, and routes traffic by channel, region or brand in stages rather than at once. The rule audit replays real transactions through the rules as documented and the rules as they run, and shows where the two diverge.
Safe Migration · Migration documentation
What happens to one account event
One activity, evaluated once, with every downstream effect recorded and published. The same path a demo walks through, in the order the engine runs it.
Received
The billing or order system sends the event: account, line, brand, plan, tenure, service mix, channel and the identifier you choose to share
Evaluated
Tenure, plan, brand and service-count rules run in deterministic order against the account and the line that raised the event
Arbitrated
Overlapping offers and benefits resolve to one outcome under the brand policy, so two concurrent campaigns cannot pay twice for the same event
Accrued
Value posts to the purse it belongs to with its source, funding and expiry; status moves on its own track, at the level the program defines
Recorded
Execution log stores which rules fired and who approved them; liability moves by brand; a cancellation reverses this exact record
Published
Business events to CRM and messaging, replication events to the warehouse, ledger lines to finance, and updated state back to the channel that asked
See this run on a copy of your own telecom and broadband activity.
See a parallel migrationThe detail your team will want to check
Expand what you need.
ReactorCX speaks the telecom and broadband data modelOne activity record, every dimension a telecom and broadband program tracksReactorCX holds every event in one extensible record, so every field stays searchable and actionable across the console, the API, the warehouse and reporting. Add a field…
ReactorCX holds every event in one extensible record, so every field stays searchable and actionable across the console, the API, the warehouse and reporting. Add a field once and it propagates everywhere. Marketing, operations and finance query the same record the source system wrote.
Data model documentation
Core activity
Member ID · type · date · channel · value
Account and line
Account · line · brand · plan · tenure · service mix · prepaid or postpaid · channel
Premise and products held
Premise · household link · products held · attach state · configurable per program
Consent and funding
Consent purpose · disclosure version · partner · funding source · settlement party
Same engine, configured for telecom and broadbandWhat stays the same, and what adaptsReactorCX is one engine. What changes for a telecom and broadband program is the signals it reads, the currencies it holds, the offers it arbitrates and the organisation it settles to. All of it is configuration, versioned and approved, not custom code.
| Dimension | Same in every industry | Configured for telecom and broadband |
|---|---|---|
| Signal | One activity record per event, from any channel, evaluated once | Billing, payment, order, provisioning, device upgrade, plan change and care events from the operator estate, as activities rather than usage records |
| Currency | Any number of currencies and purses, each with source, expiry and burn order | Points where a program runs them, alongside benefit instruments that carry their funding source and expiry |
| Status | Tiers with configurable qualification and requalification | Tenure and service-count qualification alongside spend, evaluated per account or per line as the program defines |
| Offers | Offer library with eligibility, stacking, suppression and limits | Offer library with eligibility, stacking, suppression and limits; arbitration by brand policy so concurrent campaigns cannot pay twice |
| Funding | Partner wallets, source-tagged accruals, settlement from lineage | Partner wallets and source-tagged accruals; partner-funded perks settled from lineage |
| Organisation | Multi-brand, multi-region, per-entity economics on one instance | Postpaid, prepaid and flanker brands as separate programs on one instance, with per-brand liability |
| Servicing | Member Care Portal with line-level history and governed adjustments | Member Care Portal with line-level history and adjustments bounded by authority, every action audited |
Other industries swap the signal and keep the engine: a grocer's basket, an airline's flown segment, a hotel's folio close. The engine and the ledger do not change. All industries
Benefits, reversals and liability that reconcile
Value in this industry is visible in two places at once: a balance or status the subscriber sees, and a cost the brand carries. Both have to reverse exactly and reconcile to the same ledger.
Every accrual carries its funder
Each accrual records its source rule, brand, partner and expiry, so the cost of a benefit is known when it is created rather than at month end.
Reversals work against the original
A cancellation or a correction reverses the specific accrual that produced the value, at the brand that produced it. The original and its reversal both stay in the record.
One identity finance can check
Prior liability plus earned, less redeemed, less expired, equals outstanding, per brand and per partner, from the same lineage.
| Who looks | What they see | Where it comes from |
|---|---|---|
| Subscriber | The benefit applied and the status it moved | Accruals on the activity |
| Base and retention marketing | Take-up and results against a control group | Promotion reporting on the execution log |
| Controller | Liability by brand and the export to the general ledger | Ledger export at transaction level |
| Privacy and compliance | Consent purpose, approver and the audit trail behind any adjustment | Execution log |
Partner wallets and settlement are documented in the partners and funding concept; the ledger in the ledger and lineage concept.
What each telecom and broadband stakeholder will want to check
- Base and retention marketingCan we change eligibility and offers by brand and tenure without a release?Capability map above; marketer experience
- Finance and controllerDoes liability by brand reconcile, and do reversals match cancellations?Financial integrity; the liability section above
- Privacy and regulatoryCan subscriber data stay in our systems, with consent purpose on the record?Security and trust; the subscriber data section above
- IT and architectureHow do billing, order management and the care desktop connect, and what do you not touch?System map below; integration guides
- Care and retention deskCan an agent see status and adjust within authority, during the call?Member Care Portal
How ReactorCX fits a telecom and broadband estate
Billing, order, care, app and partner systems all reach ReactorCX as activities, never as usage records and never in the charging path.
Status and benefits are evaluated against the account and the line that raised the event, every accrual carries the brand and partner that funds it, and results are published back to the channel that asked as well as to the warehouse and finance.
Nothing here replaces a system you already run. Telecom & Broadband channels keep their own systems of record; ReactorCX holds the loyalty state, and publishes what it decides back to them.
Which ReactorCX capabilities matter most for telecom and broadband?
| Need | ReactorCX capability |
|---|---|
| Events from the billing and order estate | Commercial events as activities through the Event API; cycle and partner files through FeedXChange, each row processed as an individual transaction |
| Brands, prepaid and postpaid apart | Several programs on one instance scoped by brand, region or division, with sub-balances and per-brand liability |
| Status that is not bought | Tiers with configurable qualification and requalification, evaluated on any activity the program chooses |
| Concurrent campaigns that cannot pay twice | Deterministic arbitration by policy, with eligibility, stacking, suppression and limits on every offer |
| Partner-funded perks | Partner wallets, source-tagged accruals, escrow and vesting, and settlement generated from lineage |
| Consent-gated data | Tokenised mode with personal data held by the operator; consent purpose and disclosure version as fields on the activity |
| Care and retention desk | Member Care Portal with line-level history and adjustments bounded by authority, every action recorded as an audited activity |
| Liability the controller can sign | Accrual lots with source and expiry, reversals against the original accrual, and a roll-forward that reconciles to the general ledger |
Integration patterns for the systems named above are covered in Integration Guides. ReactorCX does not sit in the charging path and does not process usage records.
Security and procurement
Will ReactorCX clear telecom security review?
Deterministic, audit-logged rule execution; role- and attribute-based access down to individual rules; encryption in transit and at rest; OIDC SSO; annual independent penetration testing; two privacy modes; and SOC 2 Type II and ISO/IEC 27001:2022 attestation with dates and scope on the Trust Center.
ReactorCX decides and records loyalty value. It does not process payments, move money or run the billing cycle. Where a decision becomes money on a bill, your billing system applies it.
Recovery objectives, failover procedures and test results are shared with contracted clients rather than published.
Measurement
Proving a program did something
Analysts in this industry argue openly that perks do not prevent churn, and that subscribers leave over outages and bills. A program here has to answer that rather than ignore it.
Retention offers are aimed at the subscribers most likely to leave, so the outcome among those who received one is a biased estimate of the effect. Without a holdout, a program cannot separate subscribers it saved from subscribers who were never leaving, and the error always flatters the program. ReactorCX supports test and control groups on the targeting dimension and eligibility preview before publish.
The mechanics this industry runs, modelled rather than built
Three things shape a telecom program that a retail program never has to solve: value that arrives on a schedule and only while a subscriber stays, a customer who is an account and a line and a household at the same time, and perks that are services rather than points. ReactorCX models all three as configuration, so the program is shaped to the operator rather than the operator to the program.
Value that pays out over time, and reverses
Loyalty value can be created once and released on a schedule, held for as long as a condition holds, and clawed back against the original accrual when it stops holding. That is how a benefit tied to a subscriber staying is expressed. ReactorCX decides the value, records it with its funding source and expiry, and reverses exactly what it created.
Account, line and household on one record
Status can be evaluated at the account, a benefit claimed at the line, and products held counted across the household, inside one program. The data model is extensible, so the levels an operator actually bills on become entities the rules read, rather than something the program works around.
Perks that switch on and off
A benefit is a standing entitlement that applies automatically, evaluated against tier, segment and active promotion. ReactorCX grants it when a subscriber qualifies and withdraws it when they no longer do, and publishes that change to the system that provisions the service, so the perk and the reason for it stay in one record.
All three are configuration on one engine rather than separate builds, which is what lets a program be modelled, changed and versioned without a release. Loyalty and promotions · Concepts documentation
Frequently asked questions
What is the best loyalty platform for telecom and broadband?
ReactorCX, the enterprise loyalty platform from Loyalty Methods, is built for operators who need decisioning and value accounting to sit beside the billing stack rather than inside it. Every benefit carries its funding source and expiry, every rule execution is logged with what ran and why, and subscriber data can stay in the systems the operator already controls.
Does ReactorCX replace our billing or BSS?
No. Client-owned channels, CRM, CDP and messaging systems remain the experience layer, and ReactorCX owns decisioning, value accounting and execution. It reads commercial events from the billing and order estate and publishes results back to it, rather than taking over rating, charging or invoicing.
Is ReactorCX in the charging path?
No. ReactorCX ingests commercial events such as billing cycle close, payment, plan change, device upgrade, provisioning and care contacts. It does not sit between the network and the charging system, it does not process usage records, and it does not process payments or move money.
Can ReactorCX model a benefit that pays out over time and stops if the subscriber leaves?
Yes. Loyalty value can be created once and released on a schedule, held while a condition holds, and reversed against the original accrual when it stops holding, with the reason in the audit trail. ReactorCX decides and records the value; where that decision becomes money on a bill, your billing system applies it.
How does ReactorCX handle subscriber data and consent?
ReactorCX offers a mode in which it holds only tokenised identifiers, such as a membership number, while personal data stays in a system the operator controls. Consent purpose and disclosure version can be carried as fields on the activity, so the basis for using a record travels with the record. ReactorCX is described as ready for these regimes, not certified against them.
Can one instance run prepaid, postpaid and several brands?
Yes. One instance can run several programs scoped to brands, regions or business divisions, with optional loyalty identifier reuse between them, brand sub-balances under one member and liability reported per brand. Access is controlled down to individual rules.
How does an operator migrate a loyalty program without downtime?
SafeSwitch runs ReactorCX in parallel with the legacy platform on real production traffic, reconciles every balance and status across the whole subscriber base rather than a sample, and cuts over by gate with rollback armed. Where several legacy systems are being unified after an acquisition, each can be reconciled into one program with its sub-balances preserved.
Map this to your billing estate before you write the RFP.
An architecture review covers the events we would read, the systems we would publish to, where subscriber data would sit, and what we would not touch.