---
title: "Knowledge Base"
id: "2158"
type: "page"
slug: "knowledge"
published_at: "2026-10-04T08:29:35+00:00"
modified_at: "2026-10-22T16:38:23+00:00"
url: "https://xedant.com/agents/crm/addons/knowledge/"
markdown_url: "https://xedant.com/agents/crm/addons/knowledge.md"
excerpt: "The add-on Knowledge base gathers the answers your team gives again and again into articles…"
---

# Knowledge Base

[https://xedant.com/agents/crm/addons/knowledge/.md](https://xedant.com/agents/crm/addons/knowledge/.md)

The add-on **Knowledge base** gathers the answers your team gives again and again into articles with owners and review dates. It keeps what the office knows current, offers the right article while a request is being answered, and opens published articles to customers in their own room. The work is gathered in the Knowledge console, whose tabs are Articles, Review, Feedback and Reports.

![Knowledge add-on, Articles tab: the article list with status, audience, category, owner, views and review due date](https://xedant.com/wp-content/uploads/2026/10/crm-agent-addon-knowledge.png)## Why you need it

While answers live only in correspondence, every new employee works the obvious out from scratch, and customers get different versions of what should be the same reply. Worse is the instruction that went stale two years ago: people still follow it to the letter, and nobody notices the trap until a customer does.

The Knowledge base turns answers into a working process instead of a pile of texts. An article has a responsible person and a review date, a reader can vote on whether it helped, and the customer gets an open section with solutions. An agent attaches a ready article to a reply in one action rather than retelling it in their own words.

## What it does

- **Articles with an owner and a review date.** Articles live in one level of categories, each with someone responsible for its content and its own review cadence: high-traffic and critical articles are reviewed every 90 days, the rest once a year. An article past its date is reported with its owner’s name and stays readable — the duty is a fact, not a lock on the door. Publishing an article demands an owner.
- **Two audiences behind one fence.** Every article carries an audience — internal or public — and it defaults to internal, the safe side. Internal articles surface to the office; public ones are what customers and the suggestion loop see. The rule is enforced on the server, so internal material cannot leak onto a customer page whatever the request asks for.
- **Archive instead of delete.** An article cannot be deleted: it is archived with a required reason and stays readable, so links from old requests keep working. For a knowledge base that correspondence points at, a vanished answer would break the history.
- **Helpfulness and statistics from the journal.** A reader can vote on whether an article helped and say why. Views, votes and helpfulness are derived from the journal the moment they are read, instead of being stored as counters that eventually disagree with the facts.
- **Suggestions while a request is worked on.** By a request’s subject the product offers matching articles: the subject’s words are matched against titles, tags and article bodies, and a match in the description only adds a bonus. The agent sees the hypotheses and decides what to attach. Worded searches are kept verbatim in a journal — including the ones that found nothing, which are the raw material of the monthly review — and the Review tab shows what was offered, what was used and how often.
- **Insert with one action.** A published public article can go into a public reply to the customer, and an internal article into a note on the request’s history. An internal article in a public reply is refused by name, so a customer never receives internal material. Every insert is bound to the person who made it and to the request where it was used — that offered-and-used journal is what the effectiveness report counts.
- **An article drafted from a request.** A resolved or closed request can be the starting point for an article; one live draft stands per request, the title starts from the request’s subject and the text is the raw material, which a person rewrites and checks. Automatic drafting by a language model is a named deferral.
- **A daily freshness pass.** Once a day the product flags the articles whose review is due — once per article per cycle, so re-running the pass changes nothing. Articles without an owner stay in the report quietly and do not ping anyone.
- **Reports with visible denominators.** The Reports tab shows how many articles stand, how often they were used, what share of requests carried an insert, which questions found no answer and which articles nobody reads. Every rate carries the denominator it was computed from: the insert rate divides by the requests born, and no claim of “we halved the support load” is made anywhere.
- **What the customer sees.** In the customer room the knowledge page renders markdown through a fixed safe subset, and only published public articles are ever offered there — an internal article cannot appear on a public page whatever the visitor types.
- **One console.** The Knowledge console gathers the Articles, Review, Feedback and Reports tabs. It only reads: changes are made by agent commands, which can be copied straight from the interface.

## How it relates to other add-ons

Knowledge base declares no required add-ons and switches on by itself: articles can be written, searched and voted on with nothing else installed. It earns its keep beside [Service](/agents/crm/addons/service)
, where articles are suggested while a request is being classified and inserted into replies. [Portal](/agents/crm/addons/portal)
 requires both Service and Knowledge, because the customer’s public section is the knowledge base, and [ITSM](/agents/crm/addons/itsm)
 requires Knowledge too, because publishing a known error is an explicit action that refuses by name when the knowledge add-on is inactive — the problem then stands unchanged. The agent suggestions run through the knowledge port, so Service keeps working, just without the article candidates, when Knowledge is switched off.

## Honest limits

- Search goes by words, not by meaning: the product does not “understand” the question or look for something similar in sense. That is honest groundwork for what the suggestions rest on, and it is named as such.
- There are no sections for different brands, languages or article versions, and no version history or comparison of edits. An article lives as one text.
- Automatic drafting of an article from a request by a language model is a deferral. Today a person starts the draft from the request’s own words.
- An article is never deleted, only archived — otherwise links from old requests would stop working. Archiving is terminal: the way on is a new article.
- The product never claims a customer “would have solved it themselves if they had read the article”. No deflection is invented; only figures that have a visible denominator are shown.
- An article’s address is fixed when it is born and never moves, so renaming a title does not break a link that was already handed out.
- The insert rate divides by the requests born on the ticket contour, so without [Service](/agents/crm/addons/service) that share has no denominator and says so instead of guessing.

All add-ons → [Add-ons catalogue](/agents/crm/addons)

[← CRM Agent documentation](/agents/crm/docs)