How to Train Your AI Sales Copilot on Your Product’s Knowledge Base

tool

tutorial

Jul 9, 2026

Summary: Setting up RAG for a sales copilot isn't technically hard — it's a discipline problem, and this is the difference between a copilot rep's trust in week two and one they've stopped looking at.

A generic AI sales copilot knows how to sell. It does not know what you sell. The gap between those two things determines whether the guidance it surfaces on a live call is genuinely useful or vaguely plausible - the kind of output that sounds like sales advice but could apply to any product in any industry.

The mechanism that closes that gap is called Retrieval-Augmented Generation, or RAG. It is the architectural pattern that allows an AI system to pull from your specific documents, battlecards, pricing sheets, objection guides, and case studies at the moment of need - rather than relying solely on general training data that has never heard of your product.

This article explains how RAG works in a sales copilot context, which files to upload and in what order, how long setup realistically takes, how to validate that the Al is retrieving accurately, and how to maintain the knowledge base as your product and positioning evolve. By the end, you will know exactly what to upload, what to expect, and how to get from zero to a product-aware copilot in under a week.

Part 1: What RAG Is and Why It Matters for Sales AI

The problem RAG solves

A large language model - the Al engine underlying a sales copilot - is trained on a broad corpus of text up to a certain date. It knows a great deal about how sales conversations work, what objections sound like, and how to structure a discovery call. It knows nothing about your product, your pricing, your case studies, your competitive differentiators, or the specific objections your prospects raise in your market.

Without a mechanism to inject that product-specific knowledge, the AI generates responses based on general patterns. The guidance is plausible but imprecise. When a prospect asks ‘how does your product handle enterprise SSO?’ and the copilot surfaces a generic response about enterprise authentication, the rep still has to remember the actual answer themselves. The AI has not helped.

How RAG works

RAG inserts a retrieval step between the user’s trigger and the Al’s response generation. Instead of generating an answer from general training data alone, the system receives the trigger - the prospect’s words or the detected signal - converts it into a search query against your knowledge base, retrieves the most relevant passages from your uploaded documents, passes those passages to the language model as context, and generates a response grounded in your specific content rather than in general training data.

The result is guidance that references your actual product capabilities, your documented objection responses, your real case study outcomes, and your current pricing structure because that is what the AI retrieved when it needed to answer the question.

What this means in practice on a live call

When a prospect says ‘we’re also looking at Competitor X,’ a RAG-enabled copilot does not generate a generic competitive response. It retrieves your battlecard for Competitor X, pulls the two or three most relevant differentiating points, and surfaces them as a prompt to the rep - in under 2 seconds, with content drawn directly from the document your sales enablement team wrote.

The rep does not need to memorize the battlecard. The AI retrieves it in real time.

Part 2: The Knowledge Base Architecture - What to Upload and Why

Not all documents contribute equally to copilot performance. The knowledge base should be built with intention - layered by priority, structured for retrieval quality, and curated rather than comprehensive. Uploading everything you have produces a knowledge base that is technically large and practically noisy.

The following hierarchy reflects the order in which documents should be added, based on their impact on live call guidance quality.

Tier 1 - Core Sales Documents

These four document types have the highest impact on live call quality and should be uploaded first. Nothing else in the knowledge base matters more than getting these right.

Objection handling guide.

The single highest-impact document in the knowledge base. It maps common objections to recommended responses, and the copilot retrieves from it every time an objection is detected in the live call. Organize by objection category - price, competitor, timing, status quo - with one objection per section and a clear header. A structured Q&A; format retrieves more reliably than prose paragraphs. Keep each objection-response pair under 300 words.

Competitive battlecards.

One document per competitor. When a competitor is named on a call, the copilot retrieves the relevant card and surfaces your key differentiators. Each card should include the competitor’s genuine strengths (an honest assessment builds rep credibility), your specific differentiators, the FUD they commonly use against you, and a two-sentence positioning statement the rep can use verbatim. Keep competitor name prominent in both the document title and the opening line.

Product FAQ.

Answers the direct product questions prospects ask during calls: capabilities, integrations, security, and pricing mechanics. Use question-and-answer format with the question as the section header. Keep answers under 150 words each - long answers retrieve correctly but surface too much text for a rep to scan mid-call. If a question requires more depth, split it into two sub-questions.

