Solution · Business districts
Give district businesses a shared front door, not a shared currency.
A district or downtown network can operate one installation and curate participating businesses. Each business keeps its own program, staff routine, and customer-data boundary.
- Buyer
- Business district operator
- Member boundary
- One partner per business
- Shared layer
- Place identity and discovery
Short answer
Give independent businesses one operated entry point.
This model fits a business district, downtown partnership, place-management organization, or member network that operates one installation for participating businesses. The district buys and owns the software, hosts and maintains it, creates member businesses, governs publication, trains business leads, and supplies first-line support. Each business configures or approves its programs, trains staff, supports customers, and accesses only its business relationship and program records. Administrators retain installation-wide access, while the member controls global account and privacy actions; district and business controller and processor roles require an agreement. Reward Loyalty supports isolated partners, Networks and managers, customer wallets, staff roles, public discovery, APIs, and webhooks. It does not ship a coalition currency or cross-business earn and redeem.
Decision criteria
Choose a district network or a coalition currency.
One place identity can help customers discover separate business programs. It does not turn those programs into transferable district money.
Governance fit
Confirm the district can contract with participating businesses, operate the shared service, set publication and support policy, and manage entry and exit fairly.
Customer promise
Use separate business programs when the district wants discovery and one member account without shared loyalty value. Choose another platform when coalition currency is the requirement.
Operating capacity
Name who owns infrastructure, security, updates, business onboarding, training standards, first-line support, data-role agreements, incidents, and long-term funding.
Buyer fit
Use this model when the district will operate more than a campaign.
A place-marketing idea becomes software operation once businesses and customers rely on it.
Fits an accountable district body
A business improvement district, downtown partnership, association, or place operator can own the installation, contracts, shared brand, curation, support, and technical suppliers.
Fits independent business programs
Participating businesses want separate points, stamps, passes, vouchers, staff, customer records, exports, economics, and service decisions.
Choose a promotion Guide for a temporary campaign
A short district promotion may need landing pages, vouchers, email, or event operations rather than a permanent multi-business loyalty platform.
Choose a coalition platform for shared currency
Another architecture fits better when every participant must issue and accept the same value, fund a common liability, settle across merchants, and reconcile a shared ledger.
Network structure
Keep governance, discovery, and business data in separate layers.
The district can operate the front door without opening every business record to every participant.
District administration
The operator controls the installation, domain, mail, administrators, business approval, shared presentation, backups, updates, security, and service policy.
Networks and managers
A Network can group participating partners for assigned manager access. It is an internal administration boundary, not a customer-facing category or a way to merge business data.
Participating businesses
Create a separate partner for each independent business that needs isolated settings, programs, staff, customer relationships, exports, integrations, and support tickets.
Public listing
The optional listing shows programs with homepage permission. Prior district approval needs controlled onboarding, disabled self-registration, or a review step; with self-registration open and Public Listing active, a new partner can receive publishing permission and the operator must monitor and revoke it when necessary.
Responsibility
Write the district service agreement before onboarding.
Independent businesses need a stable answer for support, data access, and program ownership.
District operator
Buys the license, owns the installation, appoints administrators and managers, sets participation and publication rules, trains business leads, and supplies first-line support for the shared service.
Technical operator
Hosts and secures the application, configures domain and email services, runs backups, monitors jobs and storage, applies updates, tests recovery, and maintains integrations or source changes.
Participating businesses
Configure or approve programs and branding, fund and fulfil rewards, assign and train staff, record accurate activity, correct errors, and answer customer questions about their offers.
Customer data
The district and businesses document controller and processor roles, access, consent, retention, exports, deletion, incidents, support evidence, and what happens to records when participation ends.
Implementation
Pilot businesses with different service rhythms.
A mixed pilot shows whether the district policy is clear enough for independent teams.
-
1
Define the operating charter
Set participation, publication, program approval, customer-data roles, staff standards, support hours, incidents, exports, offboarding, funding, and the no-coalition-currency boundary.
-
2
Prepare the place platform
Configure infrastructure, domain, mail, scheduled work, storage, backups, monitoring, security, update procedure, place identity, managers, and the public-listing policy.
-
3
Onboard a varied pilot
Create separate partner businesses, configure one supportable program per participant, assign minimum staff access, and use controlled onboarding or a publication-review routine before promoting the directory.
-
4
Rehearse service and exit
Test discovery, joining, earning, redemption, corrections, wallet context, support, exports, an unavailable integration, a business leaving, backup restore, incident communication, and an update.
Day-to-day operation
Keep each business responsible for the offer it makes.
The district runs the shared service while frontline value stays local.
Customer
Uses one account, finds participating businesses when they are published, opens a selected program, and earns or redeems under that business’s own rules.
Business staff
Finds or scans the customer inside its assigned business and club, records supported actions, fulfils the local reward, and escalates corrections to its business lead.
Business and district teams
Each business reviews its programs, customers, staff activity, costs, corrections, and support. The district handles onboarding, publication, shared communications, access governance, and first-line platform questions.
Technical routine
The technical operator monitors infrastructure, mail, queues, storage, backups, integrations, security, and releases. Connections to POS, place apps, or reporting systems require owned mapping and recovery.
Buying checklist
Inspect the public promise and the hidden operating duties.
The buying decision should survive a participant joining, disputing data access, and leaving.
Value and participation
Confirm whether rewards remain with each issuing business, which businesses may join, who approves programs and listings, how costs are funded, and how participation ends.
Data and support
Inspect isolation, manager access, customer requests, exports, deletion, retention, incident handling, support evidence, and the district’s responsibility when a business cannot resolve a question.
Place brand and communication
White-label relevance: A supporting benefit. The district can configure installation identity while businesses control their own program presentation. Review domains, public URLs, wallet context, email identity, templates, locale presentation, and source-change needs.
Source-owned case
Choose source-owned software when place-brand continuity, deployment and data-location control, inspectable business boundaries, and maintainable local integrations justify self-operation. Choose a managed or campaign tool when the district cannot sustain that work.
Complete operating cost
Use maintained pricing for the license, then add hosting, email, backups, monitoring, security, business onboarding, training, support, place communications, integrations, custom work, and updates.
Product and operating limits
Keep shared discovery separate from shared value.
- Reward Loyalty does not ship a district currency, cross-business earning and redemption, shared reward liability, merchant settlement, or coalition reconciliation.
- The public listing is a discovery surface, not a complete place CRM, event platform, tourism pass, gift-card network, advertising marketplace, or automatic approval workflow. With open self-registration, the operator must monitor publishing permission.
- The district operator must supply hosting, maintenance, backups, security, participation governance, business onboarding, training standards, first-line support, legal analysis, and incident response.
- APIs, webhooks, imports, and source access can support scoped place connections, but integrations and custom behavior 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.