Skip to main content
Use Chatbot → Setup as the minimum launch checklist for a new AI Chatbot organization. The current setup page tracks three required milestones.

1. Connect an AI model

Open AI → Models and configure the generation model Chatbot will use. Chatbot uses your organization’s BYOK model configuration. Embeddings are also required for semantic retrieval from approved knowledge. Before continuing:
  • verify provider credentials;
  • verify the generation model;
  • verify embedding capability; and
  • test the provider connection.
If your primary provider cannot supply the required embedding model, RAUM can use a separate compatible model configuration. AI models →

2. Create a web channel

Open Chatbot → Channels. A channel defines the browser/security and delivery boundary for the website deployment. At minimum configure:
  • channel name;
  • one or more exact HTTPS origins;
  • active status; and
  • the public widget configuration.
Wildcards are not accepted for production origins. For example, configure the exact site origin rather than a broad domain pattern. A channel can also configure:
  • welcome message;
  • primary color;
  • launcher position;
  • optional Cloudflare Turnstile site key;
  • whether customer attachments are allowed;
  • whether handoff is enabled; and
  • an optional Email, signed Webhook, or Zendesk handoff provider.
Channels →

3. Create, publish, and install a widget

Open Chatbot → Widgets. Configure the widget draft, then publish it. The live widget changes only after Publish. Saving the draft alone does not alter the version currently served to visitors. After publishing:
  1. open the Installation tab;
  2. confirm the allowed origins;
  3. create or rotate the publishable key when needed;
  4. copy the key/snippet while it is displayed; and
  5. install the widget on an allowed website origin.
The publishable key is displayed only when it is created or rotated. It is intended to be browser-visible and origin-bound. Never place an organization API token in website JavaScript.
Install the widget →

Before your first public conversation

The three setup milestones make the widget technically runnable. Before directing real customers to it, also review:
  • Shared Knowledge — approve only customer-safe resources.
  • Forms & Handoffs — make sure low-confidence and human-request paths have somewhere to go.
  • Visitor Identity — decide what anonymous, email-verified, or signed-in users may access.
  • Public connections/actions — keep internal connections private unless explicitly configured and approved.
  • Simulation — test difficult cases and verify public ACTION calls are intercepted.
  • Retention — review conversation, request, action-audit, operational-event, deletion, and legal-hold controls.
  • Topics / visitor data — keep optional collection off unless you intentionally enable and disclose the fields you need.

Test the live installation

After installing the snippet on an allowed origin, verify:
  1. the launcher loads and is styled correctly;
  2. opening the widget creates a usable session;
  3. the selected languages work;
  4. approved knowledge answers are retrieved;
  5. unapproved/internal knowledge is not exposed;
  6. low-confidence behavior routes as expected;
  7. attachments/forms behave according to the draft you published;
  8. public sources require the configured identity tier;
  9. public writes require confirmation and do not execute in Simulation; and
  10. the conversation appears under Chatbot → Conversations.

Current public channel

The production customer-facing channel is the web widget. Internal schema values may anticipate other channel types. Do not plan a deployment around a future channel merely because an enum exists in the database. Software has enough imaginary features without documentation helping.