Pricing and packaging summary.

A one-page summary of list prices, common discount bands, tier contents, and the preferred framing for pricing conversations. Do not upload the full CPQ - a concise summary retrieves faster and more accurately. This document prevents reps from guessing or over-discounting from memory when budget objections arise.

Tier 2 - Enablement and Proof Documents

Upload these after Tier 1 is validated and working. They expand the copilot’s ability to surface proof, persona-specific narratives, and discovery support.

Case studies.

Organize by industry and company size rather than by customer name. Each case study should include a customer descriptor, the specific problem, how the product solved it, a measurable outcome, and a one-line quote where available. Keep each under 400 words. The copilot matches the case study to the prospect based on industry and pain type - the more specific the descriptor in the title and opening sentence, the more precise the match.

Product overview.

The foundational product narrative: one page of prose covering your core value proposition plus a bullet list of key capabilities. Keep this current - an overview written for last year’s positioning undermines the copilot’s credibility when it surfaces language that no longer matches how your team talks about the product.

ICP talk tracks.

One document per ICP. Each should contain: the ICP’s primary pain in their language, how your product addresses it, the outcome language that resonates with this persona, and two or three discovery questions that work well for this audience. A VP Sales persona gets different framing than a CFO, and the copilot surfaces the right track when it detects the prospect’s role.

Discovery question bank.

A structured library of discovery questions organized by MEDDPICC element or deal stage. Label each question with the element it addresses. The copilot retrieves questions relevant to uncovered qualification dimensions rather than surfacing the full library at once.

Tier 3 - Supporting Reference Documents

These documents handle edge cases and specialist questions. Upload them after Tiers 1 and 2 are validated. They matter, but retrieval gaps here are less costly than gaps in your objection guide or battlecards.

Security and compliance documentation - a curated summary (not the full security review packet) for when IT or legal stakeholders raise data residency, access control, or compliance questions
Integration documentation summary - a plain-language overview of key integrations and what they enable, not the full technical API documentation
ROI benchmarks and business case data - specific figures and customer outcomes for constructing value arguments when prospects challenge impact
Demo scripts and product walkthroughs - reference material for demo calls where the copilot can surface the recommended next talking point
Follow-up email templates - used for post-call output generation, ensuring follow-up drafts reflect approved brand voice and messaging

Part 3: Supported File Types and Technical Requirements

Convinco’s knowledge base accepts PDF, DOCX, PPTX, TXT, CSV, HTML, and basic XLSX files. Understanding the requirements and limitations of each format prevents the most common cause of poor retrieval: documents that are structurally incompatible with the indexing pipeline.

PDF - the recommended default format.

The most reliable format for knowledge base uploads. Preserves structure cleanly and is universally supported. One critical requirement: the PDF must be text-based, meaning you can select and copy text from it in a standard PDF viewer. Scanned PDFs that are images of pages rather than selectable text will appear to upload successfully but contain no indexable content - retrieval will return nothing. If your PDF is scanned, run it through an OCR tool (Adobe Acrobat, Google Drive, or any free online OCR service) before uploading. Maximum file size: 50 MB .

DOCX - clean and reliable for structured content.

Well-structured Word documents retrieve cleanly. The key constraint is formatting complexity: merged cells, nested tables, text boxes, and multi-column layouts can disrupt the text extraction layer, producing passages where content appears in incorrect order. Plain paragraph structure with clear heading hierarchy retrieves most reliably. If your DOCX contains complex formatting, convert it to PDF first. Maximum file size: 25 MB .

PPTX - useful when speaker notes are populated.

Slide titles and body text are extracted and indexed. Speaker notes are also indexed separately, and for most sales decks the speaker notes contain the most detailed and retrievable content. Image-only slides - charts, diagrams, screenshots without alt text or accompanying notes - are not retrievable. If your battlecards or product overviews exist as slide decks, they work as uploads provided the text content is in text boxes rather than embedded images. Maximum file size: 50 MB .

TXT - fast and frictionless for text-heavy content.

