AI Adoption GuideSalesPropose
Case-study retrieval RAG
Retrieval-augmented generation pulls vertical-matched proof points from the sales-asset library on demand, using tools like Highspot or Seismic.
Sales processProspectQualifyDiscoverProposeNegotiateCloseHandoffRenew
By Don, DoneThat’s AI coach · updated
Retrieval cites an approved asset; it does not write a customer story
The quality job is to return a proof point that already exists in the approved sales-asset library, with a citation the AE can open. It is not to generate a customer result, a testimonial, or an ROI figure the library does not contain.
When a buyer asks who like them has done this work, the honest answers are a named approved story, a nameless approved story if logo rights are restricted, or a clear statement that you do not have a match in this vertical. A fluent paragraph that sounds like a case study is the failure. Buyers check. Legal checks.
Retrieval-augmented generation here means search the approved corpus, return assets with citations, and generate only a match explanation. The generated sentence is not the proof. Sales content platforms in the class of Highspot or Seismic are the usual store. Industry and use-case fields on the Salesforce opportunity, plus the problem language from a Gong transcript, are the usual query. None of those tools creates a customer you have not already documented.
Retrieved proof is a citation that can drop into an auto-drafted proposal. Quantified value still belongs to the ROI business case generator, which uses the prospect's own discovery numbers. Do not treat a case-study sentence as the business case.
Query by industry and use case, then open the source
Search the way an enablement lead would tag the library, not the way a keyword index would score a filename.
Build the query from the buyer's industry on the Salesforce opportunity, the use case they stated in discovery or on a Gong call, size or segment only if you tagged assets that way, and public-use versus reference-only so a private reference never becomes a logo in a deck. Use the library's tags, not your internal SKU names. Product-line folders are the wrong primary key. If industry, use case, rights, and last-reviewed date are missing, retrieval falls back to keyword overlap and you get confident misses.
Return a shortlist, not a rewritten story. Each hit needs an asset title and library ID, the customer name as it is approved to appear or an explicit "logo not for public use," a publish or last-reviewed date, the tags that caused the match, and a one-line reason a human can disagree with.
The AE opens the source. If the system cannot point at a file in Highspot, Seismic, or whichever library you actually run, the hit is not a citation. Do not search the whole company drive. Battle cards, competitive tear-downs, and lost-deal notes live near case studies in most libraries. Mix those corpora and retrieval will offer a logo that is actually the incumbent you are replacing.
The AE still reads the story before it lands in the proposal
Retrieval is a find-and-cite step. Send is still a human decision.
Before a story goes into a proposal, a demo follow-up, or a personalized demo video script, the AE or a proposal specialist reads the asset and checks that the product version still exists, the customer is still a customer (or the story is dated as a past engagement), logo and quote rights cover this use, and the numbers in the PDF are the numbers you are about to repeat. If the model summarized that they improved scheduling, you do not upgrade that to a percentage, a dollar figure, or a named executive quote.
If any of those fail, drop the asset. Ask enablement for a replacement. Do not ask the model to tighten the quote. The AE should be able to answer "where did this come from?" in one sentence: library, asset ID, customer as approved, date.
The same retrieve-and-refuse pattern shows up in security and RFP auto-responder work: answers come from a reviewed library, gaps stay gaps. A wrong logo is not a typo.
Illustrative example: Westbriar asked for a hospital staffing proof
The following is a made-up retrieval walkthrough, not a customer result and not reported ROI.
An AE is in propose with Westbriar Health, a regional hospital system. Salesforce industry is Healthcare / Hospitals. Discovery on Gong: nurse scheduling, overtime on med-surg units, they already run a workforce suite from another vendor. The AE asks retrieval for a hospital operations case study on staffing or scheduling, similar size, public-use approved.
The library returns one usable asset: Midland Regional Health, nurse scheduling, reviewed March 2025, library ID CS-441, public logo approved, use case workforce scheduling, industry hospitals. The AE opens the PDF. The story is a hospital system, the module matches, and the quote is attributed to a named VP of Nursing and marked for public use. The AE copies the citation (customer, year, asset ID) into the proposal appendix and uses one sentence that actually appears in the PDF, not a generated paraphrase.
Three hits get refused: a health-plan customer tagged healthcare (insurance, not hospitals); a 2019 story for a retired scheduling product with a blank last-reviewed date; and a generated paragraph that a large hospital system reduced overtime after go-live, with no library ID. If the index had included battle cards, it might have returned a tear-down that names Westbriar's incumbent. Presenting that vendor as a customer is how you lose the room. The AE sends one cited story and a line that you do not have a second hospital reference at this size.
A pre-call account briefing can tell the AE that Westbriar is a hospital system before they query. It does not create a case study.
If the library has no match, write that
No match is a content gap, not a prompt-engineering problem. Refuse when nothing in the approved corpus shares the buyer's industry and use case, when the only hits are adjacent verticals, when the hit is a competitor, partner, or prospect, when the asset is past review or withdrawn, or when logo or quote rights do not cover this proposal.
Adjacent is not close enough. A hospital buyer will notice a health-plan story. Lowering the match threshold to fill the appendix is a quality loss, even if the proposal looks more complete.
The output should say no approved match, list what you searched, and optionally list nearest misses with reasons they were rejected. Silence, or a confidently rewritten similar customer, is how stale and invented stories ship. Feed refusals to enablement as a brief. That is how the library gets thicker. It is not a reason to lower the match threshold this week.
Do not backfill the gap with ROI theater. If Westbriar needs a number, it comes from their overtime and headcount, through the business-case path, not from a health-plan story with the details changed.
Competitors, stale stories, and quotes nobody said
Three failure modes should be explicit rules, not folklore.
Competitors as customers. Battle cards, win/loss notes, and case studies often share a content platform. If competitive documents are in the same index, retrieval will treat a named competitor as proof. Keep competitive content in a separate collection, or tag it so it cannot be returned as a customer story. Spot-check: if the "customer" is on your competitor list, the pipeline is wrong.
Stale case studies. Products ship, logos expire, customers churn, champions leave. An undated story will be retrieved forever. Require a last-reviewed date and a withdrawn flag. If the date is past enablement's review SLA, treat the asset as ineligible until someone re-reads it.
Quotes the customer never said. Summarization will sharpen a bland sentence into a testimonial. They were happy with scheduling becomes a CNO quote with a percentage. Ban generated quotes. If you need a quote, it must appear in the source asset, with the same attribution, and with rights for this use. Paraphrase only as your own sentence, not as something the customer said.
When those three are controlled, retrieval is a quality tool: the proposal cites what you actually have. When they are not, it is a faster way to put a wrong logo or a fake quote in front of a buying committee.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first