The gap between "user is confused" and "user reads the documentation" is where most support tickets are born. It involves leaving your product, finding your docs site, searching it, and returning — and at every step, opening a chat window is easier.
The help widget closes that gap by putting the knowledge base inside the product, on the page where the confusion happened.
One script tag
Add the embed snippet to your application and the widget appears. It brings your published articles, full search, and an AI assistant that answers from your documentation — on your own domain, in your own app.
Everything it needs is loaded from FinalDoc, so there is nothing to host, and nothing to redeploy when you publish a new article. Update your knowledge base and the widget is current.
Answers, not just links
Search is there, and it works — but the more useful behaviour is asking a question in plain language.
The assistant answers from your published articles and cites the ones it used, so a reader gets a direct answer with the option to read the full page behind it. Ask it how to publish a knowledge base and it returns the actual steps, with the article titles they came from — not a ranked list of things that might contain the answer.
Readers can also ask out loud. The widget supports a spoken conversation with the same assistant, which is genuinely useful in a product someone is using with their hands busy.
Grounded in your documentation
The assistant answers from your published knowledge base and nothing else. It is not a general chatbot with your brand on it: unpublished, hidden and draft articles are never used, and questions your documentation does not cover get an honest answer instead of an invented one.
That constraint is the feature. An assistant that occasionally invents a setting name is worse than no assistant, because it takes one confident wrong answer to make a user stop trusting every answer after it.
It tells you what people asked
The widget reports what readers search for and ask about. That is a different and often better signal than your docs site analytics, because it is captured at the moment of confusion, inside the product, with the page they were on as context.
Questions asked in the widget are the ones users had while trying to do something — not the ones they had while browsing your documentation.
Make it look like your product
Appearance is configurable — colours, position, and how the launcher behaves — so it reads as part of your application rather than a bolted-on box. You can also give the widget content that lives only there, for answers that belong in the product rather than in your public documentation.
Where to start
Open External Widget in the sidebar, configure it, and copy the embed code. Put it on your busiest screen first — the one that generates the most tickets — rather than everywhere at once. The questions it collects in the first week will usually tell you which article to write next.