Use Tier0 as a controlled support cockpit: connect verified routes, approve project policy and knowledge, let agents prepare structured work, then keep humans and deterministic policy in charge of customer-facing actions.
Most bad outcomes start when traffic arrives before route, policy, knowledge, or approval controls are ready.
Start in onboarding, then create one project per product, brand, or support identity. A project owns the public support name, website, route, policy, knowledge, assistant widget, and optional voice number.
Use the project setup guide to verify the sending domain and route inbound mail. Tier0 is not a hosted mailbox; it processes verified support traffic and drafts governed replies.
Policy is the rulebook for the project. Keep refund rules, escalation language, forbidden promises, high-risk intents, and confidence thresholds explicit before agents draft against them.
Upload or capture sources, inspect the extracted text, then approve only the sources that are safe for agents and widgets to cite. Unapproved or stale sources should not shape customer replies.
Send a safe test request through the real route. Confirm it appears in Inbox, Workbench, Dashboard, and Audit before sending production customers through the project.
Connect read-only project data sources for support cases that need current account state. Choose a safe Postgres or relay path, define strict query tools, and enable them only on the surface that needs them.
The app is designed around a repeatable operating loop, not a pile of disconnected pages.
Use these route groups to move between high-level health, active support work, setup, and governance without guessing.
Use these routes during a support shift.
Use these routes before production traffic or when project rules change.
Use these routes to keep the system bounded and inspectable.
Every channel should produce project-scoped support records, policy checks, usage signals, and audit history.
This is the boundary operators should rely on when the dashboard shows a draft, policy decision, or action proposal.
AI can classify, summarize, cite, draft, and propose. It cannot send, refund, cancel, delete, change policy, invite users, or read secrets.
Every customer-facing side effect must pass deterministic server policy and leave audit history.
Customer messages, uploaded documents, web pages, transcripts, and notes are untrusted input until normalized and scoped.
Use the least-privileged role that can do the work.
Most issues have a specific owner: route, provider, policy, knowledge, role, billing, or audit. Fix the owner rather than weakening the promise.
The dashboard has owner, admin, operator, viewer, and billing responsibilities. Role boundaries matter because support data and customer-facing actions are sensitive.
Billing, workspace setup, integrations, critical controls.
Do not use ownership to bypass evidence gates.
Project setup, policies, knowledge approval, security review.
Do not loosen policy to make a single draft pass.
Triage, thread review, approvals, customer context.
Do not change workspace-level billing or retention settings.
Read-only monitoring, analytics, audit review.
Do not approve, send, delete, invite, or change policy.
Plans, credits, seats, invoices, usage review.
Do not edit support policy or customer memory.
Verified support routes decide where requests belong.
Use policy, knowledge, and audit before trusting a draft.
Operators remain responsible for customer-facing outcomes.