
TL;DR β three multi-tenant architectures, one operational reality
You're an agency owner running a whitelabel WhatsApp CRM reseller business in India. Friday evening you closed your fifth customer. Monday morning your wallet says βΉ0, two end-customer brokers can't log in because their licenses expired overnight, and a support ticket is sitting open for 14 hours because your part-time engineer thought it was a Lion CRM-side bug when it was actually a wallet top-up issue. Multi-tenant license management is the operational layer that breaks first when an agency scales from 5 end-customers to 50. This guide is the playbook so you don't have to learn it in production.
I'm Rakshit, co-founder of Lion CRM, a product by LotsOfCode Private Limited. Over the past four years I've watched dozens of Indian whitelabel resellers stress-test their license-management layer. Most of them hit a wall around their fifteenth end-customer because they treated license management as an afterthought instead of a Day-1 architectural choice.
Three architectures, three operational shapes:
| Reseller architecture | Tenant isolation | Reseller dashboard visibility | Per-license cost shape | Right when⦠|
|---|---|---|---|---|
| Hosted-SaaS multi-tenant (BSP-partner like AiSensy) | Logical (shared database, separate schemas) | Yes β into customer activity, conversations, churn-risk indicators | Variable β depends on customer's WhatsApp conversation volume | You want dashboard visibility for upsell + retention, accept conversation-volume variance |
| Chrome-extension multi-tenant (Lion CRM) | Physical (data on each end-customer's laptop) | License manifest only β no customer chat/contact data | Fixed β flat per-user-per-month wholesale | You want predictable per-license costs + zero data-store liability + simple ops |
| Self-hosted multi-tenant (build-your-own) | Whatever you build | Whatever you build | Whatever you can engineer | You have a 5-engineer team and 12 months of runway, otherwise unrealistic |
The architecture decides what your Day-30 looks like. The pricing tier you negotiate is a smaller second-order choice. Pick by ops bandwidth + privacy posture, not by "which has the better partner-program landing page."
If you'd rather see this walked through visually, LotsOfCode's YouTube channel has a 12-minute version. The deep operational dive β with sizing math, integration steps, and the support-tier handoff playbook β is below.
The Lion CRM license-pool architecture
Lion CRM's multi-tenant model is deliberately simple, which is why it scales without eating your operational bandwidth. The shape:
admin.lioncrm.com (you, the reseller β ONE admin account)
β
βββ Branding section (one-time setup: brand name, logo, colors, domain, support number)
βββ Wallet section (single recharge β one credit balance for ALL licenses)
βββ Licenses section (generate paid + 7-day trial licenses per end-customer broker)
βββ Overview section (1-month free personal-use license for dogfooding)
βββ (optionally) Webstore Setup ($250 one-time β public marketing site under your brand)
End customer (your client's broker)
βββ Downloads YourBrand-CRM extension (rebranded build β never sees "Lion CRM")
βββ Logs into WhatsApp Web in their own Chrome
βββ License activates β broker uses extension on their laptop
βββ Contacts + chats + Kanban board live LOCALLY on broker's laptop
A few things about this model that aren't on the price card:
- One admin account, one wallet, N licenses. No separate billing per end-customer to chase. The wallet draws βΉX per license per month for paid licenses; trial licenses are free.
- Each end-customer broker's data lives on their own laptop. Lion CRM does not store contacts, conversations, follow-ups, or any customer data on a central cloud. Your reseller dashboard sees the license manifest (broker name, license type, expiry, last-active timestamp) β never the actual contact records or chat logs.
- Branding is reseller-account-level, not per-end-customer. Once you configure Branding (logo, colors, domain, support number), every license you generate inherits it. To run two parallel brand verticals (e.g. Real-Estate-CRM and EdTech-CRM under the same agency), today you need two admin accounts. (Multi-brand under one admin is on the Lion CRM roadmap; not shipped at the time of this post.)
- No template approval queue, no Meta BSP partner-tier gates. End-customer's own WhatsApp number sends and receives messages from their own browser session. This is what makes the "fixed wholesale" math possible β there's no per-conversation cost to model. (For the architecture deep-dive, see our WhatsApp CRM vs WhatsApp Business API post.)
The trade-off is genuine and worth naming explicitly: you lose dashboard visibility into customer activity (campaigns sent, conversations volume, engagement trends) because that data isn't centrally stored. In return you get zero data-store liability (no GDPR/DPDP compliance burden for storing end-customer broker data β because you don't store it) plus predictable per-license economics (no conversation-volume surprises).
For a reseller running 30β500 SMB end-customer agents, that trade-off is usually a clear win. For a reseller chasing high-volume marketing-template broadcast customers (100k+ messages/day) where dashboard visibility is genuinely useful, it might tip the other way β see the hosted-SaaS vs Chrome-extension comparison section below.
License-pool sizing β how many licenses to start with
Most early Vikrams over-provision their wallet by 3Γ because they're nervous about a cash-flow gap, then they spend that drag on licenses they don't use for months. Or they under-provision, and end up scrambling at 11 PM on Friday to top up their wallet because a closing customer needs their broker accounts active by Monday morning. Both fail patterns are avoidable with a simple formula.
The sizing formula:
licenses_needed = (active_brokers Γ 1.15 buffer)
+ ceil(monthly_trials Γ trial_conv_rate Γ broker_per_customer)
The 1.15 buffer absorbs short-term churn replacement (5β10%/month average) plus the occasional broker-laptop-died scenario where you re-issue a license to a new device. The second term is your trial pipeline β license slots reserved for prospects who are testing the branded extension before paying.
Worked example β Vikram's first 90 days:
- 3 confirmed customers Γ 5 brokers each = 15 active brokers
- Monthly trial pipeline: 4 prospects per month Γ 25% conversion Γ 5 brokers per converted customer = 5 trial-converted brokers/month
- Buffer = 15 Γ 1.15 = ~17 (rounded up)
- Active + buffer + trial = 17 + 5 = 22 licenses
So Vikram's wallet should support 22 active licenses at the Lion CRM Growth tier (= 22 Γ $2.00/month = $44/month wholesale + $200 one-time setup). His first wallet recharge: ~$200 covering ~4.5 months of license fees + buffer.
Scale rule β top up in 25-license increments. As Vikram crosses break-even thresholds (typically around customer #15), grow the wallet 25 licenses at a time. Set a Slack alert (or even a phone reminder) at 80% utilization of the current wallet β that's the trigger to plan the next top-up before you hit 100% on a Friday evening close.
Common sizing mistakes to avoid:
| Mistake | Symptom | Fix |
|---|---|---|
| Over-provisioning at launch (50+ licenses for first 5 customers) | Cash-flow drag, demoralized founder watching unused capacity | Start at the formula's number, not gut feeling. Top up after each closing wave. |
| Under-provisioning during a sales push | Friday 11 PM panic recharge for Monday-morning customer kickoff | 80%-utilization Slack alert + standing wallet buffer β₯ 1.5Γ current active count |
| Allocating trial licenses without expiry tracking | "Why is my wallet draining for inactive trials?" | Use Lion CRM's built-in trial-license expiry (7 days default) β auto-frees back to pool |
| Reusing a paid license slot for a trial without canceling | Wallet shows correct count, but billing reconciliation fails | Cancel the paid license first; trial slots are separate counters |
The first six months are when sizing discipline matters most β that's the period where every wallet decision is visible to the founder personally. After break-even (~customer #15 on the Chrome-extension model, ~customer #25 on the BSP-partner model), sizing automation becomes worth building.
Sub-account isolation β what each side actually sees
The phrase "sub-account isolation" sounds like a SaaS-architecture design pattern, but for a reseller it's an operational guarantee β what your end-customer sees, what their end-customer (their broker) sees, and what you (the reseller) see. Three vantage points worth keeping straight.
Your end-customer's broker (the actual person using WhatsApp):
- Downloads
YourBrand-CRMextension from the link you provide - Logs into WhatsApp Web in their own Chrome
- License activates against their email + WhatsApp number
- Sees only their own contacts, conversations, follow-ups, Kanban cards
- Never sees another customer's data because no central database holds it
- Brand-wise: every UI surface says
YourBrandβ they don't see "Lion CRM" anywhere
Your end-customer's owner / admin (your direct customer):
- May have multiple brokers under their organization
- Receives the license credentials from you
- Distributes to their brokers via internal channel
- May share contacts within their organization via the Lion CRM team-sharing feature (still laptop-local, peer-to-peer between authorized devices)
You (the reseller, on admin.lioncrm.com):
- Sees the license manifest for every license you generated:
- Broker name + email associated with the license
- License type (paid vs trial)
- Expiry date
- Last-active timestamp (when the broker last opened WhatsApp Web with the extension)
- License status (active / expired / revoked)
- Sees the wallet balance + branding settings
- Does NOT see: broker contacts, broker chat logs, broker follow-ups, broker Kanban cards, broker analytics
- Can revoke a license (frees back to the wallet pool); cannot recover the broker's data (it's on their laptop)
This isolation model is structurally different from hosted-SaaS multi-tenancy. In a hosted-SaaS reseller dashboard (think AiSensy partner panel), the reseller has visibility into customer conversation volume, campaign send-rate, engagement trends β useful for identifying upsell triggers and churn risk. In Lion CRM's model, that visibility doesn't exist because the data isn't on the cloud.
Why this trade-off matters operationally:
- Compliance burden: zero. As the reseller, you're not the data controller for end-customer broker contacts or chats. Your end-customer is. India's DPDP Act, GDPR for European customers, healthcare-specific data handling β all the data-locality questions become "your end-customer's responsibility" rather than your data-architecture problem.
- Upsell signal generation: harder. You can't easily detect "this customer's brokers stopped sending campaigns last week, time to call them about churn." You learn churn at cancellation, not before.
- Support diagnostics: narrower. When a broker reports "my contacts disappeared," you can verify the license is active and the extension version is current β but you can't see what contacts they had. The diagnosis lives entirely on the broker's laptop.
For most SMB reseller use-cases (real-estate brokers, service businesses, EdTech tutors), the compliance + operational simplicity wins outweigh the lost upsell-signal visibility. For high-touch enterprise resellers selling into healthcare or finance verticals where the end-customer specifically wants compliance offloaded, the win is even clearer.
Billing API hooks β Zapier bridge to Razorpay and Stripe
Lion CRM's wallet model handles the reseller-to-Lion-CRM billing automatically (you recharge once, licenses draw down). What it doesn't natively handle is the reseller-to-end-customer billing β i.e., your invoices to your customers for the branded WhatsApp CRM service. That's where the Zapier bridge comes in.
The bridge pattern: when you generate a paid license in Lion CRM, fire a webhook β Zapier filter β Razorpay/Stripe subscription create β email the end-customer their invoice + login. When the license is cancelled, fire another webhook β Zapier β cancel the subscription. Total wire time: ~30 minutes one-time setup, then it runs hands-off.
The 5-step Zapier setup:
- Trigger: Lion CRM Webhook on license-create β Lion CRM fires a webhook when a paid license is generated. Payload includes:
broker_email,customer_email,license_type,license_id,retail_price(configured in your reseller dashboard's per-license retail field),created_at. Configure this webhook in Lion CRM Webhooks section. - Filter: license_type == "paid" β Skip trial license events (no billing for trials).
- Action: Razorpay (or Stripe) Subscription Create β Map fields:
customer.emailβcustomer_emailcustomer.nameβcustomer_emailusername portion (or pull from a separate field if you collect business names)plan.amountβretail_price(in paise β multiply by 100 if the field is in rupees)notify.emailβcustomer_emailstart_atβcreated_at
The subscription auto-charges monthly. Razorpay returns asubscription_id.
- Action: Email β Invoice + Welcome β Use Mailgun, Gmail, or SendGrid in Zapier. Compose from a template:
- Subject:
Your YourBrand WhatsApp CRM subscription is active β login details inside - Body: subscription_id, login link to your branded extension, support email, billing FAQ
- Send to
customer_email
- Subject:
- Trigger: Lion CRM Webhook on license-cancel β Action: Subscription Cancel β Closes the loop. Without this hook, you'll keep charging end-customers after the license expires.
Total wire time: ~30 minutes the first time. After that, every license you generate fires the full pipeline automatically. Saves you a manual Razorpay click for every new customer (15β20 minutes Γ monthly close volume).
Edge cases worth handling:
| Scenario | What to do |
|---|---|
| End-customer's payment fails repeatedly | Add a Zapier path: Razorpay subscription payment_failed event β email reminder + Slack alert to you. After 3 failures, optionally auto-revoke the Lion CRM license. |
| End-customer wants to switch from monthly to annual prepay | Manual today: cancel the monthly subscription, create a new annual one, no Lion CRM license change needed (license is metered by month either way). |
| End-customer wants to add a broker mid-month | Generate a new Lion CRM license, fire the webhook β Zapier β upgrade the Razorpay subscription with the additional broker. Pro-rate at billing time. |
| Refund request | Issue refund from Razorpay dashboard manually; revoke the Lion CRM license; update wallet allocation. |
The bridge is intentionally minimal β most resellers add 1β2 custom steps over time as their billing complexity grows. The starter pattern above is enough for the first 50 customers without modification.
Support-tier handoff β Tier 1 vs Tier 2
About 80% of end-customer support tickets are Tier-1 (you handle them as the reseller). About 20% are Tier-2 (escalate to Lion CRM). Knowing which is which prevents two failure modes: wasting your support engineer's time on Tier-2 issues that need vendor-side fixes, and wasting Lion CRM support's time on Tier-1 issues you should have closed.
Tier 1 (you, the reseller β ~80% of tickets):
- Onboarding training β extension install, WhatsApp Web login, first contact import, basic feature walkthrough. New brokers especially in Tier-2/3 cities need 30β45 minutes of guided training. Pre-record a short video; reference it in onboarding emails.
- Password resets / license reissues β broker forgot login, broker switched laptops (Backup & Restore), broker email changed.
- "My campaign didn't send" triage β usually one of: WhatsApp Web disconnected, contact list parse error, message length exceeds limit, broker hit WhatsApp's anti-spam threshold. Diagnose with the broker, not by escalating.
- Scope/feature questions β "Can the extension do X?" / "How do I do Y?" β answer from your knowledge base. If the answer is no and the customer needs that feature, that becomes a Tier-2 roadmap escalation.
- General how-to β bulk message setup, follow-up triggers, Kanban stage transitions, AI integration setup.
Tier 2 (Lion CRM support β ~20% of tickets):
- Extension crashes / version-specific bugs β reproducible across multiple devices, indicates a Lion CRM-side issue. Send the version number + screen-recording.
- License-pool / wallet billing issues on YOUR Lion CRM admin account (not on the end-customer) β wallet balance discrepancy, license-count mismatch, paid license that won't activate, trial license that didn't auto-expire.
- Multi-tenant isolation questions β e.g., "I think customer A's data is showing up on customer B's broker." Almost always a laptop-side issue (broker logged into wrong WhatsApp account, shared device), but worth verifying with Lion CRM if reproducible across multiple devices.
- Roadmap escalation / feature requests β your end-customer needs a feature that doesn't exist. File via the Lion CRM partner roadmap channel; communicate timeline back to your customer honestly.
Escalation criteria β give your support engineer this list:
Escalate to Lion CRM Tier-2 if:
β Bug reproduces across 2+ devices and 2+ Lion CRM versions
β Wallet balance / license count doesn't match your reseller dashboard manifest
β Extension fails to install/activate on a known-good Chrome version
β Multi-tenant isolation suspicion confirmed across devices
Close as Tier-1 if:
β Single-broker, single-laptop issue
β WhatsApp Web side problem (logged out, network)
β Configuration question answerable from the knowledge base
β "How do I" question
β Feature request that hasn't been roadmap-confirmed
SLAs to set:
- You β end-customer: 4-hour first response, 24-hour resolution for Tier-1 issues. Tier-2 issues: 4-hour first response, "we've escalated, will update within 48 hours" β then communicate honestly when Lion CRM Tier-2 responds.
- Lion CRM Tier-2 β you: 24 business hours first response, 72 business hours resolution attempt for confirmed Tier-2 issues. Faster on Pro support tiers if available.
Don't promise faster than your engineering bandwidth supports. SMB customers in India accept honest 24-hour SLAs more readily than missed 1-hour SLAs β set expectations explicitly in onboarding.
Common operational pain points
Five operational scenarios every Vikram hits within the first 90 days. Each has a known fix, none requires an emergency.
(a) License-pool depletion at Friday evening close. A new customer signs Friday 8 PM, you go to generate licenses Monday morning, wallet says βΉ0. Fix: keep wallet topped up to β₯1.5Γ current active license count. Set a Slack alert (or phone reminder) at 80% utilization. The 30 seconds spent on this avoids the Friday-evening panic recharge.
(b) End-customer requests a Lion CRM-side feature change. "Can your extension support voice messages in bulk?" When the answer is "not currently, but it's on the roadmap" β communicate the timeline honestly. Don't promise a feature that isn't shipped. File the request via Lion CRM's partner roadmap channel; loop back when there's a status change.
(c) End-customer's broker laptop dies β license + data both at risk. Lion CRM's Backup & Restore feature mitigates this completely if used. Mandatory: include a 5-minute Backup & Restore training in your onboarding. Optional: monthly automated reminder email to all your end-customers β "Did you back up this month?" Most resellers skip this and learn from the first laptop-death incident.
(d) End-customer wants to switch broker mid-month. Old broker leaves, new broker joins the customer's team. Process: cancel the old broker's license in your dashboard (frees the slot back to the wallet pool), generate a new license for the new broker, transfer customer data via Lion CRM's Backup & Restore β old broker exports, new broker imports on their laptop. The wallet doesn't double-charge for the same slot in the same month if you cancel-and-reissue within 24 hours (subject to your specific tier terms).
(e) Reseller wants to launch a sub-brand vertical (e.g., EdTech-CRM under same parent agency). Today: separate admin account at admin.lioncrm.com per brand (separate wallet + separate license pool). Manual but isolation-clean β your EdTech end-customers see "EdTech-CRM," your real-estate end-customers see "Real-Estate-CRM," neither knows the other exists. Trade-off: you manage 2 wallets + 2 license pools + 2 branding configurations. Lion CRM roadmap: multi-brand under one admin (planned, not shipped).
One that's harder than it looks:
(f) Migrating an existing AiSensy/Wati end-customer to your Lion CRM whitelabel offering. Their conversation history is on the BSP cloud (AiSensy/Wati's database). Lion CRM's Chrome-extension model uses the broker's own WhatsApp Web β different data location entirely. The migration is technically clean (broker keeps their WhatsApp account, contacts, message history because those live in WhatsApp itself), but the historical analytics on the BSP side don't transfer. Communicate this honestly: "You'll lose the AiSensy campaign-level analytics dashboard, but your WhatsApp messages and contacts come with you." Most SMB customers prioritize lower per-month cost over historical analytics; the migration story is a feature, not a bug.
Hosted SaaS vs Chrome-extension multi-tenancy
The most useful side-by-side for a Vikram who's actually deciding which architecture to commit to:
| Dimension | Hosted SaaS multi-tenant (BSP-partner) | Chrome-extension multi-tenant (Lion CRM) |
|---|---|---|
| Tenant isolation | Logical (database-level row/schema separation) | Physical (data on each end-customer's laptop) |
| Reseller dashboard visibility into customer data | Yes β campaigns, conversations, engagement, churn signals | License manifest only β no chat or contact data |
| Data-store liability for reseller | High β you store end-customer data on the BSP's cloud | None β you don't store end-customer data |
| GDPR / DPDP compliance burden for reseller | Significant β you're processing personal data on behalf of your end-customers | None for chat/contact data; minimal (just license metadata) |
| Per-customer cost shape | Variable (per-conversation Γ volume Γ BSP markup) | Fixed (per-license-per-month) |
| License-pool model | Yes (sub-account quota in partner dashboard) | Yes (wallet-based, single recharge) |
| Time to first reseller customer | 3β7 days (BSP onboarding + business verification) | Same day (admin signup ~30 min) |
| Scalability ceiling | Very high (100k+/day broadcast volume customers) | High (5β500 active brokers, lower per-customer broadcast volume) |
| Ops bandwidth needed at 50 customers | Higher β billing reconciliation across BSP + your invoicing + per-customer activity monitoring | Lower β simpler license-manifest tracking, no per-conversation reconciliation |
| Support-tier handoff complexity | Higher β you mediate between BSP support and end-customer | Lower β clearer Tier-1 vs Tier-2 boundary |
| Multi-brand support | Often yes via partner sub-tenancy | Per-brand admin account today (multi-brand under one admin on roadmap) |
Honest read: neither is universally better. Hosted SaaS suits resellers who need dashboard visibility and can absorb conversation-volume variance. Chrome-extension suits resellers who want predictable cost shape and simpler operations. Pick the one whose operational shape matches your team's bandwidth and your end-customer base's actual broadcast behavior.
If your end-customers send marketing-template campaigns at 100k+/day with high conversion, the hosted-SaaS BSP-partner path will pay back the variance + complexity. If your end-customers are 30 brokers each sending normal SMB volumes (a few hundred messages a day, lots of 1-on-1 conversations), the Chrome-extension path's predictability + zero-data-liability will compound for you.
Multi-brand operational scenario
Vikram has been running a single brand β "AgencyOne CRM" β for 6 months. Now he wants to launch two more verticals: "AgencyOne EdTech" (for tutoring centers) and "AgencyOne Realty" (for property brokers). Three brands, three different end-customer personas, three different sales pitches. How does multi-brand work on Lion CRM today?
Today's setup (3-brand reseller):
- 3 separate admin accounts at admin.lioncrm.com β one per brand
- 3 separate wallets β Vikram recharges each independently based on per-brand license counts
- 3 separate Branding configurations β each brand gets its own logo, colors, domain, support number
- 3 separate Licenses sections β license pool per brand, no cross-pollination
- 3 separate Zapier billing pipelines if Vikram wires Razorpay subscriptions per brand (or one pipeline with brand-tag routing)
Workload implications:
| Activity | Single-brand effort | 3-brand effort |
|---|---|---|
| Wallet top-up | 1Γ per cycle | 3Γ per cycle (~5 min total) |
| Branding configuration | 1Γ one-time | 3Γ one-time (~30 min total) |
| License-pool monitoring | Single dashboard | 3 dashboards, ~2 min each daily |
| Support routing | All in one inbox | Separate inbox per brand (recommended) |
| Billing reconciliation | One Razorpay account | One Razorpay account, brand-tagged subscriptions |
Total extra admin overhead vs single-brand: ~2 hours/month. Manual but tolerable β the isolation is clean and end-customers in different verticals never see each other's brand or data.
Lion CRM roadmap (planned, not shipped at the time of this post):
- Multi-brand under one admin account
- Brand profiles: switchable Branding configurations under one wallet + license pool
- Per-brand tag on each license β tag becomes the routing key for all brand-specific operations
- Single dashboard with brand-filter dropdown
When that ships, the 3-brand Vikram collapses to: 1 wallet + 3 brand profiles + 1 license pool with brand tags + 1 support inbox with brand-tag routing. ~2 hours of monthly admin overhead drops to ~30 minutes.
For now, if you're planning a multi-brand reseller business, build it expecting today's per-brand-admin-account model. The roadmap upgrade will be additive β your existing per-brand admin accounts will be migratable to brand profiles when the feature lands.
Customer-handoff scenario β when an end-customer leaves
End-customer wants to leave the reseller β maybe they're going direct to Lion CRM (rare), maybe switching to another reseller, maybe shutting down their business. The handoff has a technical side and an economic side, and they have different shapes.
The technical handoff (smooth):
- Reseller cancels the license in their admin dashboard. License frees back to the wallet pool. End-customer's broker can no longer activate the extension under your brand.
- End-customer registers direct or with another reseller. They get a new license activation key.
- End-customer's broker exports their data via Lion CRM's Backup & Restore feature on their laptop β contacts, chat history, follow-up rules, Kanban cards. Backup file is local.
- Broker installs the new branded extension (or the direct Lion CRM extension), logs in, imports the backup. Their data comes with them.
The technical part is genuinely smooth because data is laptop-local. There's no central database migration, no API call to "transfer ownership," no "delete-your-account-on-our-side-then-they-create-on-theirs" coordination. It's just: cancel license, broker exports, broker imports under new license.
The economic handoff (always awkward, sometimes manageable):
You lose lifetime value. The customer relationship was built on your branded extension + your support + your invoicing relationship. When the customer leaves, all three pieces leave together.
Mitigation strategies that actually work:
| Strategy | What it does | When to use |
|---|---|---|
| Annual prepay discount (10β15% off) | Reduces month-to-month churn risk; locks in 12 months of cash flow | Standard offer for any customer with > 5 brokers + > 6 months tenure |
| Bundle integrations + onboarding services | Makes the relationship sticky beyond the bare extension β Zapier pipes to their existing CRM, custom training, vertical-specific templates | Especially for high-touch B2B verticals where your operational expertise compounds |
| Tiered service plans (Standard vs Pro) | Pro tier with monthly review call + priority support builds personal relationship that's harder to replicate | After customer crosses ~10 brokers β when the relationship is worth investing in |
| Clear license-cancel terms in end-customer agreement | Removes "who pays for what" ambiguity at exit; preserves goodwill | At onboarding β bake into your standard customer agreement |
The mitigation strategies don't prevent customer-handoff β sometimes the customer's business changes and they genuinely don't need a WhatsApp CRM anymore. They reduce the pain of when it happens.
The slight upside of laptop-local data: the customer leaves with their data intact. They don't feel hostage. That's usually a goodwill-positive β the same customer might come back when they spin up their next venture, or recommend you to a peer who hasn't built their reseller layer yet. Don't burn bridges on exit.
Try Lion CRM free for 7 days
Want to test the multi-tenant license model yourself before committing? Install Lion CRM directly from the Chrome Web Store β every first-time install gets an automatic 7-day free trial.
Steps:
- Click the install link β Get Lion CRM on Chrome Web Store
- Click "Add to Chrome" β extension installs in seconds.
- Open WhatsApp Web in your browser β Lion CRM activates automatically.
- Your 7-day trial starts the moment you log in. No credit card needed.
- After 7 days, choose a paid plan or upgrade to whitelabel reseller.
The end-user trial is the same software your future customers will use β you'll see exactly what they see, before you commit to the reseller setup.
Start your multi-tenant Lion CRM whitelabel reseller account in under 30 minutes
Ready to set up the reseller layer with multi-tenant license management? Here's the full 9-step admin onboarding flow:
Steps:
- Go to the admin panel β admin.lioncrm.com
- Register your account, then log in.
- Choose a plan (Starter / Growth / Enterprise) and complete payment. You'll be redirected to the dashboard.
- Open the Branding section β fill in your white-label details (brand name, logo, colors, support number, your website URL) β click Save. This applies to every license you'll generate.
- Click Download Extension to get your own white-label branded build.
- Open the Licenses section to generate licenses:
- Paid licenses (each consumes one active-user slot at your tier's per-user/month fee, drawn from wallet)
- 7-day free trial licenses (give to prospects so they can test your branded extension first; auto-expire after 7 days)
- Overview section gives you 1 month of free license for your own personal use of the extension β dogfood your own multi-tenant setup before handing it to the first customer.
- Add balance once in the Wallet section using the license-pool sizing formula above β removes per-license payment friction; each new license draws from the wallet.
- Distribute your branded extension to your end-customers + activate licenses. You're now running a multi-tenant whitelabel WhatsApp CRM SaaS.
That's the complete reseller setup. The Zapier billing bridge (above section) is the optional Step 10 that automates end-customer invoicing.
Frequently asked questions
How does multi-tenant license management work in a whitelabel WhatsApp CRM?
Multi-tenant license management in a whitelabel WhatsApp CRM means one reseller admin account managing multiple end-customer broker licenses through a single dashboard. In Lion CRM’s model: one admin account at admin.lioncrm.com, one wallet (single recharge), N licenses (each license = one active broker on one end-customer’s laptop). The reseller centrally manages branding (one-time), license generation (per end-customer broker), wallet top-up, and support routing. End-customer data lives 100% on each broker’s own laptop β the reseller sees the license manifest (broker name, license type, expiry status) but not the actual contact records or chat logs.
What is the difference between hosted-SaaS multi-tenancy and Chrome-extension multi-tenancy?
Hosted-SaaS multi-tenancy (BSP-partner platforms like AiSensy or Wati) uses logical tenant isolation β all customer data lives on the vendor’s cloud database, separated by row-level or schema-level access controls. The reseller has dashboard visibility into customer activity (campaigns sent, conversations, engagement signals) and carries data-store liability for storing end-customer data. Chrome-extension multi-tenancy (Lion CRM) uses physical tenant isolation β each broker’s data lives on their own laptop. The reseller sees the license manifest but not customer data, has zero data-store liability, and gets predictable per-license cost (no conversation-volume variance). The trade-off is reseller dashboard visibility for compliance simplicity + cost predictability.
How many licenses should I start with as a Lion CRM reseller?
Use the formula: licenses_needed = (active_brokers Γ 1.15 buffer) + ceil(monthly_trials Γ trial_conv_rate Γ broker_per_customer). For a Vikram-type reseller with 3 confirmed customers averaging 5 brokers each (15 active brokers) and a monthly trial pipeline of 4 prospects Γ 25% conversion Γ 5 brokers per converted customer (5 trial-converted brokers), the start-up license count is approximately 22 licenses. Scale in 25-license increments after crossing your operating-cost break-even point. Set a Slack alert at 80% wallet utilization to plan top-ups proactively rather than reactively.
How does sub-account isolation work in Lion CRM?
Sub-account isolation in Lion CRM is physical, not logical. Each end-customer’s broker downloads the YourBrand-CRM extension (rebranded build), logs into WhatsApp Web in their own Chrome, and sees only their own contacts, conversations, follow-ups, and Kanban cards β the data lives entirely on the broker’s laptop. The reseller sees the license manifest (broker name, email, license type, expiry, last-active timestamp) on admin.lioncrm.com but cannot see the actual broker conversation data. End-customers in different verticals (e.g., a real-estate broker and an EdTech tutor under different reseller brands) have completely separate data because no central database holds either’s records. This isolation model trades reseller dashboard visibility for compliance simplicity and zero data-store liability.
Can I integrate Razorpay or Stripe with Lion CRM for end-customer billing?
Yes, via a 5-step Zapier bridge. When you generate a paid license in Lion CRM, fire a webhook β Zapier filter on license_type=paid β Razorpay/Stripe subscription create with mapped fields (customer_email, retail_price, subscription start date) β email the end-customer their invoice + login. When the license is cancelled, fire a webhook β Zapier β cancel the subscription. Total wire time: approximately 30 minutes one-time setup, then runs hands-off. Lion CRM doesn’t natively integrate with Razorpay or Stripe (it’s a CRM, not a billing engine), but the webhook surface lets resellers wire the bridge through Zapier or any similar automation tool.
What is the support-tier handoff between Lion CRM and a reseller?
Tier 1 (the reseller) handles approximately 80% of end-customer support tickets β onboarding training, password resets, license reissues, “my campaign didn’t send” triage, scope/feature questions, general how-to. Tier 2 (Lion CRM support) handles approximately 20% β extension crashes, version-specific bugs, license-pool or wallet billing issues on the reseller’s Lion CRM admin account, multi-tenant isolation suspicions, roadmap escalation. The escalation criteria for Tier-2: bug reproduces across 2+ devices and 2+ Lion CRM versions, wallet balance discrepancy, extension fails to install on known-good Chrome, or multi-tenant isolation issue confirmed across devices. Lion CRM Tier-2 SLA: 24 business hours first response, 72 business hours resolution attempt for confirmed issues.
Can I run multiple brand verticals under one Lion CRM admin account?
Today, no β multi-brand requires separate admin accounts at admin.lioncrm.com per brand vertical, with separate wallets, separate license pools, and separate Branding configurations. For a Vikram running 3 brand verticals (e.g., Real-Estate-CRM, EdTech-CRM, D2C-CRM), the operational overhead is approximately 2 extra hours per month vs single-brand operation β manual but tolerable, with clean isolation between verticals. Multi-brand under one admin account is on the Lion CRM roadmap; when it ships, the 3-brand setup will collapse to 1 wallet + 3 brand profiles + 1 license pool with brand-specific tags. Existing per-brand admin accounts will be migratable to brand profiles when the feature lands.
Related guides
- Whitelabel WhatsApp CRM Software: Founder's 2026 Guide
- Whitelabel WhatsApp CRM Margins: What Resellers Make 2026
- Lion CRM vs AiSensy vs Wati: Whitelabel Pricing 2026
- WhatsApp CRM vs WhatsApp Business API: Which to Pick (2026)
- WhatsApp Kanban Board: 2026 Sales Pipeline Guide
The honest verdict
License management is the unglamorous operational layer that breaks first when an agency scales from 5 end-customers to 50. The architecture you pick on Day-1 determines the shape of your failure modes β hosted SaaS gives you dashboard visibility (good for upsell) at the cost of conversation-volume variance and data-store liability; Chrome-extension gives you predictable per-license costs and zero data liability at the cost of dashboard visibility (you can't see customer activity for upsell signals); self-hosted multi-tenant is full control at the cost of full operational burden β only realistic if you have an engineering team and 12+ months of runway.
Pick by ops bandwidth + privacy posture, not by which has the slickest partner-program landing page. The Vikram who designs the license-management layer Day-1 β wallet sizing formula, support-tier handoff playbook, Zapier billing bridge, isolation model that matches their compliance posture β will scale past 50 customers without re-architecting. The one who treats it as an afterthought hits a wall around customer #15 and rebuilds in production while bleeding goodwill.
Lion CRM's Chrome-extension model trades dashboard visibility for predictable cost + zero data liability. Most SMB resellers in India in 2026 β selling to real-estate brokers, service businesses, EdTech tutors, D2C brands β find that trade-off a clear win. If you're running a high-volume marketing-template broadcast operation (100k+/day), the trade tips the other way and a hosted-SaaS BSP-partner path is genuinely better. Pick the architecture that matches what your end-customers actually do, not what the highest-headline-margin sales deck claims.
If you're ready to model the Chrome-extension reseller path, the Lion CRM trial install takes 30 seconds via the Chrome Web Store. The whitelabel reseller signup at admin.lioncrm.com takes about 30 minutes from "register" to "first branded license generated." For the visual walk-through of both paths plus the multi-tenant operational tour, LotsOfCode's YouTube channel has the comparison and the admin-panel tour.
β Rakshit Soni, co-founder, Lion CRM (a LotsOfCode Private Limited product)