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.
Set up the product in the order the support loop needs.
Most bad outcomes start when traffic arrives before route, policy, knowledge, or approval controls are ready.
01
Create the workspace and project
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.
Workspace membership is ready.
Project name, website, and support display name are correct.
The project is active before customer traffic is routed to it.
02
Connect email and DNS
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.
Public support address is the one customers will use.
Inbound forwarding points to the generated project route.
Outbound sending stays blocked until the domain is verified.
03
Create policy before trusting drafts
Daily loop
Use the dashboard as a shift checklist.
The app is designed around a repeatable operating loop, not a pile of disconnected pages.
1. Start in DashboardDashboard is the workspace health view. Use it to see queue pressure, setup blockers, risky work, approval debt, and signals before opening individual threads.
Open high-risk or breached-SLA work first.
Use Setup when the workspace is not production-ready.
Use Safety when agent checks, policy state, webhooks, or audit signals need attention.
2. Triage in WorkbenchWorkbench is the hands-on board. It keeps intake, context, draft, approval, sent, and blocked work visible as lanes with required evidence gates.
Routes
Know which page owns which decision.
Use these route groups to move between high-level health, active support work, setup, and governance without guessing.
Operate
Use these routes during a support shift.
DashboardCommand center for queue pressure, setup readiness, safety state, and operating signals.
Start every shift here.
Use tabs to switch between Operate, Setup, Safety, and Signals.
WorkbenchLane-based operator board for moving support work through evidence gates.
Best for active triage.
Channels
Email, widget, voice, and customer updates share the same control model.
Every channel should produce project-scoped support records, policy checks, usage signals, and audit history.
Email supportEmail is the primary V1 channel. Resend webhooks bring messages in, workflows prepare AI output, humans approve, and outbound sends use deterministic server-side policy.
Duplicate webhook deliveries should not create duplicate messages.
Outbound replies require approved draft state and idempotency.
Delivery and side-effect history belongs in Audit.
Assistant WidgetThe widget is a governed support surface, not a generic unmanaged chatbot. It must use allowed domains, rate limits, approved knowledge, escalation paths, and the same policy posture as the project.
Safety
What Tier0 will and will not do.
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.
Troubleshooting
Follow the status signal before changing settings.
Most issues have a specific owner: route, provider, policy, knowledge, role, billing, or audit. Fix the owner rather than weakening the promise.
No support requests appearStart with setup state. Missing requests usually mean the public address, forwarding rule, DNS, webhook configuration, or workspace database path is not ready.
Check project setup and support address.
Verify Resend webhook readiness and DNS state.
Confirm the request was sent to the project’s public address.
Drafts have no citationsThe draft agent can only cite approved project knowledge. If sources are pending, rejected, stale, or scoped to another project, citations should be absent.
Open Knowledge and inspect source trust state.
Roles
Give people the narrowest access that lets them do the work.
The dashboard has owner, admin, operator, viewer, and billing responsibilities. Role boundaries matter because support data and customer-facing actions are sensitive.
Do not change workspace-level billing or retention settings.
Viewer
Read-only monitoring, analytics, audit review.
Do not approve, send, delete, invite, or change policy.
Billing
Plans, credits, seats, invoices, usage review.
Do not edit support policy or customer memory.
Route first
Verified support routes decide where requests belong.
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.
A current policy version exists.
Forbidden promises are concrete phrases, not vague warnings.
Auto-send remains off unless the workspace owner has deliberately enabled a narrow low-risk path.
04
Approve knowledge sources
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.
Sources are scoped to the right project.
Extracted text matches the original source.
Sensitive, outdated, or hostile content is rejected or deleted.
05
Test the full support loop
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.
The message lands in the correct project.
Agent output shows risk, confidence, policy state, and citations where relevant.
Every important action leaves an audit trail.
06
Add account context safely (optional)
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 connector uses read-only credentials and allowlists only support-safe schemas and views.
Lookup SQL uses one statement, SELECT/WITH only, and `email = $1`.
Tool enablement is explicit for Agent drafting and widget after identity requirements are satisfied.
Draft preview for a test thread shows only expected plan/usage/context fields.
Do not treat a draft as ready until source, policy, risk, and approval evidence are complete.
Use the digest when escalating to another operator.
Blocked threads should stay blocked until the missing evidence is resolved.
4. Review drafts in ApprovalsApprovals is where humans decide whether a generated draft can proceed. The model prepares work; it does not own customer-facing outcomes.
Prioritize critical and high-risk drafts.
Reject drafts with weak evidence, policy conflicts, or unsupported promises.
VoiceVoice routes callers into project-scoped intake. Outbound follow-up calls are human-gated and processed via the Support Supervisor queue using LiveKit SIP connectivity.
Assign phone numbers and view call history in the voice panel.
Outbound follow-ups are strictly human-gated; autonomous calling is disabled.
Outbound calls enforce strict 08:00 - 22:00 UTC quiet-hours to prevent intrusive customer outreach.
Fallback and standardized support inquiries are routed to support@driftrail.com.
Customers and broadcastsCustomer memory is for known support context. The broadcast panel is for governed updates to known customers, not cold outreach or marketing automation.
Respect cross-project memory controls.
Send only support-relevant updates to known customers.
Billing, SMS, and email limits must be visible before send.
Re-upload or refresh stale material before expecting stronger answers.
A send or automation is blockedBlocks are intentional. Policy, confidence, risk, role permissions, billing limits, or provider readiness can all stop customer-facing actions.
Read the policy reason before changing settings.
Check role permissions and project status.
Use Audit to confirm whether anything actually happened.
Voice starts without enough contextVoice should fail closed when project context cannot be loaded. It can collect a summary for follow-up, but it should not answer account-specific questions or claim actions completed.
Check project assignment and provider configuration.
Confirm the app context endpoint is reachable.
Review call records before follow-up.
Draft has no customer contextIf account details are missing during support, verify the project data connectors and lookup tools are active for the right draft surface.
Open `/projects/[projectId]/data` and confirm a connector is active.
Confirm the lookup query is one statement, starts with SELECT/WITH, and uses `email = $1`.
Confirm the tool is enabled for Agent drafting and widget where expected.
If you changed schemas or roles, re-run the test thread before production traffic.
Evidence first
Use policy, knowledge, and audit before trusting a draft.
Human owned
Operators remain responsible for customer-facing outcomes.