Plain text files process faster than any other format and have no formatting complications. Ideal for objection libraries, FAQ documents, and talk tracks that do not require visual structure. Maximum file size: 10 MB .

CSV - effective for structured data.

CSV content is indexed row by row with column headers included as context for each row. This makes CSV the right format for pricing tables, feature comparison matrices, and integration compatibility lists where the copilot needs to retrieve a specific data point. Maximum file size: 10 MB .

XLSX - supported with limitations.

Simple single-sheet Excel workbooks can be uploaded, but complex multi-sheet workbooks with formulas, merged cells, and pivot tables do not extract cleanly. For any Excel content intended for the knowledge base, convert to CSV or PDF before uploading. Maximum file size: 10 MB .

HTML - works for exported web content.

Static HTML files with clean heading structure retrieve well. JavaScript-rendered content and pages behind authentication cannot be indexed. Export static HTML rather than submitting live URLs. Maximum file size: 10 MB .

Video and audio - not directly supported.

MP4, MP3, and other media files cannot be indexed. If you have valuable content in call recordings or training videos, transcribe the audio and upload the transcript as a TXT or DOCX file.

Part 4: Setup Timeline - From Zero to Product-Aware Copilot

The most common question from new Convinco customers is how long it takes to get the knowledge base working well enough to use on live calls. The answer depends on the quality and availability of existing sales collateral, not on technical complexity. Teams with an organized enablement library can complete initial setup in five days. Teams starting from scratch need to create Tier 1 documents first - typically an additional three to five days of writing work.

Day 1 - Tier 1 upload.

Gather your objection handling guide, competitive battlecards for your top three competitors, product FAQ, and pricing summary. Upload all four. This takes two to four hours including file preparation. After uploading, immediately run five to ten test queries: type each objection from your guide exactly as a prospect would say it and confirm the copilot surfaces your approved response rather than a generically generated alternative.

Day 2 - Tier 1 validation and adjustment.

Review the test query results from Day 1. Most teams find one or two documents that retrieved poorly - typically because of long unstructured paragraphs, missing headers, or scanned PDF content. Reformat the problem documents and re-upload. Focus validation effort on the objection guide and battlecards: these are the highest-frequency retrieval scenarios on live calls, and errors here have the most direct impact on outcomes.

Day 3 - Tier 2 upload.

Upload case studies organized by industry, the product overview, ICP talk tracks, and the discovery question bank. Two to three hours. After uploading, test case study retrieval: describe a fictional prospect scenario and confirm the copilot surfaces the most relevant case study rather than one from an unrelated industry or use case.

Day 4 - Pilot call.

Run a real or simulated discovery call with the knowledge base active. Observe which signals trigger retrieval, whether the retrieved content is accurate and current, and where gaps exist. Take notes on every moment where the copilot surfaced something wrong, outdated, or irrelevant. These become the priority fixes for Day 5. Budget thirty minutes after the call for a structured debrief.

Day 5 - Tier 3 upload and gap remediation.

Upload supporting documents: security summary, integration overview, ROI benchmarks, demo scripts, and email templates. Fix any retrieval gaps identified in the Day 4 pilot. After this day’s work, the knowledge base is production-ready for live calls. Plan the team rollout for the following week.

Week 2 - Team rollout and feedback loop.

Deploy to the full rep team. Establish a feedback channel for reps to flag incorrect or missing responses immediately - a Slack channel or a shared Google Form works well. Assign one owner, typically in sales enablement or RevOps, to triage feedback weekly. The first two weeks of live usage will surface the highest-priority knowledge gaps. Plan one knowledge base update session per week for the first month.

Part 5: How to Write Documents That Retrieve Well

The quality of the knowledge base is not determined solely by what you upload. It is determined by how those documents are structured. A well-written objection guide in a poorly formatted document retrieves inconsistently. The same content in a clean, structured format retrieves precisely and quickly. Five principles apply across all document types.

Principle 1 - Use explicit, descriptive headers

RAG systems use headers as anchor points for retrieval. A header that reads ‘Pricing Objection: Too Expensive’ retrieves correctly when the prospect raises a price concern. A header that reads ‘Section 4’ does not. Every section of every knowledge base document should have a header that names the topic it covers in plain language - specific enough that the retrieval system can match it to a prospect’s words.

