1.0
Separate support by product
Projects prevent one product's policy, sender identity, or knowledge source from leaking into another support queue.
- Support identity
- Inbound route
- Project-scoped knowledge
Home
Product
Projects
Per-product support identities, sender domains, inbound routes, policies, knowledge sources, and setup readiness.
Isolation
Project
Each product keeps its own policy and sources.
Setup
Checklist
Domains, routes, sources, and tests stay visible.
Policy
Versioned
Support behavior changes are tracked.
2.0
Launch with known readiness
The setup checklist shows what is ready for production support and what still needs owner attention.
- Verified sending domain
- Test email
- Approval mode
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
Workspace membership controls access.
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.
Workspace membership controls access.
Project policy changes are versioned.
Knowledge scope is explicit.
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.
Next