Loyalty Platform for Agencies

One client is a project. Ten clients is an operation.

Running a loyalty or quest program for a single brand is straightforward. Running them for a roster of clients is where most tooling breaks down. The usual loyalty apps are built around one storefront: they bill per store, scale by that store's monthly order volume, and assume the merchant, not an agency, owns the account. Smile.io, for example, prices in tiers by monthly orders, and its partner track has agencies configuring the native Shopify app inside each client's own store rather than from a shared console. That model leaves you juggling a separate login, contract and invoice for every client, and stitching reports together by hand.

For an agency that is the wrong shape. You need to provision a new client without a new vendor relationship, keep each brand's audience and data walled off from the next, and prove value per account with real numbers. A standard white-label loyalty platform re-skins one program; an agency needs that same branding control multiplied across many tenants, governed from a single super-admin seat. That is the gap this page is about. For a deeper side-by-side on the incumbent model, see our Smile.io alternative breakdown.

How the multi-tenant module works for agencies

Loyalty Stacker uses a two-tier administration model. At the top sits your agency super-admin, with visibility and control across every client brand you manage. Beneath it, each client is a fully separate tenant with its own admins, members, quests, points ledger and credentials. One tenant cannot see, query or affect another: data isolation is the default, and API keys and integration credentials are scoped per tenant so a client's connected accounts never leak across the boundary.

Each tenant carries its own identity. You set a custom domain or subdomain with managed SSL, upload light and dark logos, an icon and share cards, pick a theme, and rename the generic Points to whatever currency fits the brand, with its own icon. Members sign in through Dynamic under the client's domain, so the end experience looks and feels like the client built it, not like a shared tool.

The piece that makes this an agency product rather than a single-brand one is per-client feature toggles. Every capability is switchable per tenant: referrals, leaderboards, the rewards shop, badges, daily check-in streaks, the creator clipping module, Apple and Google Wallet loyalty cards, social quests, on-chain quests, NFT minting and soulbound credentials. A client only ever sees and runs the modules they actually purchased, so the same platform powers a bare-bones referral program for one account and a full Web2-plus-Web3 quest stack for another, with no forks and no separate deployment.

Standing up a new client program

1. 1
   Provision the tenant

   From your super-admin console, create a new client tenant. It comes up isolated by default with its own member list, points ledger, admin roles and scoped credentials. No shared keys and no shared audience with your other clients.

2. 2
   Brand it and point a domain

   Add the client's custom domain or subdomain with managed SSL, upload light and dark logos and share cards, choose a theme, and rename Points to the client's own currency. Pick the homepage layout that suits their audience.

3. 3
   Toggle features to what they purchased

   Switch on only the modules in the client's package: referrals and points for a starter, wallet loyalty and clipping for a growth tier, full on-chain quests with NFT or SBT rewards for the top tier. Everything else stays hidden from that tenant.

4. 4
   Load quests, rewards and the shop

   Build the client's quests (social, check-in, API or on-chain), set point values, stock the rewards shop and configure badges and multipliers. On-chain conditions are verified read-only via Alchemy across EVM chains and TON; the reward itself is granted inside the program.

5. 5
   Test behind maintenance mode

   Flip the tenant into maintenance mode and use the admin bypass to walk the client through their live program before the public can reach it. Catch branding, point math and quest logic privately, then hand over a finished build.

6. 6
   Launch and monitor per-tenant analytics

   Lift maintenance mode to go live. From then on each tenant has its own dashboard of DAU, WAU and MAU, stickiness, completions and retention, plus one-click CSV exports you can drop straight into the client's monthly report.

Per-tenant analytics, exports and audit

Every tenant reports on itself. Inside a client's workspace you get an engagement dashboard covering DAU, WAU and MAU, stickiness (DAU over MAU), new signups, total members, points distributed, a quest-type breakdown, the top-performing quests, and cohort and retention curves. Because the numbers are scoped to a single tenant, what you show one client never mixes with another account's data.

When it is time to report or hand over raw data, one-click CSV exports cover members, quest completions, the leaderboard and full points history. Those drop straight into a spreadsheet or your own deck, and they pair well with the loyalty ROI calculator when you want to turn engagement into a revenue story for the client.

Two more controls matter at agency scale. Admin actions are written to an audit log, so when a client asks who changed a reward or adjusted a member's balance, there is a record. And maintenance mode with admin bypass lets you take a tenant offline for changes or pre-launch testing while your own team keeps full access, so clients only ever see a finished, working program.

Who it's for

The multi-tenant module fits any team that delivers engagement programs as a service rather than running one in-house:

• Marketing, growth and retention agencies adding loyalty and quests to client retainers without reselling someone else's branding.
• Web3 studios, guilds and launch partners running on-chain quests, NFT and SBT campaigns for multiple communities, each verified read-only via Alchemy.
• Loyalty and CRM consultancies that design programs and need a platform to operate them across a whole client book.
• Franchise groups and multi-location operators that treat each region or sub-brand as its own tenant.
• Product and dev shops that want to put a working engagement platform under their own offering instead of building one from scratch.

If you only run a single brand, the white-label loyalty platform page covers the same branding controls for one tenant.

Run every client program from one console

If you deliver engagement as a service, the multi-tenant module lets you provision, brand, toggle and report on each client without a new vendor relationship per account. Get started to open your agency console, or book a demo to walk through onboarding your first client tenant.