Solution · Multi-location
Run loyalty across locations you own.
Headquarters can operate one business across several clubs and staff teams. The structure must match the loyalty promise customers receive at each location.
- Buyer
- Headquarters
- Business boundary
- One centrally owned partner
- Location boundary
- Club and assigned staff
Short answer
Start with ownership across the locations.
This model fits a centrally owned business whose headquarters buys and owns one installation, hosts and maintains it, configures the business and its clubs, trains location staff, supports customers, and controls customer data. Reward Loyalty can organize programs and staff by club inside one partner. A club owns its cards, vouchers, passes, and staff boundary, so the buyer must inspect any requirement for one shared balance or earn-and-redeem-anywhere behavior before making that promise.
Decision criteria
Define the location promise before configuration.
Central ownership can simplify support and governance. It does not make every balance, card, pass, or voucher portable across clubs.
Ownership test
Use this model when headquarters owns the locations, customer relationship, data policy, program economics, staff standards, and support route.
Program test
Decide whether each location can hold its own program or whether the customer promise requires one balance and reward across the chain.
Brand test
Keep one business identity when the locations share an owner and customer promise. Use separate partners when distinct businesses need isolation.
Buyer fit
Choose central operation for locations under one owner.
This page covers a chain, group, or service network controlled by one headquarters team.
Fits centrally owned locations
Headquarters sets the program rules, funds rewards, controls customer data, defines staff procedure, and owns support for every participating location.
Fits one technical operation
One team or provider can host, secure, update, monitor, back up, and recover the installation for the group.
Choose the franchise model for independent owners
Separate franchisee governance, funding, customer-data rights, and dispute rules need the franchise Solution rather than a central-chain assumption.
Choose partner isolation for separate businesses
Use the multi-business architecture when brands or legal entities need separate business settings, customers, permissions, exports, and reporting.
Location structure
Use clubs for real program and staff boundaries.
A club is part of one partner business, but its loyalty records retain club ownership.
One partner business
The partner holds the shared business identity, customer relationships, program administration, analytics, and business-level configuration for the centrally owned group.
A club for each operating unit
A club can represent a location or unit. Cards, vouchers, prepaid passes, and staff assignments belong to a club, which keeps service actions within the intended operating boundary.
One customer wallet
A customer can hold programs from several clubs and see them in one wallet account. This reduces account duplication without merging the underlying program records.
Shared balance requirement
If the buyer needs one card or balance to earn and redeem at every location, confirm the current supported structure and test it. Plan custom work or another product when club-owned programs do not meet that promise.
Responsibility
Put headquarters in charge of the complete service.
Central control works only when the central team accepts the operating duties.
Headquarters buyer
Buys the license, owns the installation, sets program policy, chooses customer-data roles, approves costs, and controls the customer relationship.
Technical operator
Hosts the application, configures domain and email services, protects access, runs backups, applies updates, monitors jobs, and leads recovery.
Program and training team
Creates the partner and club structure, configures programs, assigns staff, writes location instructions, trains teams, and reviews reports and corrections.
Support route
Location staff escalate program questions to headquarters. Headquarters supplies first-line support to staff and customers, then raises verified application defects through product support.
Implementation
Pilot the hardest location before the whole group.
A representative pilot reveals permission, training, support, and customer-promise gaps.
-
1
Map the ownership and exceptions
List locations, legal ownership, brands, staff roles, program differences, data access, support hours, languages, currencies, and integration needs.
-
2
Choose the partner and club model
Use one partner for the centrally owned business and create only the clubs needed for location programs or staff boundaries. Document why each boundary exists.
-
3
Configure and integrate the pilot
Create the selected program, assign pilot staff, prepare QR and customer content, and scope any POS or commerce connection. Test location attribution and failure handling.
-
4
Run a controlled expansion
Train by role, check customer wording at each location, review corrections and support load, test backups and updates, then add locations in batches.
Day-to-day operation
Keep the location action short and the governance central.
Each role needs a defined route for the normal transaction and the exception.
Customer
Uses one account and wallet, opens the program for the current club, and receives only the earning, reward, voucher, or pass promise the configured program supports.
Location staff
Works within the assigned club, finds or scans the customer, records supported actions, and sends exceptions through the headquarters support route.
Headquarters operator
Reviews club activity, staff use, program economics, customer questions, corrections, campaigns, imports, exports, and location comparisons within the product’s reporting scope.
Technical operator
Monitors the shared installation, integrations, mail, queues, storage, backups, security, and updates. One shared fault can affect every location, so response ownership must be explicit.
Buying checklist
Inspect the cross-location promise line by line.
The most expensive gap is often a customer promise that the chosen structure does not provide.
Program portability
Confirm where customers join, earn, redeem, use passes, claim vouchers, receive achievements, and see history. Test the shared balance requirement with real roles and locations.
Access and data control
Confirm headquarters, manager, partner, and staff permissions; club assignment; exports; privacy requests; retention; and access after a location closes.
Branding and locale
White-label relevance: A supporting benefit. Headquarters can control the installation identity and business presentation, while translations, currencies, dates, and numbers need configuration and review for each market.
Cost and operation
Budget through maintained pricing for the license, then add hosting, email, backups, monitoring, training, support, integrations, source changes, security, and rollout time.
Product and operating limits
Do not promise one chain-wide balance without proving it.
- A shared customer account does not create one chain-wide loyalty balance. Club-owned cards, vouchers, prepaid passes, and staff boundaries must match the public promise.
- Reward Loyalty does not provide managed hosting, location onboarding, staff training, operational support, program consulting, or a ready-made POS connection for every site.
- One partner is a poor fit when locations are separate businesses that need isolated customers, settings, permissions, exports, support contracts, or billing.
- Source access can support a scoped cross-location change, but the operator must design, test, secure, document, and maintain that change through future releases.
Implementation guides
Use current documentation for changing details.
Requirements, interfaces, settings, limits, and release behavior belong in the maintained product documentation.