How do you handle support for multiple brands under one agent team?

A common architectural challenge emerges when scaling customer support operations: a single agent team must provide service for multiple, distinct brands while maintaining strict data isolation and brand-specific workflows. This is not merely a UI routing problem; it is a data modeling and pipeline challenge that mirrors multi-tenant SaaS design. I've architected several such systems, and the critical failure point is usually conflating identity at the application layer.

The core requirement is a **unified agent interface** that dynamically adapts to the brand context of each incoming interaction, while all reporting, routing, and data access is scoped accordingly. This requires a foundational data model that treats `brand_id` as a primary key across all support objects. Consider the following simplified schema concept for a supporting data warehouse:

```sql
-- Core fact table for interactions
CREATE TABLE fact_interactions (
interaction_id VARCHAR(255),
brand_id VARCHAR(255) NOT NULL, -- Partition key in most systems
channel_id VARCHAR(255),
agent_id VARCHAR(255),
customer_id VARCHAR(255),
started_at TIMESTAMP_NTZ,
resolved_at TIMESTAMP_NTZ,
-- ... other facts
);

-- Dimension for brand-specific configurations
CREATE TABLE dim_brand_routing (
brand_id VARCHAR(255),
support_email VARCHAR(255),
default_queue_id VARCHAR(255),
sla_priority INTEGER,
allowed_channels ARRAY,
brand_timezone VARCHAR(50)
);
```

The implementation playbook typically follows these phases:

* **Phase 1: Identity & Routing Layer (Weeks 0-2)**
* All incoming tickets/conversations must be tagged with a `brand_id` at ingestion. This is often derived from the source email domain (e.g., `@brandA.com`), a subdomain in chat widgets, or an API key.
* Routing rules (omni-channel queues) are built as brand-specific sub-queues or using dynamic priority based on the `dim_brand_routing` table.
* Agent permissions are mapped to brands via a junction table (`agent_id`, `brand_id`), allowing for cross-brand agents or specialists.

* **Phase 2: Unified Agent Workspace Configuration (Weeks 3-5)**
* The agent UI (e.g., a customized Zendesk, Kustomer, or custom React app) uses the `brand_id` context to:
* Pull the correct brand logo, color scheme, and greeting templates.
* Filter macro and Canned Response libraries.
* Scope knowledge base article searches.
* Enforce brand-specific SLA timers and escalation paths.

* **Phase 3: Data Pipeline & Reporting Isolation (Weeks 6-8)**
* ETL processes from the support platform (via API or event stream) must preserve and propagate the `brand_id` to the data warehouse.
* All downstream dashboards and reports are filtered by `brand_id` by default, with role-based access control governing which analysts can see aggregated vs. brand-specific data.
* Cost allocation (for cloud platforms like Snowflake/BigQuery) can be isolated by brand for chargeback using tag/query labels filtered on `brand_id`.

The primary trade-off is between **agent efficiency** (one login, skill-based routing across brands) and **operational risk** (potential for brand context errors). Mitigation requires rigorous UI design and data auditing. I am particularly interested in how others have solved the reporting layer—do you maintain a single consolidated dataset with `brand_id` as a filter, or do you create physically separate data marts for each brand for compliance reasons?

- Mike