Solution · Shopping centres
Run tenant loyalty programs under one centre operation.
A shopping-centre operator can run one installation for separate tenant businesses. The centre owns the platform operation; each tenant owns its program and service routine.
- Buyer
- Shopping-centre operator
- Business boundary
- One partner per tenant
- Customer promise
- Separate tenant programs
Short answer
Separate the centre operation from each tenant program.
This model fits a shopping-centre operator that buys and owns one installation for separate tenant businesses. The centre team or its technical provider hosts and maintains the application, creates tenant businesses, governs centre presentation, trains tenant leads, and supplies first-line support. Each tenant configures or approves its programs, trains staff, supports its customers, and accesses only its business relationship and program records. Administrators retain installation-wide access, while the member controls global account and privacy actions. The parties must contract their controller and processor roles. Reward Loyalty supports isolated business records, manager groups, customer wallets, staff roles, a public listing, APIs, and webhooks; it does not create a shared currency or automatic cross-tenant earn and redeem.
Decision criteria
Choose the tenant promise before the platform structure.
A centre-wide identity can sit above separate business programs, but it does not create shared points, shared rewards, or automatic property-system connections.
Tenant relationship
Confirm that the centre can contract, onboard, govern, and support participating tenants without taking over each tenant’s reward economics or customer service.
Program promise
Choose separate tenant programs when customers may use one account but earn and redeem only under the rules of the business that issued the value.
Operating capacity
Name the centre team or provider responsible for infrastructure, releases, incidents, tenant onboarding, first-line support, and the centre-level data policy.
Buyer fit
Use this model when the centre will operate the shared layer.
The buyer is the property or place operator, not an individual retailer looking for its own loyalty card.
Fits a centre with an operator team
The shopping-centre operator can own the installation, tenant agreement, service standard, support route, brand policy, and technical suppliers.
Fits independent tenant programs
Tenant businesses want their own cards, stamps, passes, vouchers, staff access, customer records, and program economics inside a shared customer experience.
Choose another approach for one shared currency
A coalition platform fits better when customers must earn the same value at one tenant and redeem it at another, with shared liability and settlement.
Choose a property CRM for property automation
A mall CRM or specialist platform fits better when car-park identity, footfall sensors, concierge work, lease systems, media inventory, or automatic tenant sales feeds are central requirements.
Centre structure
Model the property, tenants, and customer view separately.
The structure should follow permission and customer-data boundaries rather than the floor plan alone.
Installation and administration
The centre operator controls the installation, domain, mail service, shared settings, backups, updates, security, and administrator access.
Networks and managers
A Network can group selected tenant partners for manager access and internal administration. Networks are not visible customer categories and do not merge tenant data.
Tenant businesses and locations
Create a separate partner for each tenant business that needs isolated settings, programs, staff, customers, exports, and support. Clubs can represent real location or program boundaries inside that tenant.
Customer discovery
The optional public listing presents businesses and programs with homepage permission. Prior approval needs controlled onboarding, disabled self-registration, or a review step; when self-registration is open with Public Listing active, a new partner can receive publishing permission and the operator must monitor and revoke it when necessary.
Responsibility
Put every service question with an owner.
Tenants and customers need one clear escalation route even when several organizations share the operation.
Centre operator
Buys the license, owns the installation, contracts with tenant businesses, sets platform policy, appoints administrators and managers, and defines the centre-level customer relationship.
Technical operator
Hosts and secures the application, configures domains and email, runs backups, monitors jobs and storage, applies updates, tests recovery, and investigates incidents.
Tenant businesses
Configure or approve program rules and branding, fund rewards, assign staff, train counter teams, fulfil the offer, correct transactions, and answer customer questions about their programs.
Customer data and support
The parties document access, controller and processor roles, consent, retention, exports, deletion, incidents, and tenant exit. The centre supplies first-line support for the shared service; product support remains within the maintained terms.
Implementation
Pilot the tenant with the hardest operating rhythm.
A varied tenant mix exposes permission, service, and integration gaps before the centre makes a broad promise.
-
1
Write the operating charter
Define eligibility, tenant onboarding, program approval, branding, customer-data roles, support hours, incidents, exports, offboarding, and the no-shared-currency boundary.
-
2
Prepare the installation
Configure infrastructure, domain, mail, scheduled work, queues, storage, backups, monitoring, administrator access, and an update and recovery procedure.
-
3
Create the centre and pilot tenant
Set installation presentation, create the tenant partner and required club, configure one useful program, assign scoped staff, and choose controlled onboarding or a publication-review routine before enabling discovery.
-
4
Rehearse normal and failed journeys
Test joining, earning, redemption, corrections, wallet presentation, staff escalation, a tenant export, an unavailable integration, tenant closure, backup restore, and release checks before expansion.
Day-to-day operation
Keep customer service with the business that made the promise.
The shared installation should shorten access without hiding responsibility.
Customer
Uses one member account, discovers participating businesses when the operator publishes them, opens the selected tenant program, and presents the relevant wallet or code at that tenant.
Tenant staff
Finds or scans the customer, records the supported loyalty action inside its assigned business and club, fulfils rewards, and escalates corrections through the tenant lead.
Centre and tenant operators
The tenant reviews its customers, programs, staff activity, corrections, costs, and support. The centre reviews shared service health, participation, manager access, publication, and agreed aggregate operating evidence.
Technical routine
The technical operator monitors infrastructure, mail, queues, storage, backups, integrations, security, and updates. API or webhook connections need owned mapping, credentials, logs, reconciliation, and failure handling.
Buying checklist
Inspect the gaps hidden by a centre-wide headline.
The right product depends on the exact relationship among the centre, tenants, and customers.
Program and data boundary
Confirm whether value stays with the issuing tenant, which organization can view each record, how customer requests are handled, and what happens when a tenant leaves.
Brand and communication
White-label relevance: A supporting benefit. The centre can configure installation identity while each tenant controls business and program presentation. Inspect domains, public URLs, wallet context, email identity, templates, and any source work needed for a deeper place brand.
Integration and reporting
List required POS, commerce, parking, property, CRM, footfall, and reporting connections. Reward Loyalty APIs and webhooks are integration surfaces, not automatic connectors or a property analytics layer.
Source-owned case
Choose source-owned software when deployment and data-location control, inspectable integration boundaries, and maintainable centre-specific changes justify running production. Choose a managed platform when the centre cannot own that operation.
Complete operating cost
Use maintained pricing for the license, then add hosting, email, backups, monitoring, security, tenant onboarding, training, first-line support, integrations, custom work, and update maintenance.
Product and operating limits
Do not sell a coalition program the product does not run.
- Reward Loyalty does not ship a shared currency, cross-tenant earning and redemption, coalition settlement, pooled reward liability, or cross-business campaign engine.
- The public listing is an optional discovery surface, not a mall CRM, tenant portal, car-park system, footfall platform, media product, or automatic approval workflow. With open self-registration, the operator must monitor publishing permission.
- The centre operator must supply hosting, maintenance, security, backups, tenant onboarding, training governance, first-line support, data-role agreements, and incident response.
- Source access can support scoped property or brand work, but the operator owns design, integration, testing, security, documentation, and maintenance through later releases.
Implementation guides
Use current documentation for changing details.
Requirements, interfaces, settings, limits, and release behavior belong in the maintained product documentation.