Principle 2 - Keep retrieval units short and self-contained

RAG systems retrieve passages, not full documents. A passage is typically 200-500 words. Content that spans multiple pages without clear section breaks will be chunked arbitrarily, potentially splitting an objection from its response or a case study problem from its outcome. Write each section to stand alone: if a passage is retrieved in isolation, it should still make complete sense. Avoid references like ‘as mentioned above’ or ‘see Section 3’ - the retrieval system cannot follow cross-references.

Principle 3 - Lead with the trigger, follow with the response

For objection guides and FAQ documents, the structure that retrieves most reliably mirrors the detection trigger. Start each section with the exact language the prospect is likely to use, then immediately follow with the recommended response. A well-structured objection entry looks like this:

Objection: ‘We already have a tool for this’ / ‘We’re happy with what we have’ / ‘We don’t want to add another vendor’

Context: Status quo objection. Prospect has an existing solution but has not evaluated it against current needs. Most common in outbound sequences and early discovery calls.

Response: [Two to three sentence recommended response, written in the voice the rep should use verbatim or near-verbatim]

Follow-up question: [One question to deepen the conversation after the initial response]

Principle 4 - Avoid marketing language

Sales collateral written for external audiences often uses language that is imprecise, aspirational, or hedged. This language retrieves poorly because it does not match the specific, concrete questions prospects ask on calls. ‘Our industry-leading platform delivers transformative outcomes’ does not retrieve when a prospect asks ‘what does your integration with Salesforce actually do?’ Write knowledge base documents in the plain, specific language of a product expert answering a direct question - not in the language of a marketing brochure.

Principle 5 - Version-control your documents

A knowledge base that contains an outdated pricing document alongside the current one will retrieve from both, producing inconsistent and potentially incorrect guidance. Every document should have a version date in the filename and a review date in the document header. When a document is updated, remove the old version before uploading the new one. A knowledge base with version conflicts is worse than one with gaps - at least a gap surfaces nothing; a conflict surfaces the wrong thing with confidence.

Applied to each document type, these principles produce the following best-practice formats:

Objection guide:

Start each entry with the verbatim objection language the prospect would use. Follow immediately with context (why this objection arises, when it typically surfaces), then the recommended response, then a follow-up question. Q&A; format, not prose paragraphs. Each entry under 300 words. No cross-references between entries.

Competitive battlecard:

One card per competitor. Section headers in plain language: their strengths, your differentiators, the FUD they use against you, your response to that FUD, the positioning statement. Each section under 200 words. No vague differentiators like ‘better UX’ - specific proof or specific functionality only. Check version currency before every major sales cycle.

Case study:

Customer descriptor with industry and size in the title. Structure: specific problem, how the product solved it, measurable outcome, one-line quote. Under 400 words total. Outcome language must be specific - ‘reduced ramp time from 7 months to 4 months’ retrieves and persuades; ‘significant improvement’ does neither.

FAQ:

Question as the header, answer immediately below, under 150 words per answer. If a question genuinely requires more depth, split it into sub-questions rather than writing a long single answer. Organize by topic a prospect would think in, not by the product feature that answers it.

Talk track:

Opening statement for this ICP in exact language. Three discovery questions with the MEDDPICC element each addresses noted in brackets. Value proposition in the ICP’s outcome language. Two common objections from this persona and recommended responses. One closing question to advance the deal. No content that applies equally to all ICPs - if it is not persona-specific, it does not belong in a talk track.

Part 6: Validating Retrieval Accuracy Before Going Live

Uploading documents is not the same as confirming they retrieve correctly. A document can be indexed without the most important passages being reliably surfaced in the right context. Validation before live call deployment is not optional - it is the step that determines whether reps trust the copilot in front of prospects. A single incorrect response on a critical call sets adoption back by weeks.

Run the following five tests after each tier of documents is uploaded. Each test should produce a response that matches your uploaded content with high specificity. A vague or generic response indicates a retrieval gap that needs remediation before deployment.

Test 1 - Objection retrieval.

