1.0
Separate where it matters
Each product can have distinct sender domains, inbound routes, policy, and approved knowledge sources.
- Sender identity
- Policy rules
- Knowledge sources
Home
Solution
Multi-product support
Run support for multiple products from one workspace while keeping identities, policies, knowledge, and customers scoped.
Products
Many
Projects separate support configuration.
Workspace
One
Operators keep a shared command center.
Scope
Strict
Knowledge and policy stay project-bound.
2.0
Unify where it helps
Teams still get one dashboard, approval queue, audit log, and analytics view across the workspace.
- Command center
- Approval queue
- Workspace analytics
Operations
What this means in production.
These pages describe the product contract behind the UI, not a decorative brochure. Each surface should connect back to the same governed support loop.
Control boundary
Project access is explicit.
Operator workflow
Support moves through secure ingest, AI preparation, human approval, outbound execution, and audit evidence.
Configuration impact
Provider setup, project policies, knowledge trust, retention, and billing limits decide how this behaves for a real workspace.
Proof points
Designed for governed support, not hidden autonomy.
Project access is explicit.
Thread context carries project identity.
Customer records preserve project history.
References
Official stack and legal references.
These external links point to provider documentation, privacy notices, data-processing terms, or platform terms that shape production operation.