Dashboard Features

The app uses a left sidebar for navigation (Inbox, Knowledge, Analytics, Install widget, Settings (owners), and Platform metrics for platform admins). The top bar shows the Chat9 brand, your email, and Log out.

Install widget (/dashboard)

• Your Bot ID — your bot's public_id, used in the widget embed snippet (the value of data-bot-id). Safe to expose in page HTML.
• Embed code — HTML snippet that loads the widget loader (widget.getchat9.live/widget.js) with your bot's public_id via data-bot-id, then calls Chat9Widget.start() to mount the chat. Copy the block; code areas use an inline copy icon.
• If the OpenAI API key is not set, a red banner at the top of every page (with an Add key button for owners) points to Settings → Bot to configure it.

Knowledge (/knowledge)

Formerly /documents — that route is removed; use Knowledge.

• Supported formats: PDF, Markdown (.md, .mdx), HTML (.html, .htm), Swagger/OpenAPI (.json, .yaml, .yml), Word (.docx, .doc), plain text (.txt).

• Profile tab: review the extracted product profile, glossary, and editable topics derived from your docs. These topics are documentation themes, not necessarily strict product module names.

• FAQ tab: review auto-generated FAQ candidates extracted from your knowledge base. Approve, reject, or edit each candidate — approved FAQs are used to answer common questions directly without a full retrieval pass. "Accept all" is available for quick bulk moderation.

• Unanswered tab: questions visitors asked in the last 30 days that the bot could not answer, or where it offered a human. Answer drafts a reply with your OpenAI key; edit it or ask the agent to rewrite it, then publish it to the bot's FAQ (publishing is owner-only; operators can save drafts). Mark a question Not needed (with a reason) or restore it; the Show filter switches between Open, Answered and Not needed. The Knowledge item in the sidebar shows how many questions became open since you last opened the tab. Owners and operators both see it.

• OpenAPI ingestion: API specs are split into operation-aware chunks, with extra request/response schema detail for larger endpoints.

• Limits: e.g. max file size 50 MB (see product limits); embedding runs asynchronously after upload/trigger.

• Status: Documents move through ready → embedding → ready or error; the UI polls the API until embedding finishes.

• Health: After embedding, each document gets a health score (0–100). Chat9 runs a set of rule-based checks and flags issues that can hurt retrieval quality:

  Issue	Severity	What it means
  Empty or too short	High / Medium	No readable text, or under ~80 words — too little content for reliable retrieval
  Parse / extraction issue	High / Medium	Null or replacement characters, or the text is noisy and symbol-heavy — suggests the file didn't extract cleanly
  Poor structure (Markdown)	High / Medium	A section is very long without subheadings, or a long document has almost no headings — different topics end up in the same chunks
  Incomplete section	Medium / Low	An empty heading, an unclosed code block, or the document ends mid-sentence

  A Re-check button runs the health check again after you've improved the document. Health issues are informational — the document still works, but fixing them improves answer accuracy.

• Delete: Removes the document and its embeddings.

• URL sources: Add a documentation website by URL, track crawl/index status, review recent runs, and manage exclusions. When adding a source you can set a crawl schedule:

  Schedule	Behavior
  Weekly (default)	Chat9 automatically re-crawls the source once a week
  Daily	Re-crawls every day
  Manual	No automatic re-crawl; you trigger it yourself

  You can also trigger a manual refresh at any time from the source row. There is a 1-hour cooldown between manual refresh requests to prevent accidental hammering.

• Indexed pages: Inside a URL source, you can remove one indexed page without deleting the whole source. Removed pages stay excluded from future refreshes for that source.

• External sources: Cards for future connectors (e.g. GitHub) plus a unified table of indexed sources.

Settings → Bot (/settings)

• OpenAI API key — per-tenant key, encrypted at rest; required for embeddings, chat, and document health checks. Save, replace, or remove the key from this page. Removing it asks for confirmation.

• Instructions — shown as two parts. The standard instructions are read-only and maintained by Chat9 — they set your bot's baseline support-agent persona, tone, and ground rules, and are updated centrally as Chat9 improves them. Your additions is a textarea (up to 3 000 characters, with a character counter) where you add anything specific to your product on top of the standard instructions. The placeholder {product_name} is replaced at runtime with the product name extracted from your knowledge base.

  • A "Use only my own prompt" toggle lets you drop the standard instructions entirely and run on your own text alone — use it if you want full control over your bot's persona instead of building on the Chat9 default.
  • Either way, Chat9's core product rules (grounding answers in your documentation, escalation behavior, formatting) always apply on top and cannot be overridden.
  • When you create a bot and provide a website URL at signup, Chat9 auto-extracts a short company description from that page and adds it to your instructions in the background.

