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

  1. A visitor clicks the chat bubble and asks a question.
  2. Scitor searches your knowledge base for relevant articles.
  3. An AI model writes a short answer grounded in those articles, with links to the sources.
  4. 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?

Scitor β€” Turn GitHub into your support platform