Angryturtle multi-tenant tenant hierarchies explained: agency, client and location layers for healthcare marketing agencies at scale

Angryturtle multi-tenant tenant hierarchies are the architectural spine that lets a healthcare-focused marketing agency operate one platform across an agency, its clients, and each client's individual locations without spreadsheets, credential-sharing, or reporting chaos. The agency sits at the top of the tree as the parent tenant; each client is a child tenant with its own settings, users and data boundary; each of the client's physical locations is a grandchild tenant with its own Google Business Profile, sie" style="color:inherit;text-decoration:underline;text-decoration-color:rgba(42,126,200,.5);text-underline-offset:2px">Rank OS score, and operational queue. ICG built this hierarchy to run our own 150+ healthcare client portfolio, and the same architecture is available to other healthcare-focused agencies inside the Healthcare Local SEO Agency India engagement.

angryturtle/02-rank-os.png" alt="Angryturtle Rank OS — 5-dimension health scoring (Completeness · Consistency · Authority · Activity · Sentiment) across the portfolio" loading="lazy" decoding="async" style="width:100%;height:auto;display:block;">

Why tenant hierarchies, not flat multi-account

Most local SEO platforms — BrightLocal, Moz Local, Yext, Whitespark — treat a portfolio as a flat list of accounts. The agency logs in, sees every location the agency manages, and every user with agency access can see every location. It works for a 5-location portfolio. It falls apart at 50, breaks at 200, and becomes actively dangerous at 500.

Flat multi-account has three structural failures at scale.

No client boundary. An account manager assigned to Client A can see Client B's data. A compliance reviewer approving content for Hospital A can accidentally publish content on Hospital B's profile. Cross-client accident risk grows linearly with portfolio size.

No location grouping. A hospital chain with 12 city locations shows up as 12 flat entries next to a solo clinic's 1 location. The chain's marketing head has no consolidated view; the account manager has to remember which 12 entries belong to that client.

No billing separation. The agency's own subscription, the client's allocated seats, and the location-level credit consumption all pool into one bucket. Reconciling what to bill each client at month-end becomes a spreadsheet reconstruction exercise.

Tenant hierarchies fix all three by making the boundaries structural rather than optional.

The three-layer tree explained

Angryturtle's tenant model has three canonical layers.

Parent tenant — the agency. The agency itself is the top-level tenant. Agency Admin users at this level have full visibility across every client and every location the agency manages. Agency-level settings include the agency's brand identity, white-label configuration, billing subscription, and the roster of Agency Admin, Operations Specialist, and Compliance Reviewer users who work across the full portfolio.

Child tenant — the client. Each client of the agency is a child tenant. The client tenant carries the client's brand, specialty defaults (paediatric, orthopaedic, IVF, dental, etc.), NMC/ASCI/DPDP compliance settings appropriate for the specialty, and the client-side users (marketing head, hospital CMO, practice owner) who see only their own data.

Grandchild tenant — the location. Each of the client's physical locations is a grandchild tenant. The location tenant carries the specific Google Business Profile, its Rank OS score, its action queue, its competitor set, its review pipeline, and its Post publishing schedule. A single-location clinic has one grandchild tenant under one child tenant; a 50-location hospital chain has 50 grandchild tenants under one child tenant.

The tree can extend if needed. Enterprise setups sometimes add a fourth layer between client and location (region, brand under a holding company, etc.), but the default three-layer tree fits 95% of healthcare-agency portfolios cleanly.

Role-based access across the hierarchy

Each role has a natural altitude in the tree at which it operates.

Agency Admin. Operates at the parent-tenant altitude. Full visibility and edit rights across every child and grandchild tenant. Typically 1-3 users per agency — founder, head of operations, head of client success.

Operations Specialist. Operates cross-portfolio at the parent altitude with execution rights on every grandchild tenant. Runs Geo-Grid scans, publishes Posts, executes citation building, responds to reviews across the portfolio. Typically 4-10 users per agency.

Account Manager. Operates at the child-tenant altitude for assigned clients only. Full visibility and edit rights on the assigned clients' child tenant and all its grandchild tenants; no visibility of other clients. Typically 10-30 users per agency, each managing 8-20 clients.

Compliance Reviewer. Operates cross-portfolio at the parent altitude with approval-gate rights on content publishing. Reviews AI-drafted content before publish across every client. Typically 2-4 users at a healthcare-focused agency.

Client Read-Only. Operates at the child-tenant altitude for own client only. Full visibility, no edit rights. Client teams (marketing head, hospital CMO) see their own Rank OS scores, action queues, monthly reports.

Client Editor. Optional role. Operates at the child-tenant altitude for own client with edit rights on their own content but no visibility of other clients. For clients who want to draft their own Posts or reply to their own reviews while the agency handles the rest.

