Write and publish your first article
Your knowledge base is public from the day the workspace exists. It lives at your-workspace.replium.chat/kb, it is open to anyone with the address, and until you publish something it tells visitors "Nothing published yet". This is how you fill it.
Write the article
Articles in the console, then New article. There are four things on the form:
| Field | What it does |
|---|---|
| Title | The heading of the page, up to 200 characters. Also what search weighs most heavily |
| Category | Where it sits in your knowledge base. "Uncategorized" is a valid answer and can be changed later |
| Status | Draft or Published. A new article starts as a draft |
| Content | The article itself, in the editor below |
The editor has two tabs, Edit and Preview. The preview is not an approximation: it is rendered on the server by the same code that renders the public page, so what you see there is exactly what a visitor gets. Formatting — headings, lists, tables, links between articles, images — has its own article.
An article body can be up to 100,000 bytes, which is far more than any support article should be.
The address is decided once
When the article is first created, its address is derived from the title: "How to reset your password" becomes /kb/how-to-reset-your-password. That address never changes afterwards.
This cuts both ways, and it is worth knowing before you save:
- Renaming an article does not move it. Links you gave customers, and links from your other articles, keep working after any number of title edits.
- A typo in the title survives in the address, because the address was minted from it. If the title is wrong, the cheapest fix while nothing links to the article yet is to delete it and create it again.
Draft, then published
A draft is visible to your team in the console and to nobody else. A visitor gets the same answer for a draft as for an article that does not exist — it is not in the list, not in search, and its address returns nothing.
Publishing is one control, in two places: the Status field on the form, and a Publish / Unpublish button while editing an existing article. Unpublishing is not a delete — it returns the article to draft, address and text intact, and you can publish it again later.
Two consequences people meet in their first week:
- The dashboard's setup step only ticks on a published article. A draft looks like progress and changes nothing for your visitors, so the checklist deliberately does not count it.
- An empty article cannot be published. Save it as a draft, write the body, publish then.
Show a draft to somebody before it goes live
While editing a draft, Copy preview link mints a link that opens that one article for anyone who has it — no account needed. It works for 7 days, and the page carries a "Draft preview" notice so nobody mistakes it for the published version.
The link grants exactly one article. It is not a key to your drafts in general, and it does not let the reader see anything else in your knowledge base that is not already public.
Organise it with categories
Categories in the console. A category has a title and, optionally, a parent — nesting goes three levels deep, which is one more than most support sites ever need. Drag to reorder categories, and articles within a category, into the order a reader should meet them rather than the order you wrote them.
You do not have to decide the structure up front. Articles can be left uncategorized and filed later; moving one between categories is a field on its own form.
What a visitor gets
- The knowledge base page, with your categories, your logo and your accent colour from Branding.
- Search that reads the whole article, not only titles. Titles are ranked higher, quotes search a phrase, and a leading minus excludes a word —
refund -shipping. Stemming follows your workspace's language, so "refunds" finds "refund". - The same search inside your chat widget. A published article is findable from the widget on your own site too: a visitor searches for an answer in the panel and reads it there, without leaving the page they were on. Nothing to configure — see installing the widget.
- A contents list on a longer article, built from its headings and shown above the text, plus an address of its own for every section. It means a support answer can send somebody to the paragraph that answers them rather than to the top of a long page. It appears from three sections up and arrives folded on a phone; how to write the headings it is built from is in the formatting article.
- Small conveniences on the page itself: a Copy button on every code block, and a click that opens a screenshot full size over the article. Nothing to configure, and nothing to write differently — see the formatting article.
- "Was this article helpful?" under each published article — Yes or No, anonymous, with an optional line about what was missing. One honest caveat: these votes are stored, but there is no screen showing them to you yet.
- Drafts appear in none of this.
Whether search engines see it
The Articles page carries one switch, Search engine indexing:
- On — published articles can appear in Google and other search results.
- Off — published articles stay reachable by their address, but ask search engines not to index them.
Off is the right answer for a knowledge base meant only for existing customers; on is the right answer if you want these pages found by people who have not written to you yet.
What the free plan holds
| Limit | Free | Pro |
|---|---|---|
| Articles | 50 | 1000 |
| Categories | 20 | 100 |
Both are per workspace, and drafts count towards the article number — they occupy a row like any other article.