Your sales agent answers a pricing question confidently. The buyer forwards the answer to your account manager, who discovers that the agent used an old presentation. The conversation sounded helpful, but the next salesperson now has to correct a promise. This is a knowledge-management problem as much as an AI problem.
An AI sales knowledge base should help a system find the right approved information for the right question. More documents do not automatically produce better answers. This guide sets out a practical approach to source selection, ownership, change management and testing. The examples are suggested workflows to discuss with your implementation team, not a promise that every integration works without configuration.
Start with the questions buyers actually ask
Collect a small, representative set of questions from recent sales conversations. Group them by the decision the buyer is trying to make: whether the product fits, what the implementation involves, which integrations need confirmation and what the commercial next step is. Remove personal information from examples before using them in a pilot.
For each question, write the answer a salesperson is allowed to give and the point at which a specialist should take over. A question about a published capability may have a straightforward answer. A request for a custom integration or a contractual commitment may need review. This distinction prevents a knowledge project from becoming an uncontrolled library of sales promises.
Start with one product line and one audience. The pilot becomes easier to assess when a reviewer knows which answers are in scope. Add a question to the library because a customer needs it, not simply because a document happens to exist.
- Use actual questions with personal details removed.
- Label answers as approved, conditional or requiring review.
- Assign an owner to every unanswered question.
Separate approved facts from persuasive sales material
Build a source inventory before uploading content. Record the document name, owner, audience, last review date and whether it is still current. A public product description, an internal implementation note and a customer-specific proposal serve different purposes. They should not all be treated as universally approved answers.
A useful starting structure is a short fact sheet for each offering, supported by detailed references. Mark the limits alongside the capability. If an integration depends on the customer's configuration, include that condition in the approved answer rather than leaving it in a footnote. Retire obsolete presentations from retrieval when newer versions replace them.
Keep quotes and private customer arrangements out of general answers. A discount offered in one deal is not a public price. Your retrieval permissions should preserve that boundary, while a salesperson can request the correct commercial approval when needed.
Make the source of an answer visible
Retrieval-augmented generation, often shortened to RAG, brings retrieved material into the answering process. It can help an agent use selected information, but the quality of the result still depends on what was retrieved and how it was interpreted. Microsoft's knowledge-source documentation illustrates how an agent can use configured sources and source citations. The same design principle is useful when evaluating your own sales workflow.
Ask to see which source supports a response, when that source was reviewed and whether the answer adds anything the source does not say. A citation is a starting point for checking an answer, not proof that every sentence is correct. Review the cited passage and the buyer's actual question together.
For a pilot, log a concise source reference with the answer and keep the full document available to authorized reviewers. If two sources disagree, create a visible exception for the owner instead of silently allowing the agent to choose whichever wording sounds more convincing.
Reference: Microsoft: Knowledge sources in Copilot Studio.
Create an answer card that includes the limits
Try an answer card with five fields: buyer question, approved response, conditions, source and escalation owner. For example, a buyer might ask whether the agent can update their CRM. The approved answer should identify what has been confirmed for that configuration and what still needs technical review. It should not become a blanket statement about every CRM.
Use a short version for a quick conversation and a longer explanation for a follow-up. Both should share the same conditions and owner. This helps a voice interaction stay concise without removing information that matters to the buyer's decision.
Add a review date and a change note. When an answer changes, the owner should be able to explain why. A simple record of the old wording and the new approved wording makes it easier to find conversations that may need a correction.
- Question: what decision is the buyer trying to make?
- Answer: what can the team state today?
- Conditions: when is that answer valid?
- Source and owner: where can a reviewer verify it?
- Review date: when should it be checked again?
Define a useful response when information is missing
A missing answer is a normal operating condition. Define what the agent should do with it: acknowledge the question, explain which detail needs confirmation and capture a follow-up for the responsible person. The buyer should leave knowing what will happen next, rather than receiving an invented answer or an unexplained refusal.
Consider a buyer who asks about a deployment requirement that your approved materials do not cover. A useful handoff includes the precise requirement, the buyer's environment if supplied, the source already checked and the owner who will respond. Avoid asking the buyer to repeat information that is already in the conversation.
Do not infer an answer from a superficially similar feature. Two integrations with similar names can have different capabilities. If the source is unavailable or outdated, preserve that state and route the request for review instead of presenting a plausible guess as a confirmed product fact.
Test the library with difficult questions
Create a small evaluation set with straightforward questions, ambiguous questions and requests the agent should escalate. Include an outdated pricing example, two conflicting documents, a customer-specific exception and a question outside the pilot's scope. Write the expected behavior before testing so reviewers do not redefine success after seeing the answer.
Score factual support, completeness of important conditions, appropriate escalation and usefulness of the next step. These are proposed review categories, not a universal industry benchmark. Keep the sample size and examples alongside any percentage so the results remain understandable.
Re-run the same evaluation after changing sources or instructions. An update that improves one answer can affect another. Keep a version record for the library so a reviewer can connect a questionable response to the information available at the time.
Treat updates as part of sales operations
Choose who approves changes and how they reach the live agent. Product, commercial and implementation teams may own different sections. A salesperson should be able to report an incorrect answer without editing the approved source directly. Give that report a clear status and a responsible owner.
Review high-impact facts when the underlying product or offer changes. Do not depend only on a fixed calendar reminder. A feature release, revised eligibility rule or discontinued integration should trigger a targeted source review and a small regression check.
Keep the handoff between knowledge and CRM clear. The knowledge base explains what the business can say; the CRM records what this particular buyer needs and what was agreed. Joining those two contexts thoughtfully is more useful than copying every document into every lead record.
Bring a focused knowledge workflow to your demo
Choose five anonymized buyer questions, the approved answers and two examples that require a human. Bring a current product document and one outdated version so the demonstration can show how source selection and exceptions would be handled. Ask which parts are configured, which integrations are required and how changes are published.
In a Vistaar AI Hub discussion, focus on the conversation you want to improve and the information a salesperson needs afterward. Explore the sales-agent and CRM-agent workflows, then confirm the exact fit for your environment. The useful outcome is an agreed pilot with clear evidence requirements, rather than a broad promise that the agent knows everything.
After the demo, assign an owner to the initial library and a reviewer to the evaluation set. That small operational commitment is often more valuable than adding another hundred pages to the source collection.
Put the workflow into practice
A dependable AI sales knowledge base is a maintained collection of approved answers, conditions and clear ownership. Start with a narrow set of buyer questions, preserve source context and test what happens when the answer is uncertain. Expand only when the team can explain why a response was given and how an incorrect response will be corrected.
Bring your workflow to a Vistaar AI Hub demo
Discuss your current process, the systems involved and one practical improvement. Confirm the available configuration and review points with the team.
Book a demoExplore AI CRMContinue exploring
Explore 15 more practical questions
Should old presentations stay searchable?
Keep historical files where they are needed for records, but exclude superseded material from current answering unless there is a deliberate historical use case.
How should pricing questions be handled?
Use the currently approved commercial information and its conditions. Customer-specific quotes, discounts and contractual commitments should follow your defined approval process.
Can we use the same library for chat and voice?
A shared approved source can support both, but responses need channel-specific presentation. Test that shorter spoken answers still preserve important conditions.
What belongs on an answer card?
Include the buyer question, approved response, applicable conditions, supporting source, owner and review date. Add an escalation path when the answer requires confirmation.
How often should sources be reviewed?
Review them when relevant product or commercial information changes, with periodic checks as a backup. Choose the cadence based on how quickly each source becomes outdated.
Should customer proposals become general knowledge?
Only information approved for general reuse should be included. A proposal can contain private arrangements that do not apply to other buyers.
How do we test conflicting documents?
Include a deliberate conflict in the evaluation set and define which source is authoritative. The agent should escalate unresolved conflicts rather than silently invent a compromise.
What should a salesperson see in the CRM?
Record the buyer's requirement, the answer or commitment made, the relevant source reference and the next action. Avoid filling the record with unrelated documents.
Can a citation prove an answer is accurate?
A citation lets a reviewer inspect the source. The reviewer still needs to check whether that source supports the answer and whether important conditions were omitted.
What is a good first pilot?
Choose one product, one audience and a small collection of frequent questions. Include difficult and out-of-scope questions so the evaluation tests escalation as well as answering.
How should incorrect answers be reported?
Capture the question, response, relevant source version and the expected correction. Route the report to an owner and track whether the change has been tested and released.
Should the agent browse any website for an answer?
Define approved sources and the conditions for outside research. Unreviewed pages should not silently become authoritative statements about your product or commercial terms.
What metrics are useful?
Suggested measures include source-supported answers, correct escalation, important conditions preserved and reviewer correction effort. Report sample sizes alongside the results.
Does Vistaar AI Hub support every data source automatically?
Coverage and setup depend on the proposed workflow. Confirm source access, integration requirements, permissions and update behavior during a demonstration.
What should we bring to a demo?
Bring anonymized buyer questions, approved answers, a current source and examples that require escalation. Explain the handoff you want the sales team to receive.