The altitude model makes access predictable. A user's role tells you exactly which tenants they can see and what they can do at each altitude.

Data segmentation and security boundaries

The tenant tree is not just a UI convenience; it is a data segmentation boundary enforced at the platform layer.

Grandchild tenant data (Rank OS score, action queue, review pipeline, competitor snapshots) is scoped to its parent child tenant. Users without access to that child tenant cannot query, export, or view the grandchild's data. Cross-child data cannot leak through shared caches, shared queries, or shared reports.

Parent-tenant data (agency-wide settings, cross-client analytics, portfolio dashboards) is scoped to Agency Admin and Operations Specialist roles only. Account managers see aggregated data only for their assigned clients.

The segmentation also aligns with DPDP Act 2023 data-processing obligations for Indian healthcare — patient identifiers (if collected during review workflows) are scoped to the specific client tenant that owns the data, and the agency's cross-client operations do not create incidental access to identifiers of clients the operations user is not assigned to.

Billing hierarchies and credit allocation

Billing follows the tenant tree.

The agency pays Angryturtle for the platform subscription at the parent tenant level. The subscription tier determines the total profile count included, the credit pool for Geo-Grid scans and Ask Maps analyses, and the white-label feature availability.

AI Overview readiness scoring on every healthcare query for the listing's specialty × city" loading="lazy" decoding="async" style="width:100%;height:auto;display:block;">

Credits are allocated from the parent pool to child tenants. Agency Admin sets each client's monthly credit budget for Rank OS scans, Geo-Grid scans, Pin Checker tests, and Ask Maps analyses. Client-level credit consumption is tracked separately per child tenant, with low-credit alerts firing on individual client approach to budget exhaustion.

Grandchild tenants (locations) draw from their parent child tenant's credit pool. A hospital chain with 12 locations shares the client-level credit budget across all 12 locations; a solo clinic with 1 location has its full client-level budget available for that single location.

The agency's month-end reconciliation becomes straightforward. Each client's consumed credits, executed operations, and delivered outputs are attributable to their child tenant. Invoicing the client (whether at fixed-fee or usage-based structure) uses child-tenant data directly.

Sample setup for a 30-client, 200-location agency

Consider a healthcare-focused marketing agency in India with 30 clients and 200 total physical locations across the portfolio — a common mid-sized configuration.

The agency is the parent tenant. Under it, 30 child tenants — one per client. Under those 30 child tenants, 200 grandchild tenants distributed as: 12 clients with 1 location each (solo clinics), 10 clients with 2-8 locations each (small chains), 6 clients with 10-25 locations each (mid-sized chains), 2 clients with 40+ locations each (large chains).

User roster at the agency: 2 Agency Admin (founder, head of ops); 6 Operations Specialists (execution across the 200 locations); 12 Account Managers (each managing 2-3 clients averaging 15-20 locations); 3 Compliance Reviewers (content approval across the portfolio).

User roster on the client side: approximately 60 Client Read-Only users total across the 30 clients (2 per client on average — marketing head plus one deputy).

Credit allocation: agency subscription includes total credit pool for the portfolio; Agency Admin allocates monthly credits per client based on tier and scope. Large chain clients get higher credit budgets for cross-location Geo-Grid scanning; solo clinic clients get smaller budgets appropriate to single-location operations.

Portfolio-wide operations: Operations Specialists run cross-portfolio Geo-Grid scans on Friday for end-of-week reporting. Content Studio drafting runs continuously across every location, with Compliance Reviewers approving in bulk. Review response operations run per-location per-day.

Month-end: each client child tenant produces a white-label monthly report auto-generated by the platform, delivered by the assigned Account Manager. Billing reconciliation is automatic — each client's consumed credits, executed operations, and outputs are attributable via child tenant data.

What breaks without tenant hierarchies

Agencies running flat multi-account platforms at 200-location scale hit three specific breakdowns.

Cross-client accidents. Operations specialists publishing a Post on the wrong client's profile. Compliance reviewers approving content on the wrong client. Review responses sent from the wrong client identity. Each accident carries reputational cost that scales with client sensitivity — a mistake on a large hospital chain client is materially more damaging than on a small clinic.

Reporting reconstruction. Client reports assembled manually from flat platform exports, with per-location filters applied by hand. A 60-hour month-end reconstruction task for a 30-client portfolio.

Billing disputes. Clients contesting month-end invoices because credit consumption attribution is unclear. Agency margins consumed by write-offs to preserve client relationships.

Tenant hierarchies eliminate all three by structure. The boundaries are automatic; the attribution is automatic; the reporting is automatic.

