Setup Guide

This guide is for teams moving from first tests to dependable production behavior. You are not just connecting integrations. You are defining how support decisions should behave when real customer pressure hits.

A useful way to approach setup is to think in layers. Start with message ingress, then answer quality, then decision policy, then runtime data, then rollout discipline. If you skip layers or do them out of order, setup usually feels noisy and fragile.

Build the Foundation in the Right Order

Start in Settings -> Organization and confirm your organization details are correct. In the current app state, your organization runs in single-workspace mode, so this is your primary operating context.

Next, connect one inbound support channel in Settings. Pick the channel where your real traffic already exists. For Email Inbox, complete domain verification and forwarding steps. For Intercom, complete connection and confirm status. For Zendesk, complete OAuth, then set webhook URL and webhook secret. A connection badge alone is not enough; always verify end-to-end message flow.

Then open Knowledge -> Library and build your initial support corpus. Keep it focused. Upload sources your agents actually trust during live conversations: pricing rules, policy articles, troubleshooting flows, and account process explanations. Avoid dumping large internal docs that were not written for customer-facing clarity.

As documents enter the system, watch ingestion states. If a document is failed or still processing, do not assume it can ground answers yet. Re-ingest where needed and remove stale duplicates that create conflicting language.

Now move to Knowledge -> Validate. Use advanced validation to test real conversation turns, inspect evidence, and rate outputs as correct or wrong. Add correction notes when needed. This feedback process is what turns “it generated an answer” into “it generated an answer we would stand behind.”

After validation, review Knowledge -> Analysis for health trends. This is where you catch silent quality problems, such as rising failed-document ratios or weak coverage in key collections.

Only after those pieces are stable should you tune routing behavior. In Routing, keep automatic behavior on if you are still early. If you need explicit controls, enable manual mode and define a small set of tags, destinations, and rules. Keep the taxonomy lean. Too many overlapping tags create policy confusion faster than they create precision.

If your use case requires account-specific answers, then add Data Connectors. Start with one provider and one concrete question type. For example: “look up customer subscription state by email.” Keep access scoped and template behavior explicit.

That sequence sounds strict, but it saves time in practice because each step depends on the previous one.

What Teams Usually Get Wrong

Most launch friction comes from a few predictable mistakes.

One common mistake is trying to solve quality with routing changes when the actual issue is weak source content. If answers are generic or uncertain, improve the knowledge layer first.

Another mistake is enabling too much manual control too early. Routing manual mode and connector template controls are powerful, but they add policy surface area. Use them when you have a clear reason, not just because they exist.

Teams also underestimate channel-specific completeness. It is easy to think a channel is “done” after OAuth, then discover inbound events are not reaching conversations due to missing webhook setup, forwarding gaps, or signing secret mismatches.

A fourth mistake is skipping internal dry runs. The fastest teams always run a short internal traffic cycle before external rollout. That cycle catches ownership gaps, escalation surprises, and response tone issues while the blast radius is still small.

Define Launch Readiness Before Launch Day

A strong go-live is mostly a readiness decision, not a bravery decision.

You are ready when a routine question is answered correctly, a sensitive question is escalated predictably, and your team can explain why both outcomes happened. If any of those three is missing, keep iterating before you scale traffic.

A practical readiness pass looks like this:

1. Confirm channel ingress is stable and messages appear in Conversations.
2. Confirm knowledge coverage for top recurring question categories.
3. Confirm validation outputs have acceptable quality and evidence.
4. Confirm routing behavior matches your escalation expectations.
5. Confirm connector tests pass for any account-aware flow.
6. Confirm human takeover in conversation detail works when needed.

If those checks pass, move to rollout.

Roll Out in Controlled Steps

Run launch as a sequence, not a switch.

Start with internal traffic and observe outcomes in Conversations. Then move to a small canary slice of real traffic. Expand only after behavior is stable across answer quality, escalation correctness, and channel reliability.

When issues appear, isolate by layer. If responses are wrong, inspect knowledge and validation evidence first. If escalations are surprising, inspect routing conditions and ownership logic. If messages are missing, inspect channel ingress and webhook configuration. This layer-by-layer debugging approach prevents random changes that create new problems.

The setup process is complete when your team no longer feels like the system is “mysterious.” Instead, they can predict behavior, adjust intentionally, and explain operational decisions with confidence.

From here, move to Key Workflows to see how this setup translates into real day-to-day support execution.