Your support inbox has patterns. “How do I reset my API key?” shows up every week. “What’s the rate limit on webhooks?” comes in from new customers. “Does your product support SAML SSO?” arrives before a prospect signs up.

You’ve already answered these questions. The answers are in your documentation. But customers don’t always find them, so they open a ticket instead—and your team answers the same question again.

An AI chatbot breaks this loop. When a visitor is reading your docs and has a question, they type it into the chat widget. The chatbot searches your documentation, synthesizes the relevant parts, and answers immediately. No ticket created. No wait for the customer. No repetitive work for your team.

The questions that actually reach your support queue become the ones that need human judgment: bugs, edge cases, account-specific issues.

You can try it right now: the chat widget is live on scitor.io. Click the bubble in the corner and ask it anything about the product.

What the chatbot handles well

The chatbot is built for docs-answerable questions. That covers more than you might think:

How-to questions. “How do I configure webhook retries?” The chatbot finds the relevant section in your docs and returns a clear answer, often with a direct link to the source.

Troubleshooting. “I’m getting a 403 on the API.” Your docs likely cover common authentication errors and status codes. The chatbot walks through it without a ticket being opened.

Pre-sales questions. “Does your product support X?” Prospects evaluating your product need to confirm capabilities before they talk to sales. If the answer is in your feature docs, the chatbot handles it immediately.

Quick clarifications. “Is this limit per minute or per hour?” Short question, immediate answer.

What it doesn’t handle: questions that require access to account data, issues your docs don’t cover yet, and anything that genuinely needs human judgment. When the chatbot doesn’t find a confident answer in your documentation, it says so and offers to open a support ticket instead—with the full conversation already attached so your team has context.

Setup: one script tag, one YAML block

There is no backend to deploy and no separate service to provision.

Step 1: Create a form (if you don’t have one yet).

The widget needs a form ID to route escalations to your GitHub repository. If you haven’t set one up, run this slash command on any issue in your Scitor-connected repo:

/create-form

Scitor replies with a short form ID. You’ll use it in the next step. (If you already have a contact form on your docs site, its ID works too—no need to create a second one.)

Step 2: Add the widget to your site.

Paste one line into your HTML wherever you want the chat bubble to appear:

<script
  src="https://api.scitor.io/widget/chat.js"
  data-form="your-form-id">
</script>

The widget renders a chat icon in the bottom-right corner of the page. Click it and a panel slides open. Works on any page—your marketing site, your docs, your app. Shadow DOM means zero style conflicts with your existing CSS.

Step 3: Enable it in your repository.

In .github/scitor.yaml, add:

chatbot:
  enabled: true
  docs_path: docs/

That’s the entire configuration. On the next push to your main branch, Scitor indexes every markdown file in docs/. Those files become the chatbot’s knowledge base. PDFs work too—any .pdf in your docs folder gets indexed alongside markdown, useful if you have API reference guides or integration specs as PDFs.

Step 4: The fallback is already wired up.

If the chatbot can’t answer, it offers to open a support ticket. This uses the same Scitor contact form you already have—same data-form ID, same GitHub Issues pipeline. The conversation is attached to the new ticket automatically, so your team sees exactly what the customer already tried.

Three steps. No new infrastructure.

The knowledge base lives in your repo

Most chatbot products require a separate admin panel where you upload content, write articles, or maintain a knowledge base. That’s a second system to keep in sync with your actual documentation. When you update your docs, you have to remember to update the chatbot too.

Scitor’s chatbot reads directly from your repository. Your docs are the knowledge base.

When you push a commit that updates an API guide or adds a new tutorial, the chatbot indexes those changes on the next build. The content team, the engineers writing docs alongside code, the pull request that adds a new feature and updates the relevant .md file—all of that flows directly into what the chatbot knows.

This fits how developer teams already work. Documentation lives in the repo as markdown files. You write docs alongside code, review them in pull requests, deploy them as part of the same pipeline. The chatbot inherits all of that without extra process.

No separate content management system. No admin dashboard to keep updated. No sync job to monitor.

What customers actually experience

When a customer clicks the chat icon and types a question:

Their message is matched against your indexed documentation
If relevant content is found, the model synthesizes a response using those excerpts
The response cites which doc files it drew from, shown as clickable links
If the customer wants more detail, the links go directly to the full documentation
If the chatbot can’t answer confidently, it says so and offers the contact form

Retrieval and generation typically complete in a few seconds. Because the chatbot only generates an answer when it finds relevant content in your docs, it doesn’t invent answers it doesn’t know—it declines and escalates instead.

Customers get their answer at the moment they’re reading your docs, not hours later when your team gets to the ticket.

The workload reduction adds up

The math is simple: questions the chatbot handles don’t become tickets. If your team spends 15–20 minutes on a routine how-to ticket, and the chatbot deflects 30 of those per month, that’s 7–10 hours of support time back.

The less obvious benefit is queue quality. When repetitive questions stop arriving as tickets, the ones that do come in are genuinely complex. Your team has more capacity for the issues that actually need debugging, investigation, or escalation to engineering.

And the chatbot works around the clock. A customer in a different timezone at 2am with a question your docs cover? They get an answer immediately—without waking anyone up.

Limits worth knowing

The chatbot performs best when:

Your docs actually cover the questions customers are asking
Your content is clearly written (vague documentation produces vague answers)
Questions are about how the product works, not account-specific data

It’s not a general-purpose assistant. It’s grounded in your documentation. A question about a billing adjustment, a permission change, or a specific account issue won’t get a confident answer—the chatbot says so and offers the form. That’s intentional.

There are rate limits per IP and per tenant to prevent abuse. These are conservative defaults that won’t affect normal usage.

Getting started

The chatbot is part of the Enterprise plan. If you’re already on Enterprise, enable it in .github/scitor.yaml:

chatbot:
  enabled: true
  docs_path: docs/

Push to main. On the next build, the widget activates, your docs get indexed, and the chat button appears on any page with the widget script.

The chatbot ships with support for English, Dutch, German, and French. Add a locale override if your customers aren’t primarily English speakers:

chatbot:
  enabled: true
  docs_path: docs/
  locale: nl

No deployment steps, no provisioning wait. If the script tag is on the page and the flag is in your config, it works.

Deflect common questions with the AI chatbot. Available on the Enterprise plan. Install Scitor from the GitHub Marketplace and follow the setup guide in the docs.

An AI Support Chatbot That Answers Questions Before They Become Tickets