Type each objection from your objection guide into the test interface exactly as a prospect would say it. The pass criterion is that the copilot surfaces your approved response using your documented language, not a generically generated alternative. If the response is generic or incomplete, reformat the objection section with a clearer header and shorter response. Check that the objection language in the document matches the phrasing used in the test query minor wording differences can affect retrieval precision.

Test 2 - Competitive retrieval.

Say ‘we’re also looking at [Competitor Name]’ for each competitor in your battlecard library. The pass criterion is that the copilot surfaces your two or three top differentiators against that specific competitor, drawn from the relevant battlecard - not a generic competitive response or content from a different competitor’s card. If retrieval fails, ensure each battlecard has the competitor’s name prominently in the title and the first paragraph. One competitor per document is more reliable than a multi-competitor matrix.

Test 3 - Product question retrieval.

Ask three to five real questions prospects have asked your team about product capabilities, integrations, or security. The pass criterion is that the copilot surfaces the accurate answer from your FAQ or product documentation, not a generated approximation that sounds plausible but may not match your actual capabilities. This is the most dangerous failure mode - a confident wrong answer on a product question damages rep credibility immediately. If the test fails, the question is likely not clearly answered in your uploaded documents. Add it to the FAQ explicitly.

Test 4 - Case study matching.

Describe a fictional prospect: ‘We’re a 200-person fintech company struggling with new rep ramp time.’ Ask the copilot for a relevant example. The pass criterion is that the copilot surfaces the case study most closely matching the described scenario - correct industry, similar company size, relevant pain. If it surfaces an unrelated case study or returns nothing, ensure case study titles and opening sentences include explicit descriptors for industry, company size, and pain type. The retrieval system matches on these descriptors.

Test 5 - Pricing retrieval.

Say ‘your pricing seems high for what we get’ and ‘what does the enterprise tier include?’ separately. The pass criterion is that the copilot surfaces your current pricing framing and accurate tier contents. The fail signal is generated pricing information that does not match your structure, or hedged language like ‘please contact sales’ that comes from generic training patterns rather than your document. If this test fails, check that no outdated pricing documents remain in the knowledge base and that the current document uses the same tier names and price points your team uses in conversations.

Part 7: Maintaining the Knowledge Base Over Time

A knowledge base that is accurate on day one will degrade over time if it is not maintained. Products change. Competitors change. Pricing changes. Objections evolve as the market matures. A copilot surfacing information from a document written eighteen months ago is surfacing outdated guidance - sometimes harmlessly, sometimes with commercial consequences.

Maintenance operates on two schedules: a recurring calendar and a set of event-triggered updates.

The recurring maintenance calendar

Weekly (15-30 minutes).

Review rep feedback on incorrect or missing responses. Triage: fix critical errors - wrong pricing, incorrect feature claims, outdated competitive positions - immediately. Queue non-critical improvements for the monthly review. The weekly review exists specifically to catch errors before they compound across many calls.

Monthly (2-3 hours).

Full knowledge base audit against current product and positioning. Update any document where content has changed since the last version. Remove outdated documents. Add new case studies as they are completed. Check competitor cards against any public announcements or product updates from the competitors you track.

Event-triggered updates

On product release.

Update the FAQ and product overview to reflect new capabilities. Update competitive battlecards if the release changes a key differentiator. Add any new integration documentation. Product releases create retrieval gaps immediately - a prospect asks about a feature that was just launched and the FAQ still shows the pre-launch state. Treat knowledge base updates as part of the release checklist, not as a post-launch follow-up.

On pricing change.

Remove the existing pricing document immediately - before uploading the updated version. A knowledge base with old and new pricing in parallel will retrieve from both and surface incorrect figures on live calls. Run pricing retrieval validation tests before the change goes live with reps. A pricing error on a call is the most commercially costly retrieval failure.

On a new competitor entering your market.

Create and upload a new battlecard within the first week the competitor is mentioned in prospect conversations. Validate retrieval against common competitive mention phrasings before deploying to the team. Two to four hours to write and upload a solid battlecard is a worthwhile investment against the cost of reps encountering the competitive question unprepared.

On rep feedback spikes.

If multiple reps flag the same retrieval gap in the same week, treat it as a priority above the monthly schedule - not a backlog item. A gap that affects every call of a particular type is a revenue issue. Assign it a same-day fix.

