A user is trying to cancel. They type "stop charging me" into your help center search box.
Your best article is titled Managing your subscription. It does not contain the word "charging". It does not contain the word "stop". Keyword search returns nothing, and the user opens a support ticket that your documentation could have closed.
This is the normal failure mode of help centers, and it is not a content problem. You wrote the article. The search just could not find it.
Vocabulary mismatch
Help articles are written by people who know the product. They use the product's nouns: subscription, seat, workspace, entitlement. Searches are written by people who do not know the product yet. They use their own: plan, user, account, access.
Keyword search requires those two vocabularies to overlap. Frequently they do not, and the gap is widest for exactly the users who need help most — the new ones.
Semantic search closes the gap
Kookee's help center search is semantic. Articles are embedded as vectors, the query is embedded the same way, and matching happens on meaning rather than on shared characters:
const results = await kookee.help.search({ query: 'stop charging me', limit: 5 });
results.forEach((result) => {
result.title; // 'Managing your subscription'
result.matchedChunk; // the passage that actually matched
result.category; // { name, slug }
});matchedChunk is the part we find most useful in practice. You get back not just the article but the passage that answered the query — which means your search results page can show the answer inline instead of a list of blue links to skim.
Then remove the search box entirely
Search is still an interface where the user does the work. They phrase a query, scan results, open an article, and scan again for the paragraph that applies to them.
The chat widget skips those steps. It answers in natural language, grounded in your published help articles, and cites the sources it used:
import { KookeeChatWidget } from '@kookee/react/chat';
import '@kookee/react/chat.css';
<KookeeChatWidget
clientOptions={{ apiKey: 'your-api-key' }}
title="Help"
greeting="Hi! How can I help you?"
suggestions={['How do I get started?', 'What are the pricing plans?']}
onSourceClick={(source) => window.open(`/help/${source.slug}`, '_blank')}
/>That is the whole integration. It is a floating bubble on any page, it themes to light, dark or auto, and it takes a primaryColor so it does not look like someone else's product bolted onto yours.
Grounding matters here. The widget answers from your articles and links to them. When it does not know, that is a gap in your documentation — and onSourceClick plus your article view counts tell you which articles are actually load-bearing.
Write for the question, not the feature
Two things follow from all this, and both are about how you write.
Semantic search matches on meaning, so an article that opens by restating the user's problem in the user's words will be found. One that opens with "This article describes the subscription management interface" will not, no matter how good the rest of it is.
And the numbers tell you when you got it wrong. An article with heavy traffic that keeps producing the same support question is not a missing article. It is a wrong one — people are finding it and it is not helping — and that is the most actionable signal a help center can give you.