Why "one platform, several brands" is harder than it sounds
A multi-brand retailer generally cannot let one brand’s customer see or infer another brand’s data, workflows, or agent pool — both for customer-experience reasons (each brand’s voice should feel deliberate and distinct) and, depending on the brands involved, for genuine data-separation requirements. At the same time, running each brand on entirely separate, independently-operated infrastructure multiplies operational cost and administrative overhead without a corresponding benefit if the brands share a parent organization’s security and compliance posture anyway. The right architecture needs to deliver brand-level separation without brand-level infrastructure duplication.
What "shared infrastructure, separate operations" actually requires technically
This requires strong tenant-level data isolation (each brand’s conversations, customer records, and knowledge base genuinely separated, not just filtered by a shared application-layer flag that a bug could bypass), brand-specific configuration for workflows, routing rules, IVR scripts, and knowledge content, and separated reporting and analytics per brand — all running on infrastructure the parent organization operates and secures once, rather than once per brand. A platform that can’t deliver genuine data isolation at the brand level forces an uncomfortable choice between real separation (expensive, duplicated infrastructure) and acceptable risk (shared infrastructure with only application-layer separation).
Why schema-per-tenant multi-tenancy is directly relevant to this exact use case
Schema-per-tenant multi-tenancy — where each tenant gets its own dedicated database schema rather than a shared table filtered by a tenant ID column — maps naturally onto a multi-brand structure: each brand can be provisioned as its own tenant, with database-level isolation between brands rather than isolation that depends on every application query correctly filtering by a brand identifier. This is architecturally the same isolation model used between entirely separate customer organizations, applied here to separate brands within one parent company — the isolation guarantee doesn’t weaken just because the brands share a corporate parent.
What stays shared, and what should be brand-specific
Infrastructure operations, base security architecture, and platform-level upgrades are naturally shared and centrally managed, which is exactly where the cost and operational efficiency of a multi-brand structure comes from. Brand voice, IVR scripts, routing logic, knowledge-base content, and reporting views should be configured per brand/tenant, so each brand’s customer-facing experience and each brand’s internal reporting reflect that brand specifically, not a blended cross-brand view. A parent organization typically also wants a rolled-up, cross-brand reporting capability for its own oversight, which is a legitimate additional requirement to scope separately from per-brand isolation.
How this maps to Voz360’s real architecture
Voz360 generates every tenant schema from a single factory definition, so each brand provisioned as its own tenant gets a structurally identical, genuinely isolated schema — not a stripped-down or inconsistent variant. Per-tenant AES-256-GCM encryption under its own DEK and a SHA-256 hash-chained audit log apply at the same tenant (brand) level, so cross-brand data exposure isn’t a lower-priority edge case but the same isolation guarantee applied consistently. Specific configuration for how many brands, what routing and reporting separation looks like, and what (if any) rolled-up cross-brand reporting is needed should be scoped during discovery, since that is an operational design conversation, not a generic platform claim.
Can the vendor tell you — in one sentence — which of their AI capabilities are rule-based, which are generative, and which are still roadmap?