• Response detail — Detailed / Standard / Corporate. Controls how much technical depth the bot includes in answers; it applies to every chat. See the description of each level when selecting it.

• Escalation — support email address that receives L2 escalation tickets, and an optional escalation language override (pins the language of tenant-side ticket artifacts independently of what language end users write in — see Language Support for the full picture).

Inbox (/inbox)

Every conversation your visitors have had with the bot, and the place where a person steps in.

• Needs attention: the default view — visitors waiting for a human (an open escalation ticket nobody has answered yet, longest wait first) and conversations an operator is currently holding. Once you have replied — in the conversation, or by e-mail to the visitor — and the conversation is back with the bot, it leaves this view, even if the ticket is still open; if the visitor asks for a human again, it comes back. The count of visitors waiting shows as a badge next to Inbox in the sidebar.
• All: every conversation, newest activity first, including the ones the bot is handling on its own. Sessions with no messages at all are not listed.
• One row per visitor: when the same visitor writes again — from another device, after clearing their browser, or days later — their conversations are grouped into one row and read as one continuous thread, and your reply goes to the conversation they are in now. Grouping uses the user_id your site passes to the widget in userHints; if you have an identity key, it also needs a valid user_hash from identity verification. Visitors known only by an e-mail address stay one row per conversation: an address typed into a public chat proves nothing, and grouping on it could send your reply to someone else.
• Search: find a visitor by name, e-mail or ticket number (for example ESC-0742). The search runs over the whole history of the selected view, not just the rows on screen.
• Thread view: the visitor's full history — visitor messages, bot answers and operator replies are styled differently, and operator replies show who wrote them. Bot and operator replies render formatting (lists, links, code); your own replies are labelled You.
• Reply: type and send; the visitor sees the reply in the widget within a few seconds, signed as Support in the language of the conversation. Sending a reply takes the conversation: the bot stays silent while you hold it.
• Missed replies go out by e-mail: if the visitor has not had your reply on screen within five minutes — the widget is collapsed, the tab is in the background, or they have left the page — Chat9 e-mails them the reply text as you wrote it, to the address from their escalation request or the one your site passed to the widget. Several replies in a row arrive as one e-mail, and its Reply-To is your support inbox. A visitor with no known address is not e-mailed.
• Take / Return to bot: take a conversation before you write, or hand it back to the bot explicitly. If you go quiet, the bot resumes on the visitor's next message after the idle window on its own.
• Mark resolved: closes every open escalation ticket of the visitor (with an optional note), retires their e-mail reply addresses, and returns the conversation to the bot. The row leaves Needs attention.
• Seats: anybody in the tenant can read the Inbox. Replying, taking, returning and resolving need an operator seat (Settings → Seats). A reply sent by e-mail from a seat holder lands in the same thread and looks the same as one sent here.

Chat9 does not assign conversations. A held conversation shows who holds it, and a colleague can still answer in it.

Response controls

Set the response detail level (Detailed / Standard / Corporate) from Settings → Bot. The three levels:

• Detailed — full technical depth: paths, diagnostics, vendor/tool names.
• Standard — plain language; avoids internal paths, stack traces, and vendor error names.
• Corporate — polished, non-technical tone; no ETAs or deep technical detail; offers a support contact for ongoing issues.

Settings → Widget (/widget-settings)

• Identity verification — optional owner-only section to generate, reveal/copy, and rotate the key used to verify a visitor's user_id. Without a key, user IDs are trusted as-is; with a key, only verified visitors restore conversations across devices. Rotating replaces the key immediately; requests still signed with the old key stop verifying.
• See Embedding the Widget → Identity verification for the full setup guide.

Escalation tickets

A ticket is created automatically whenever a conversation is escalated. Tickets live inside the conversation: open the visitor in Inbox to see the ticket number, its trigger and priority, answer, and mark it resolved.

What triggers escalation:

What happens when a ticket is created:

• The visitor's chat stays open — they can keep talking to the bot while your team works the ticket. Nothing closes it, not even the visitor saying they need nothing further; the conversation only rolls over into a new one after a week of silence.
• An email notification is sent to the support email configured in Settings → Bot. When the tenant has a seat holder, the e-mail also links straight to the conversation in the Inbox, and replying to it from a seat holder's mailbox lands the reply in the thread.
• The conversation appears under Inbox → Needs attention with a sequential ticket number (e.g. ESC-42).
• Tickets whose conversation has gone quiet are closed automatically. That only clears the queue; it does not mean anyone answered.

Ticket priority (shown in the thread header):

Priority is set from the plan_tier field in userHints (enterprise or pro → elevated priority). See Embedding the Widget → userHints.

Platform metrics (/admin/metrics)

• Visible only to users with is_admin. Platform-wide usage metrics.