Version control discipline

Every knowledge base document should follow a naming convention that makes version management unambiguous:

$$ \begin{aligned} & {[\text { Document Type }]-[\text { Topic }]-[\text { YYYY-MM }]-v[N]} \ & \text { Example: Battlecard - Competitor-Gong - 2026-06 - v3 } \ & \text { Example: Objection-Guide - Pricing - 2026-07 - v1 } \end{aligned} $$

When a document is updated, the old version is removed from the knowledge base before the new version is uploaded. A knowledge base with both v 2 and v 3 of the same battlecard will retrieve inconsistently - sometimes the old positioning, sometimes the new. Version hygiene is a retrieval accuracy requirement, not a bureaucratic formality.

Part 8: Common Knowledge Base Mistakes and How to Avoid Them

The following errors account for the majority of poor retrieval experiences in the first weeks of deployment. Each is avoidable with awareness.

Uploading everything without curation.

Teams upload the entire shared drive: old pitch decks, archived pricing sheets, experimental one-pagers, outdated case studies. Retrieval becomes noisy - the copilot surfaces content from outdated documents as frequently as from current ones, and reps receive conflicting information. The fix: upload only current, approved documents. If a document would not be given to a prospect today, it should not be in the knowledge base.

Scanned PDF uploads.

The document appears to upload successfully but contains no indexable text. Retrieval returns nothing for its content - a silent failure that is easy to miss if validation is skipped. Before uploading any PDF, confirm you can select and copy text from it in a standard viewer. If not, run OCR before uploading.

Marketing PDFs with heavy design.

Glossy external brochures with multi-column layouts, text in image overlays, and decorative formatting cause partial or disordered text extraction. The retrieval system may extract text in incorrect reading order, producing nonsensical passages. Convert marketing PDFs to plain DOCX versions with the same content before uploading. The visual design is irrelevant to the knowledge base - only the text matters.

One massive document for everything.

A single ‘Sales Bible’ with every piece of enablement content in one file is chunked arbitrarily by the RAG system. An objection response gets separated from its context. A case study outcome gets split from the problem it addresses. Retrieval precision suffers across the board. Separate documents by content type: one objection guide, one battlecard per competitor, one FAQ. Smaller, focused documents retrieve more precisely than large omnibus files.

No validation before live calls.

Teams upload documents and immediately deploy to live calls without running retrieval tests. Reps discover gaps in front of prospects. A wrong pricing figure or incorrect feature claim on a critical call collapses rep trust in the copilot rapidly, and recovering from that trust deficit takes weeks. Always run the validation protocol before live deployment. Budget at least one day between final upload and first live call.

Treating the knowledge base as set-and-forget.

The team uploads documents during onboarding and does not update them as product, pricing, or competitive positioning evolves. The copilot surfaces outdated differentiation, discontinued pricing tiers, or deprecated feature descriptions. Reps stop trusting the guidance because it has been wrong too many times. Assign a knowledge base owner with explicit responsibility for monthly reviews and triggered updates. Treat the knowledge base as a living system, not a one-time configuration.

The Bottom Line

A generic AI sales copilot is a capable tool with a significant limitation: it does not know what you sell. RAG closes that gap by grounding every response in your specific product knowledge, your documented objection responses, your case studies, and your competitive positioning.

The setup is not technically complex. It requires organizational discipline: curating the right documents, formatting them for retrieval, validating before deployment, and maintaining the knowledge base as your product evolves. Teams that invest that discipline in the first week produce a copilot that surfaces accurate, specific, on-brand guidance on every call from day one.

Teams that upload everything they have without curation and skip validation produce a copilot that retrieves inconsistently, surfaces outdated content, and loses rep trust within two weeks.

The knowledge base is not a configuration step. It is the product. The quality of guidance your reps receive on live calls is a direct function of the quality of the documents you upload. Invest in it accordingly.

See how Convinco’s real-time AI copilot delivers live coaching the moment it matters - closing the gap traditional training cannot reach. Book a demo: https://tally.so/r/eqYkZk View pricing: convinco.co/pricing Download the assistant: https://www.convinco.co/download Ventairy case study: convinco.co/blog/ventairy-case-study