AI Chatbot
Let visitors get instant answers without creating a ticket. The chatbot is a floating chat widget you add to any website with a single script tag. It answers questions using only your knowledge base β the same docs that power your hosted documentation site β and offers a one-click escalation to a real ticket when it canβt help.
Info
The AI chatbot is an Enterprise plan feature. It also requires a published knowledge base, since that is where the answers come from.
How it works
- A visitor clicks the chat bubble and asks a question.
- Scitor searches your knowledge base for relevant articles.
- An AI model writes a short answer grounded in those articles, with links to the sources.
- If nothing relevant is found β or the visitor wants a human β the chat offers a contact form. Submitting it creates a GitHub Issue or Discussion through the same pipeline as web forms, with the chat transcript attached so your team has full context.
The bot answers in the language the visitor writes in.
Setup
1. Enable the chatbot in scitor.yaml
chatbot:
enabled: true
2. Add the widget to your website
Use the form ID from your docs contact form or any form created with /create-form:
<script
src="https://api.scitor.io/widget/chat.js"
data-form="YOUR_FORM_ID"
async
></script>
Thatβs it. The widget renders a floating chat bubble in the corner of the page.
Customization
All customization lives in the chatbot section of scitor.yaml:
chatbot:
enabled: true
locale: nl # UI language: en (default), nl, de, fr
color: "#22C55E" # widget color (defaults to your docs color)
position: left # right (default) or left
title: "Helpdesk" # header title (default: "Support")
escalation: true # allow raising a ticket from the chat (default: true)
| Option | Default | Description |
|---|---|---|
enabled |
false |
Turns the chatbot on. Required. |
locale |
en |
Language of the widget UI: en, nl, de, or fr |
color |
docs color | Primary color of the bubble, header, and buttons (hex) |
position |
right |
Corner where the bubble sits: right or left |
title |
Support |
Title shown in the widget header |
escalation |
true |
Whether visitors can escalate to a contact form |
Overriding individual texts
Every visible string can be overridden, on top of the chosen locale:
chatbot:
enabled: true
locale: en
strings:
greeting: "Hi! Ask me anything about Acme."
escalateButton: "Talk to a human"
Available keys: greeting, inputPlaceholder, send, escalateButton, escalateTitle, escalateNote, nameLabel, emailLabel, subjectLabel, messageLabel, submit, submitted, submittedDetail, noAnswer, quotaExceeded, error, close, openLabel, sourcesLabel, transcriptHeader.
Knowledge sources
The chatbot answers from your knowledge base β the Markdown files in your repositoryβs docs folder. PDF files in the docs folder are indexed too (up to 4 MB each), so you can drop in existing manuals, datasheets, or guides without converting them:
docs/
βββ getting-started/
β βββ index.md
βββ manuals/
βββ router-setup.pdf
After a docs build, new and changed content becomes available to the chatbot within a few hours (the search index refreshes periodically).
Escalation
When the bot canβt answer, it says so and offers a Contact support button (you can also keep it always visible). The escalation form asks for name, email, subject, and message β the subject is pre-filled with the visitorβs first question. The conversation so far is appended to the ticket, and a note above the form tells the visitor that it will be shared.
Escalations go through the exact same pipeline as web form submissions: a GitHub Issue or Discussion is created, AI triage and labels are applied, and you reply with /send as usual.
Staying on topic and abuse prevention
The chatbot is locked to your documentation. Several safeguards are built in and need no configuration:
- Grounded answers only β if your knowledge base doesnβt contain the answer, the bot says it doesnβt know and offers escalation. It never answers from general knowledge, so off-topic requests (recipes, homework, anything unrelated) get a polite refusal.
- Prompt-injection resistance β instructions hidden in visitor messages (βignore your rulesβ, βpretend you areβ¦β) are treated as data, not commands.
- Rate limiting β per-visitor message limits, plus a daily limit per site. When the daily limit is reached, the widget automatically falls back to the contact form, so visitors can always reach you.
- Input limits β messages are capped in length and the conversation context is bounded.
Privacy
Conversations are not stored on Scitorβs servers. The transcript lives in the visitorβs browser for the duration of the tab session and is only persisted if the visitor chooses to escalate β at which point it becomes part of the ticket, like any other form submission.
When the chatbot is unavailable
If the AI assistant is temporarily disabled or your knowledge base isnβt published yet, the widget gracefully degrades: the same chat bubble opens the contact form directly, so visitors can still ask their question.
Was this article helpful?