Prepare an AI chatbot knowledge base by choosing approved answers, naming the owner of every important fact, separating public information from restricted records, and testing what the assistant should do when an answer is missing. Uploading more documents is not a substitute for resolving contradictions. For a Saudi or GCC B2B team, the launch decision should depend on whether the assistant gives the right next step in both Arabic and English, including when it must stop and involve a person.
This guide focuses on content readiness before launch. It complements our lead qualification and human handoff guide, which addresses what happens during the conversation. The workflow below is a proposed operating framework, not a customer case study or a guarantee of error-free answers.
What is a chatbot knowledge base?
A chatbot knowledge base is the approved material an assistant can use to answer questions: service descriptions, product explanations, operating hours, policies, supported use cases and next steps. It needs boundaries as well as facts. A reader should be able to tell which statements are current, which depend on an assessment, and which questions require an authorized employee.
Knowledge and actions are different. A document explaining appointment booking does not prove that a booking integration works. A service overview does not authorize the assistant to issue a quotation. Keep the content inventory, permitted conversation behavior and connected actions as separate acceptance items.
Start with buyer questions, not a document dump
Ask sales and customer service to list the questions they actually receive. Use approved, anonymized examples; do not copy private conversations into a public document. Group questions by the decision the buyer is trying to make: understanding the offer, checking fit, preparing for a demonstration, requesting support or discussing a specific commercial proposal.
For each group, decide whether the assistant should answer, ask one clarifying question, point to a current page or hand over. Microsoft's topic-design guidance likewise starts with user questions and tasks. Its platform-specific instructions should not be read as a description of Solvarex's underlying implementation.
Choose a focused first scope. An assistant that reliably explains three current offers and routes the next step is more useful than one that appears able to discuss every archived business document. Define the initial boundary in writing so that a missing answer is recognized as a content gap rather than filled with a guess.
Build an answer register with accountable owners
| Field | What to record | Why it matters |
|---|---|---|
| Question and intent | The buyer's wording and the decision behind it | Similar wording can require different responses |
| Approved answer | A concise explanation with conditions and exclusions | The assistant should not invent missing scope |
| Authoritative source | Current page, approved document or policy section | Reviewers need to trace the answer |
| Owner and review date | The person or role responsible for changes | Someone must resolve contradictions |
| Language versions | Approved Arabic and English meanings | Commercial conditions must remain consistent |
| Next step | Clarification, product demo, consultation or human review | A correct answer should lead somewhere useful |
The register can begin as a simple internal worksheet. It is not a new software requirement. Keep one approved source for each material claim; archive superseded drafts outside the active collection. If the website and an old brochure disagree, the content owner must settle the difference before both become available to the assistant.
Do not turn a date field into a false assurance of accuracy. A recently uploaded document may contain obsolete terms. Review the meaning, not only the upload time, particularly for availability, contract conditions, pricing and the distinction between a managed service and a software product.
Write answers that preserve commercial boundaries
Use a direct answer first, then explain what changes the answer, and finish with the appropriate next step. Avoid long marketing paragraphs that leave the assistant to infer what is actually included. Distinguish capabilities that are available in the approved offer from integrations or customization that need a separate scope discussion.
For example, an illustrative answer to “Can this connect to our existing system?” could explain that the team must review the system, required data, direction of synchronization and access before confirming implementation. It should not claim that every named application is already connected or included. Record which clarification is useful and who can make the final commitment.
For prices or bespoke timelines that are not publicly approved, the answer should explain the information required for an assessment and offer the real consultation route. It should not fabricate an estimate to keep the conversation moving. This is a content and authorization decision, not simply a prompt-writing technique.
Prepare Arabic and English together
Localize the question set independently. A Saudi buyer may ask “أبغى موظف يرد على العملاء” while an English-speaking manager asks about an AI customer-service assistant. Both may concern the same offer, but the most useful explanation and clarification can differ. Test ordinary professional language, mixed Arabic and English product names, and realistic spelling variations.
Keep commercial conditions synchronized: what is included, what needs assessment, when a human takes over and where a service inquiry or product demo should go. Do not let a fluent translation broaden the approved offer. If a term has no clear Arabic counterpart, introduce the meaning once and use the agreed term consistently.
Check the actual rendered conversation too. Arabic punctuation, telephone numbers, email addresses and links can display awkwardly in mixed-direction text. Understanding a question and displaying an intelligible response are separate checks. Do not promise support for every dialect based on one successful sample.
Separate public knowledge from customer-specific records
A public service FAQ can explain the process. It should not contain a customer list, credentials, private quotations, employee records or confidential account information. If a use case requires customer-specific answers, it needs a separately reviewed authentication, permission and data-access design rather than a larger public knowledge upload.
Define what the assistant may ask for and why. Collect only the information needed for the agreed next step and preserve the website's applicable privacy and consent controls. Do not copy personal details into test prompts or publish real support transcripts as examples. Use synthetic business scenarios when checking the flow.
Instructions written inside retrieved documents must not be treated as permission to reveal data or perform an action. Include a test in which a document or user asks the assistant to ignore its boundaries. The expected result is to retain the approved scope, not to obey the embedded request.
Test missing, conflicting and changing information
A good test set includes questions with clear answers, questions needing clarification and questions that should not be answered from the available material. Add a deliberate contradiction between two draft facts in a test collection, then check whether the release process catches it before customer exposure. Remove the contradiction rather than relying on the model to choose the preferred version.
Microsoft's generative-answers FAQ documents the possibility of mistakes and recommends testing before publication. Its warnings reinforce a general review principle; they do not establish the behavior or configuration of another product.
| Test situation | Expected behavior | Evidence to retain |
|---|---|---|
| Current approved fact | Answer accurately without adding a promise | Source and reviewer decision |
| Ambiguous need | Ask a relevant clarification | Question and useful next step |
| Unpublished price | Explain assessment and route to a person | No invented number |
| Conflicting source | Hold the content change for owner resolution | Resolved source version |
| Restricted customer detail | Avoid disclosure and use the agreed escalation | No private data in the answer |
| Arabic/English equivalent | Preserve scope and next step in both | Separate language review |
Judge factual meaning and behavior rather than demanding identical wording on every attempt. Record the prompt, approved expectation, observed answer and pass/fail reason. Agree acceptance thresholds with the business owner before testing; this guide does not prescribe an arbitrary accuracy percentage or claim a measured Solvarex benchmark.
Assign a release owner and a maintenance loop
Before launch, a business owner approves the knowledge scope, a technical reviewer verifies what is actually connected, and a language reviewer checks both versions. These can be responsibilities held by the same small team; the point is to make the decisions explicit. Keep unresolved high-impact answers outside the release rather than accepting them because the rest looks polished.
After launch, review unanswered questions and human corrections through an authorized process. Separate a content problem from a routing problem: the right answer can still send someone to the wrong booking page. Prioritize corrections that affect expectations, confidentiality or the next commercial step, and rerun the affected tests after each change.
Keep a reversible record of approved changes. If a service is withdrawn or its scope changes, update the active source and the corresponding tests in both languages. Verify that the published assistant uses the revised material; saving a document or seeing a successful upload is not end-to-end evidence.
Frequently asked questions
Do we need hundreds of FAQs before launching?
No fixed count establishes readiness. Start with the highest-value approved questions for a clear scope, cover important exceptions, and test the next step. Add coverage when actual buyer needs justify it.
Can we upload the entire website?
Only after reviewing what it contains and what the selected platform actually retrieves. Archived offers, inconsistent pages and private material should not become approved knowledge by default.
Does a good knowledge base prevent every incorrect answer?
No. It reduces avoidable content ambiguity, but generation, retrieval, configuration and conversation context can still create errors. Use testing, bounded behavior and an effective human route.
Should the assistant book every conversation?
No. First determine whether the visitor needs a service discussion, a product demonstration, support or a different route. A booking is useful only when it matches the need and is actually confirmed.
Choose the next step based on readiness
If your offer descriptions and FAQs disagree, resolve them before asking for a wider AI rollout. If the knowledge is approved but the conversation cannot identify and route the need, review the qualification and handoff design. For the connected communication workflow, see our WhatsApp and CRM launch checklist.
Explore the verified scope of Solvarex AI Employee and Chatbot and book a product demonstration to discuss your questions, approved sources, languages and acceptance checks. A demonstration should establish fit and scope; it is not a guarantee that every requested integration or automation is already included.
