CHARGEBEE · MULTI-ENTITY PLATFORM
Multi-Entity Platform
Designing a scalable operating model for global businesses — turning an ambiguous, revenue-backed brief into a shared site-versus-entity model.
Role
Lead Product Designer
Scope
0→1 Enterprise Capability
Type
Platform Model
Status
Shipped · GA
One company. Many entities. One shared platform model.
Chargebee's flat-site model worked for a single business. But global companies needed to manage subsidiaries, regions, currencies, and local operations without rebuilding the same setup every time.
My role
I turned an ambiguous, revenue-backed enterprise brief into a shared site-versus-entity model that product and engineering teams could build against.
The flat-site model was blocking enterprise growth
It wasn't a missing screen. The product's underlying model — flat, single-tenant — couldn't represent a company that is multiple businesses. Three problems surfaced again and again across enterprise calls.
01 — Duplicated setup
Each region recreated billing, tax, product, and payment configuration from scratch.
02 — Fragmented control
Admins could not see or govern policies consistently across all entities.
03 — Opportunities blocked
Global customers could not represent their real operating structure inside Chargebee.
18
High-value accounts
Affected and needing multi-entity to scale.
130+
Merchants
Required multi-entity support across the base.
$2M+
ARR influenced
Pipeline tied to the model landing at GA.
How might we help one global business manage many entities without duplicating setup?
Before
Each regional site operated independently, with repeated setup and disconnected policies.
After
One parent company could manage shared policies centrally, while regional entities handled local needs.
The answer was not more settings. It was a clearer system model.
Underneath the broad brief were three clear needs
Discovery — customer calls, CSM debriefs, eng workshops — boiled the surface chaos into three needs the platform actually had to serve.
| Need | What it asks | Why it bit | Becomes |
|---|---|---|---|
| 01 · Shared | Don't reconfigure what doesn't change.Currencies, billing logic, core rules. | Forcing teams to rebuild identical settings on every entity was pure friction. | Site-level defaults that flow down to every entity. |
| 02 · Dual | See the whole and the parts.Operators live at two altitudes. | Without a consolidated view, leadership flew blind across regions. | Two modes — consolidated and per-entity — same screens. |
| 03 · Control | Clear boundaries, real delegation.Locked vs. configurable, hand-off scoped. | Without scoping, a regional admin's mistake could touch every other entity. | Permissions that map to the entity hierarchy. |
I made the thinking visible — and built with people, not for them
With an ambiguous brief and a skeptical room, process alone wouldn't move things. I worked the problem in the open: mapped the customer's real path with CSMs and PMs, then sorted every part of the product into what should stay shared and what had to be separate.
A layered organisation, not a flat one
What's fundamental to the business globally stays at the site. What varies by local context lives at the entity.
One line, but it reorganised the entire product. Below is how it cashed out across the modules — with the items that actually moved during exploration marked.
global, fundamental
Stays at site
- Currencymoved here
- Product catalog
- Customers
- Billing logic
- Core subscription rules
local, contextual
Lives at entity
- Taxesmoved here
- Invoice format
- Payment gateways
- Local subscriptions
- Entity-level reporting
Five roles, mapped to where they live in the system
| Altitude | Configure | Operate | Audit |
|---|---|---|---|
| Site | Site AdminOwns the overall site, sets up entities, decides what stays global. | Finance leadLives in the consolidated view; reconciles the whole to the parts. | — covered by site admin — |
| Entity | Entity AdminReal authority over one entity. Local rules, no blast radius elsewhere. | Ops · Sales · CSDay-to-day inside one entity. Must never act in the wrong context. | ComplianceCares that scope ends at the entity and everything is auditable. |
Four flows where the principle became an interface
Permissions & delegation · consolidated vs. entity view · site vs. entity settings · inherit, override & restore.
Create the entities, hand over the keys, switch context safely
The top-level admin sets up entities, then delegates control downward — give the APAC admin authority over India, Singapore, and the rest of that region, nothing outside it. Switch to an entity and the same screens scope down to just that business, with a clear "you are here" confirmation.
Every setting knows where it belongs
Currency is locked at the site — fundamental to how the business operates globally. Taxes live at the entity — they vary by jurisdiction. At every setting, the admin can see what's fixed company-wide and what they're free to change locally.
Inherit by default. Override deliberately. Restore in one click.
When you create an entity, it inherits the site's settings — because most business rules are identical and rebuilding them would be wasteful. Need something different? Override at the entity. Went too far? Restore to the site default.
Validation
Walked ~10 customers through it — the default-plus-escape-hatch model landed cleanly.
Adoption among the customers who needed it most
131
Merchants live
Running production workloads on multi-entity.
18/100
Top accounts
Of the top 100 Chargebee accounts adopted the model.
↑
First-to-ship
Framework became the org's default approach to multi-tenant problems.
I didn't wait for permission to do systems thinking. I built the clarity the whole team needed — together.
Let's
Talk
I'm most energized by work where I can dig into complex problems, collaborate with smart people, and ship things that genuinely improve someone's day.
Sreevatsan
Let's talk about AI, Design and any other interesting conversations about hard design problems.