How to build an assistant that answers from company documents rather than in generalities: where the knowledge base lives, how quality is verified before launch, and why the assistant’s most important skill is knowing when to stop talking.
Two kinds of assistant
An external assistant talks to customers: it advises on the website and in messengers, explains terms, helps choose, books appointments. It has hard limits on tone and topics, and it must always be able to hand the conversation to a human.
An internal assistant talks to employees: it finds the clause in a policy, pulls up a customer’s history, drafts a document, answers a newcomer’s questions instead of them walking over to a colleague. The limits here are softer, but the accuracy bar is higher — a person will act on its answer.
Technically it is the same architecture. The difference is in the knowledge base, in access rights, and in what counts as an acceptable mistake.
The knowledge base matters more than the model
Choosing the model is the most overrated part of the job. Modern models phrase things about equally well; the difference between a good assistant and a useless one is almost always in what it was given to read.
So the first stage is not prompting but collecting and cleaning up knowledge: price lists, policies, FAQs, service descriptions, limitations and exceptions. It often turns out half of it exists only in a department head’s memory — and we help write it down.
A side effect clients value on its own: once the knowledge base is assembled, the company has a single, current, verified set of rules for the first time. People start using it, not just the assistant.
Where the assistant must stop
The most dangerous trait of a language model is its willingness to answer anything. That is exactly why the boundaries are designed before the dialogue scenarios.
- Anything touching a customer’s health, legal position or money — approved wording only, no improvisation.
- Discounts, exceptions and individual terms — always a human.
- A complaint, a conflict or clear irritation in tone — instant handover with full context.
- A question the knowledge base does not cover — an honest “let me check and come back” rather than a plausible invention.
How quality is verified before launch
You cannot release an assistant to customers on a hunch. Before launch we assemble a test set — typically 60 to 150 real questions from your own conversation history, awkward ones included — and run the assistant against them after every change.
It is the boring but decisive part of the job: it turns “seems to answer fine” into a measurable share of correct answers and shows exactly what broke when you added a new price list.
After launch the set keeps growing: every case where the assistant erred or gave up is added to it and never repeats unnoticed.
Channels and integrations
The same assistant lives everywhere you talk to customers at once: a website widget, WhatsApp, Telegram, Instagram DM, email. The logic and knowledge base are shared; only the formatting changes per channel — shorter in a messenger, a list is acceptable on the site.
Access to live data is configured separately: a doctor’s schedule, stock availability, order status. Without it the assistant stays a reference book; with it, it starts answering the questions people actually write in about.
What happens after launch
An assistant is not a box you install and forget. Prices, services and rules change, and the knowledge base has to change with them. We hand over a simple way to update it without a developer and review the stats monthly: which questions come up most, where the assistant hands off, what is worth adding.
Frequently asked questions
- Can the assistant make an answer up?
- It can — if it is built badly. We constrain answers to the company knowledge base and train it to admit honestly when information is missing. The test dialogue set exists precisely to catch such cases before customers do.
- Which language does it answer in?
- The customer’s. That is rarely a problem: modern models switch freely, and we fix tone and terminology separately for each language.
- How long does launch take?
- Usually two to four weeks, and most of that goes not into development but into collecting and cleaning the knowledge base. The better your rules are written down, the faster it goes.
