Knowledge base

The bot doesn’t know anything about your product until you tell it. The Docs page in your workspace is where you tell it: each doc is a title plus a markdown body, and every doc you publish becomes something the bot can find and quote.

Docs live at /w/<workspace-id>/<slug>/docs. Reading them needs the docs.read capability, and creating, editing, publishing, scraping or deleting needs docs.write — which member and above hold by default.

Draft and published

Every doc is either a draft or published.

• Draft — visible to your team on the Docs page, invisible to the bot. Half-written notes never leak into a customer-facing reply.
• Published — the bot can search it and read it.

Publishing is a one-click toggle on the doc’s page, and you can flip a whole selection at once from the list (bulk publish, unpublish, or delete). A newly published doc is picked up on the bot’s very next reply — there’s no re-index step and nothing to wait for.

Deleting a doc is a soft delete: it disappears from the list and from the bot immediately.

Writing a doc

The body is GitHub-flavored markdown — headings, lists, tables, fenced code blocks, **bold**, ~~strikethrough~~, links and images all work. The editor has a live preview that renders through the same pipeline as the published page, so what you preview is what your teammates see.

Two hard limits:

• A title is at most 240 characters.
• A body is at most 50,000 characters. That’s a deliberate ceiling — a 200 KB spec pasted into one doc would swamp the bot’s context. Split long material into several docs instead.

The list supports a plain substring search across both title and body, and a filter for drafts vs published.

How a published doc reaches an answer

The bot does not get your whole knowledge base stuffed into every request. Instead:

1. Its instructions include a compact list of every published doc’s title, so it knows what topics you cover before it searches.
2. For any product-specific question it calls a search over your published docs and gets back up to 10 matches (25 if it asks), each as an id, a title, and a ~180-character excerpt.
3. When a result looks right it fetches that doc’s full body and answers from it.
4. It’s instructed to cite the doc’s title in the reply, and to say plainly that it doesn’t know — and offer a human — when nothing matches.

Drafts are refused at both steps, not just filtered from the list. A doc that isn’t published cannot be read by the bot even if it somehow guesses the id.

The transcript records which docs backed each answer, so when a reply is wrong you can see exactly which doc taught it that.

What the search actually matches

The search is a case-insensitive substring match over title and body — not semantic search, not embeddings. Your query is split into words; very short words and common filler (“how”, “what”, “the”, “can”, …) are dropped, and up to eight remaining terms must all appear somewhere in the doc. If nothing matches all of them, it falls back to matching any of them. Results are ordered most-recently- updated first.

That mechanic drives most of the practical advice below.

Writing docs the bot can answer from

• Use the words your customers use, not your internal names. The search is literal. A doc that only ever says “seat” will not be found by a visitor asking about a “license”. Put both words in the doc — a line of “also called a license” is enough.
• One topic per doc. The bot picks one or two docs and reads them whole. A 40-page everything-doc means every answer arrives buried in irrelevant context; a doc per topic means the right one wins the search.
• Put the answer in the body, not just the title. Titles are what the bot browses, but bodies are what it matches on and quotes from.
• Write the question into the doc. If customers ask “why is my card declined”, having that literal phrasing somewhere in the body makes the doc findable.
• State facts plainly, including the negative ones. The bot is told not to invent facts and to hand off when nothing matches, so an explicit “we do not support X” is far more useful than silence — silence just produces a hand-off.
• Keep docs current. Nothing expires a doc. A doc that says “billing is monthly” will keep saying so a year after you switched to annual. Unpublish anything you’re not maintaining.
• Don’t put secrets in a doc. Published docs are material the bot can quote to any visitor, including anonymous ones.

Importing from an existing site

If you already have a help center, docs site or marketing site, you can seed the knowledge base from it. On the Docs page choose Scrape a website and give it one http(s) seed URL.

What happens:

• Vroxy crawls that URL and pages beneath it on the same host and same URL prefix — up to 200 pages, with a per-page size cap and a five-minute overall limit. It identifies itself as vroxyBot/1.0 so you can allow or block it at your own site.
• It extracts the main content of each page (article/main region) and strips navigation, sidebars, footers, share buttons, related-article widgets and comment sections.
• If it finds a real help center (two or more article pages), each article becomes its own doc with its title preserved. Otherwise it treats the pages as one corpus and groups them into a handful of topic docs.
• Every result lands as a draft, with the page it came from recorded as its source URL.

The scrape runs in the background — drafts start appearing on the Docs page shortly after you kick it off, not instantly. Nothing is published automatically: review each draft, fix what the extraction mangled, and publish the ones you want. That review step is the point. Scraping gets you raw material fast; it does not get you a knowledge base.

Bot memory is not the knowledge base

Separately from docs, the bot keeps a short notebook of durable facts — about your workspace and about individual visitors — that it recalls in later conversations. That’s for context (“this customer is on the enterprise plan”), not for product truth. Product truth belongs in published docs. You can read and delete workspace-level notes from the Bot memory page, linked from Settings; a visitor’s notes appear on their chat page.