I'm building a multi-brand support operation and need routing and permissions

Absolutely — for a multi-brand support operation, you usually want two layers working together:

1. Routing: get each ticket/chat/case to the right team or agent
2. Permissions: ensure each agent only sees and acts on the brands, queues, and data they’re allowed to

Here’s a practical structure you can use.

---

1) Core routing model

Route by brand first

Every inbound item should have a brand identifier attached as early as possible:

• email domain / support alias
• website / widget source
• phone number / IVR path
• app / tenant ID
• customer account metadata
• product line / region if relevant

Then route using rules like:

• Brand
• Channel
• Language
• Region / timezone
• Issue type / intent
• Priority / SLA
• Customer tier

Recommended routing logic

A common order:

1. Identify brand
2. Identify channel
3. Classify intent
4. Check customer tier / SLA
5. Assign queue
6. Assign agent based on skills + availability
7. Fallback to overflow queue

---

2) Permission model

You’ll usually want RBAC + brand scoping.

Roles

Typical roles:

• Agent: handle assigned cases only
• Senior Agent / SME: broader queue access, escalations
• Team Lead: manage team queues, reassign, view team metrics
• Brand Manager: access all cases for one brand
• Operations Admin: manage routing and users across brands
• Super Admin: full access

Brand scope

Every user should have a scope such as:

• Single brand
• Multiple brands
• All brands
• Queue-only access
• Region-only access

Example:

• Agent A: Brand X only, English queue only
• Lead B: Brand X + Brand Y, all queues in those brands
• Ops Admin: all brands, routing config only
• Finance/Legal: restricted case types, read-only

---

3) Data access rules

Define access at the object level:

Case visibility

A user can see a case if:

• they own it
• it’s in one of their queues
• they’re in the case’s brand scope
• they’re on an escalation/watch list
• they have admin privileges

Field-level restrictions

Some fields may need extra protection:

• payment data
• internal notes
• identity verification info
• legal/compliance tags

You may want:

• masked fields for normal agents
• full view for approved roles
• audit logging on sensitive access

---

4) Queue design

Use queues that are both brand-aware and skill-aware.

Suggested queue structure

• Brand A > General Support
• Brand A > Billing
• Brand A > Technical
• Brand B > General Support
• Brand B > VIP
• Shared > After-hours
• Shared > Escalations

This helps avoid mixing all brands into one giant queue unless that’s intentional.

---

5) Skill-based routing

Add skills to agents:

• Brand knowledge
• Product line knowledge
• Language
• Priority handling
• Compliance certification

Then match tickets to:

• eligible brand access
• required skills
• current workload
• SLA urgency

A simple scoring approach works well:

• +100 if brand eligible
• +50 if skill match
• +30 if language match
• +20 if not overloaded
• -50 if near capacity

---

6) Common permission patterns

Pattern A: Strict separation

Each brand has its own team and data boundary.

• safest
• simplest governance
• harder to flex staffing

Pattern B: Shared agents, brand-scoped access

Agents can work multiple brands, but only those explicitly assigned.

• good for efficiency
• needs strong RBAC and auditing

Pattern C: Centralized triage, segmented fulfillment

A central team routes and triages; brand teams handle resolution.

• good for larger orgs
• requires careful permissions

---

7) Audit and compliance

You’ll want logs for:

• who viewed a case
• who edited it
• who reassigned it
• who changed routing rules
• who exported data

This is especially important if brands have different:

• privacy rules
• SLAs
• contractual obligations
• regulated data requirements

---

8) Recommended implementation blueprint

Minimum entities

• Brand
• User
• Role
• Queue
• Case/Ticket
• Skill
• Routing Rule
• Audit Log

Important relationships

• User ↔ Brand access
• User ↔ Queue membership
• User ↔ Role
• Queue ↔ Brand
• Ticket ↔ Brand
• Ticket ↔ Queue
• Ticket ↔ Assignment

---

9) Practical example

Example rule set

• If brand = Brand A and channel = email and intent = billing, send to Brand A Billing Queue
• If brand = Brand B and priority = VIP, send to Brand B VIP Queue
• If language = Spanish, route to Spanish-capable agent within that brand
• If no eligible agent is available in 5 minutes, overflow to Shared Escalation Queue

Example access rules

• Brand A agents can only open Brand A cases
• Leads can reassign within Brand A
• Ops admins can modify routing, but cannot see sensitive PII unless explicitly granted
• Shared service desk can triage all brands, but only with masked customer data

---

10) Questions to finalize the design

If you want, I can turn this into a concrete routing/permissions matrix. Helpful details:

1. How many brands do you support?
2. Do agents work across multiple brands or only one?
3. Are there separate legal entities/compliance boundaries by brand?
4. What channels are included: email, chat, phone, social, portal?
5. Do you need customer self-service or only agent routing?
6. What platform are you using or building on?

If you share those, I can propose:

• a role matrix
• a routing rule table
• a queue architecture
• and a recommended permission model tailored to your setup.