The compliance perimeter for multi-tenant healthcare agencies

Multi-tenant architecture in Indian healthcare intersects with several regulatory obligations.

DPDP Act 2023 obligations apply per tenant — each client tenant is a separate data fiduciary from the agency's standpoint, and patient identifiers scoped to a client tenant cannot be processed for other client tenants' purposes.

NMC ethics restrictions apply per client — the specialty-appropriate compliance defaults per child tenant enforce restrictions on content publishing that would violate NMC guidance.

ASCI substantiation requirements apply per client — claims made on any location tenant's profile must be substantiable, and the substantiation record is stored at the client tenant level.

PC-PNDT and ART Act obligations apply to specific specialty tenants (fertility, imaging) and their location tenants — the platform's specialty defaults trigger stricter content-approval workflows for these tenants.

The tool ICG uses to run this at scale: Angryturtle

ICG runs local SEO and GBP intelligence for 150+ Indian healthcare brands using Angryturtle — our own AI-native GBP intelligence and management OS. The platform scores every profile 0-100 via a proprietary Rank OS model with five weighted dimensions (Relevance, Review Health, Freshness, Entity Authority, AIO Readiness), publishes edits, Posts, media, and review replies directly to Google, and includes Ask Maps AIO Readiness scoring for Google AI Overviews and ChatGPT visibility.

Available in two shapes: self-serve at ₹999/- per month for solo owners with 1-2 profiles, and ICG's managed service from ₹25,000/- per month where our healthcare specialists execute inside the same platform. Both are anchored in the Healthcare Local SEO Agency India pillar page which has full scope, methodology and pricing.

Book a demo on WhatsApp → or start a free trial at angryturtle.ai →

When tenant hierarchies are the right fit

Right fit for: healthcare-focused marketing agencies managing 10+ client accounts with any degree of location-count variance across clients; agencies scaling from a founder-led boutique to a distributed team; agencies with distinct compliance-review workflows.

Overkill for: solo consultants managing 1-3 client accounts total; agencies with all clients at exactly one location each; non-healthcare agencies where the compliance defaults do not apply.

Absolutely necessary for: agencies with 30+ clients, any client with 5+ locations, any workflow where a cross-client accident carries reputational or regulatory cost.

Related reading

• Healthcare local SEO agency India — pillar service page
• Angryturtle Multi-tenant Agency OS explained
• Angryturtle Rank OS explained
• Multi-location GBP management for Indian healthcare
• Hospital chain local SEO India guide

FAQ

What is a tenant hierarchy in Angryturtle? A three-layer tree: agency (parent tenant) → clients (child tenants) → locations (grandchild tenants). Each layer has its own settings, users, data boundaries, and credit allocation.

Can Angryturtle handle a 30-client, 200-location agency? Yes. This is the design target for the Agency tier. ICG runs 150+ healthcare clients across substantially more locations on the same architecture.

What is the difference between a client tenant and a location tenant? Client tenant is the business relationship — one client, one contract, one brand, one compliance profile. Location tenant is the physical operating unit — one Google Business Profile, one Rank OS score, one action queue.

Can a location belong to more than one client tenant? No. Each location tenant has exactly one parent client tenant. If a physical facility is jointly operated by two legal entities, the arrangement is modelled as two location tenants (one per client) rather than one shared location.

Do client-side users get to see other clients? No. Client Read-Only and Client Editor roles are scoped to their own child tenant. No cross-client visibility.

How is billing structured across the hierarchy? The agency pays Angryturtle at parent-tenant level. Credits are allocated from the parent pool to child tenants. Client-level credit consumption is tracked separately. Month-end billing reconciliation to each client uses child-tenant data.

Can I add a fourth layer for regions or brand families? Yes, at Enterprise tier. Custom hierarchies with 4+ layers are supported for large agencies with regional structures or brand groupings under a holding company.

How does DPDP Act 2023 compliance work across tenants? Each client tenant is a separate data fiduciary. Patient identifiers scoped to one client tenant cannot be processed for other client tenants' purposes. The platform enforces the boundary structurally.

What happens if I churn a client — how does the client tenant handle offboarding? The client tenant archives with all data preserved for the contractual retention window. The agency's access is removed on the offboarding date; the archived data can be handed to the client or purged per contract terms.

Does Angryturtle's API expose the tenant hierarchy? Yes. Agency OS API endpoints support programmatic access to parent, child, and grandchild tenant data with the same role-based access control enforced.

How is this different from Angryturtle's Multi-tenant Agency OS explained separately? Multi-tenant Agency OS is the overall product concept; tenant hierarchies are the specific architectural pattern for how tenants nest. Agency OS covers the roles, reporting, white-label, and portal features that operate on top of the hierarchy.