Knowledge | Yaplet

Where to find it

Brand → Knowledge. The page heading reads Knowledge sources.

There is no organisation-wide list of knowledge bases any more, no organisation-wide list of documentation sets, and no Context tab on the AI agent. You see one brand's knowledge at a time; switching brand switches the list.

The content belongs to the brand, not to a chatbot. Whatever sits on this screen is what the brand's AI answers from — in chat, on phone calls, in the inbox's suggested replies and in AI social posts. There is nothing to attach and nothing to connect.

The two halves of the screen

Knowledge bases & documentation

The top half, headed Knowledge base & documentation on screen. Structured content you write and organise yourself: knowledge bases (articles for customers) and documentation sets (technical pages). One of each can also be served on your public web address.

Everything else your AI reads

The bottom half. Pasted text, question-and-answer pairs, uploaded files, website pages we have read for you, and API tools. None of these are ever public — they exist only to be read by the AI.

What the columns mean

Column	What it tells you
Name	Opens the editor for that knowledge base or documentation set.
Type	The screen shows Knowledge base or Documentation.
Language	The language the content is written in. It decides how the AI searches the text, and it translates nothing. You change it straight in the table; a `+n` beside it means extra translations are configured.
Items	Articles in a knowledge base, pages in a documentation set. Drafts are counted too.
Public site	Live — visitors reach this one at your web address — or Hidden. Only one knowledge base and one documentation set can be Live at a time.
Indexed	How many searchable pieces the AI has stored from it. One article usually becomes several, and only published items are stored. A dash means nothing is stored yet.

Being on the public site is not the same thing as publishing. Live and Hidden decide which source visitors reach at your web address. Published is a separate switch on each individual article, on each documentation page and on each documentation category: it decides whether that item is shown at all, and whether the AI can read it. Knowledge base categories have no Published switch of their own. An unpublished article is a draft — it still exists, it is simply not shown and not indexed.

Publishing an article is what teaches the AI

Publishing indexes the article immediately. No chat widget and no AI agent are needed for it, so a brand with no chat bubble anywhere still builds up the knowledge its phone agent and its inbox suggestions answer from. Unpublishing removes it again, and editing a published article re-indexes just that article.

Who can open this screen

A team member needs any one of three rights: Vex, Knowledge base or Documentation. Inside, each half checks its own — knowledge-base rows need Knowledge base, documentation rows need Documentation, and the bottom half is shown only to Vex holders. If your plan does not include the Documentation module, New documentation appears as a locked "Documentation — upgrade to add" entry instead of failing when you click it.

Indexed items on the free plan

Free accounts — and accounts that bought individual modules only — share 250 indexed items across the whole organisation, shown on this screen as "212 of 250 indexed items used". Everything the AI reads draws on it: knowledge base articles, documentation pages, uploaded files, website pages and Q&A entries, in every brand. One article is usually several indexed items. At the cap, publishing new articles and adding new sources is paused until you remove something or upgrade. See Free plan limits for the full breakdown.

Knowledge base or documentation

Yaplet gives you two kinds of structured content. They serve different readers, and a brand can hold both.

Knowledge base

Purpose: Customer-facing help articles in plain, conversational language

Content style: Text and sentences, written with flexible HTML editing

Editor: HTML Article Editor

Where people read it: Your public web address when it is the one being served, and the chat widget's Help tab

Best for: Support questions, FAQs, troubleshooting, product tutorials

Documentation

Purpose: Technical documentation with structured, developer-focused content

Content style: Formatted technical detail built from markdown components

Editor: Markdown Article Editor

Where people read it: Your public web address when it is the one being served

Best for: API references, technical specs, developer guides, structured manuals

Both feed the AI in exactly the same way, whether or not they are on your public address.

When to use a knowledge base

Choose a knowledge base when your readers are customers who want a quick answer to a common question.

Support questions: "How do I reset my password?" or "How do I upgrade my plan?"
Product tutorials: step-by-step guides to using your features
Troubleshooting: common problems and their fixes, in everyday language
FAQ-style content: anything you also want available inside a chat conversation

When to use documentation

Choose documentation when your readers are technical and need detailed, structured information about APIs, configuration or implementation.

API documentation: specifications, endpoints and code examples
Developer guides: integration instructions, SDK documentation, technical workflows
System configuration: detailed setup procedures
Technical specifications: component-based content that needs precise formatting

Key decision factors

Knowledge base: customers, end users, a non-technical audience
Documentation: developers, technical teams, system administrators :::
Knowledge base: flexible HTML articles, conversational tone, rich media
Documentation: structured markdown, technical components, code examples :::
Knowledge base: your public web address plus the chat widget's Help tab
Documentation: your public web address, as a technical portal :::
Knowledge base: fewer support tickets, self-service help
Documentation: developer onboarding, API integration, technical reference ::: ::

Many organisations keep both — a knowledge base for customers and documentation for developers — and link between them.

How each one is structured

Both are three levels deep, and the middle level is what a reader navigates by.

A knowledge base holds categories, and categories hold articles. Categories can sit inside one another.
A documentation set holds categories, and categories hold pages. A page can itself hold sub-pages, so one category can carry a whole nested tree.

Neither is rationed by your plan. What your plan decides is whether the Documentation module is available to you at all — not how many sets or articles you may create.