Solution · Multi-brand groups
Run separate brand programs under one group operation.
A corporate group can operate one installation while each consumer brand remains a separate business. Group control does not merge program balances or customer-data access.
- Buyer
- Corporate brand group
- Brand boundary
- One partner per brand
- Member experience
- One account, separate programs
Short answer
Keep group ownership and brand boundaries distinct.
This model fits a corporate group that owns several consumer brands and wants one installation with a separate business boundary for each brand. The group buys and owns the software, appoints the technical operator, hosts and maintains production, sets governance, creates brand businesses, trains brand leads, and supplies shared support. Each brand configures its programs, trains staff, serves customers, and accesses only its business relationship and program records. Administrators retain installation-wide access, while the member controls global account and privacy actions; group and brand controller and processor roles need a written policy. Reward Loyalty supports partner isolation, Networks and managers, a shared member account and wallet, roles, exports, APIs, and webhooks. It does not ship a shared cross-brand points currency, reward liability, or earn-and-redeem-anywhere program.
Decision criteria
Decide what belongs to the group and what belongs to each brand.
One corporate owner can centralize the installation and governance while separate brands retain their own programs, teams, records, and customer promises.
Brand boundary
Use a separate business for each brand that needs isolated settings, programs, staff, customers, exports, reporting, and presentation.
Group governance
Decide which administrators and network-scoped managers can work across brands, and which decisions remain with each brand team.
Customer promise
Choose this model when the shared member account is useful but value remains with the brand that issued it. Reject it when cross-brand currency and settlement are required.
Buyer fit
Use this model for several brands under one accountable owner.
The corporate group must be able to operate production and govern distinct customer propositions.
Fits a corporate portfolio
The group owns the brands or has authority to set the installation, access, customer-data, security, support, and operating policy across them.
Fits distinct brand programs
Each brand needs its own business identity, programs, economics, staff, customer records, communications, exports, and day-to-day decisions.
Choose the multi-location model for one brand
Locations of one centrally owned brand can often stay inside one partner with club boundaries. This page owns the different-brand decision.
Choose an enterprise coalition platform for shared value
Another architecture fits better when customers must earn at one brand and redeem at another with one currency, pooled liability, settlement, and cross-brand campaign orchestration.
Brand structure
Use product boundaries that survive a reorganization.
A visual brand difference is not enough reason for a new tenant; data and operating responsibility are.
Corporate administration
Group administrators control the installation, shared services, security, updates, and the approved creation and closure of brand businesses.
Networks and managers
Networks can group selected brand partners for manager access and internal administration. A manager remains scoped to assigned Networks and does not receive unrestricted system administration.
Separate brand businesses
Each brand partner owns its settings, clubs, programs, staff, customer relationships, activity, exports, integrations, and support tickets within the application boundary.
Shared member account
A customer can use one login and wallet to see eligible programs from several brands. That presentation does not merge balances, histories, vouchers, passes, permissions, or customer ownership across the separate businesses.
Responsibility
Make the group accountable for the shared operation.
Brand autonomy needs a central rule for production, access, incidents, and customer-data disputes.
Corporate buyer
Buys the license, owns the installation, sets brand onboarding and exit rules, approves administrators and managers, and defines the group-wide security and customer-data framework.
Technical operator
Hosts and secures the application, configures domain and email services, runs backups, monitors jobs, applies updates, tests recovery, and maintains shared integrations or source changes.
Brand teams
Configure or approve programs and branding, fund rewards, assign staff, train service teams, fulfil offers, review activity, and supply first-line answers to their customers.
Support and data control
The group defines escalation between brand and central teams. It documents access, controller and processor roles, consent, retention, export, deletion, incident response, brand sale, and brand closure.
Implementation
Pilot two brands that should remain visibly different.
The pilot should prove isolation and group oversight at the same time.
-
1
Map the portfolio
List legal owners, brands, markets, locations, programs, customer terms, staff roles, support routes, languages, currencies, integrations, data access, and planned reorganizations.
-
2
Write the governance model
Define partner creation, network assignment, manager access, brand autonomy, templates, customer-data roles, security, support, exports, incidents, closure, and the no-cross-brand-currency boundary.
-
3
Configure two representative brands
Create separate partners, assign the correct managers, configure distinct programs and presentation, add minimum staff access, and scope any shared integration without weakening tenant identity.
-
4
Test isolation and continuity
Run customer, staff, brand, manager, and administrator journeys; deny cross-brand access; test exports, deletion routing, support, integration failures, backup restore, release checks, and a brand leaving the group.
Day-to-day operation
Centralize platform care, not every brand decision.
The group operation should make shared work dependable while keeping the customer promise legible.
Customer
Uses one account and wallet, selects the relevant brand program, and earns or redeems only under that brand’s configured terms and service workflow.
Brand staff
Works inside the assigned brand and club, records supported actions, fulfils rewards or passes, and sends exceptions to the brand lead.
Brand and group operators
Brand teams review their programs, customers, activity, costs, corrections, campaigns, and support. Group managers review only the brands assigned through Networks and the agreed group operating evidence.
Technical operation
The technical operator monitors the shared installation, mail, jobs, storage, backups, security, integrations, and updates. One shared outage can affect every brand, so incident ownership and communication must be rehearsed.
Buying checklist
Inspect every cross-brand assumption before buying.
The key question is whether the group needs common access or common loyalty value.
Customer value and liability
Confirm where customers join, earn, redeem, use vouchers or passes, and see history. If value must cross brands, define settlement and accounting needs that remain outside the product.
Data, roles, and change
Inspect partner isolation, network manager scope, exports, privacy requests, retention, brand transfer, closure, integrations, and access after a brand leaves the portfolio.
Brand and locale
White-label relevance: A supporting benefit. The group controls installation presentation while each brand controls business and program presentation. Review domains, public URLs, wallet context, email identity, translations, currencies, dates, numbers, and source-change needs.
Source-owned case
Choose source-owned software when the group values deployment and data-location control, inspectable brand isolation, continuity, and maintainable portfolio integrations. Choose another platform when managed operation or shared cross-brand value matters more.
Complete operating cost
Use maintained pricing for the license, then add hosting, email, backups, security, monitoring, group administration, brand onboarding, training, support, integrations, source work, and updates.
Product and operating limits
Do not confuse one member account with one cross-brand program.
- Reward Loyalty does not ship a cross-brand points currency, shared earn-and-redeem rules, pooled reward liability, intercompany settlement, or group-wide campaign orchestration.
- A shared member account and wallet do not merge separate business data, program records, balances, vouchers, passes, histories, exports, or permissions.
- The corporate group must supply hosting, maintenance, security, backups, governance, brand onboarding, staff-training standards, first-line support, legal analysis, and incident response.
- APIs, webhooks, imports, and source access can support scoped group work, but integrations and custom behavior still need owned design, testing, security, reconciliation, and maintenance.
Implementation guides
Use current documentation for changing details.
Requirements, interfaces, settings, limits, and release behavior belong in the maintained product documentation.