Solution · Multi-business

One installation can serve many separate businesses.

Each partner operates its own programs and data inside one installation. The operator owns the shared infrastructure and administration.

Read the short answer Review the decision

Shared layer: Application and infrastructure
Isolated layer: Partner business data
Member layer: One account, separate programs

Short answer

Start with the operating model.

Reward Loyalty runs several partner businesses inside one installation. Each partner manages its own programs, staff, members, and reporting within the product scope, while the operator owns shared infrastructure and administration. Members use one account across participating businesses, but balances and business activity remain separated by partner. The architecture reduces duplicated infrastructure, not the need for tenant checks, support, and incident ownership.

A franchisor can apply that boundary through the franchise rollout and governance model.

Shared economics

Price one installation and ten client relationships.

Multi-tenancy can spread fixed software and infrastructure costs. Client onboarding and support still grow with the service.

Use the ten-client agency cost scenario as a worked example, then replace every hosting, mail, monitoring, onboarding, maintenance, and labor input.

Read the agency operating model for shared client infrastructure before deciding who owns production, first-line support, client data, and service incidents.

Return to the deployment model behind a shared installation when vendor operation or a required integration matters more than multi-business control.

Decision criteria

What the decision changes.

These choices affect configuration, staff work, economics, support, and the customer promise.

Tenant definition

Treat a partner as a business boundary, not as a casual label for each branch or department.

Operator responsibility

The installation owner controls shared configuration, plans, infrastructure, managers, and service health.

Member experience

One account reduces signup friction, while each business still presents and operates its own programs.

Architecture

Separate shared services from partner ownership.

The commercial service becomes easier to explain when each layer has one owner.

Platform operator

Owns the domain, platform identity, infrastructure, release process, plans, and cross-installation administration.

Partner

Owns its business settings, staff, programs, customers, activity, and reports within granted permissions.

Member

Uses one account and wallet, with program balances, passes, vouchers, and achievements shown per business.

Operations

Design the support and access model.

Multi-business software reduces duplicated infrastructure. It increases the importance of permission and incident discipline.

1

Define onboarding

Decide who creates a partner, which plan or permissions apply, and who verifies business settings.
2

Set manager scope

Grant only the administration needed for the portfolio or network the manager operates.
3

Test partner isolation

Use separate accounts to verify lists, exports, staff, programs, member relationships, and dashboard access.
4

Plan shared incidents

Mail, queues, scheduler, storage, or deployment problems can affect several businesses at once. Name the response owner.

Scale check

Test the shared failure domain before adding clients.

One installation simplifies deployment, while a fault in a shared service can reach several businesses at once.

Capacity

Measure queue load, mail volume, storage, database growth, backups, and restore time against the client mix the operator plans to sell.

Isolation

Test every role, export, API credential, manager scope, and support workflow with accounts from separate partner businesses.

Service ownership

Set maintenance windows, incident communication, escalation, and client exit steps before the shared platform becomes business-critical.

Product and operating limits

Keep the recommendation inside the product boundary.

Multi-tenant operation does not provide automated client billing, tax, contracts, onboarding service, or support staffing by itself.
The shared wallet does not merge partner balances or let one partner inspect another partner’s customers and activity.
One license covers one installation under the current license terms. Separate installations need separate licenses.

Implementation guides

Use current documentation for changing details.

Requirements, interfaces, settings, limits, and release behavior belong in the maintained product documentation.

Review the shared-wallet architectureUnderstand platform branding, partner isolation, member identity, and network use cases. Review user rolesMap administrators, managers, partners, staff, and members to operating responsibilities. Configure partner permissionsControl feature access and partner-level overrides. Group related businessesUse networks for administration without inventing cross-partner data access.