Drafting Referral Messages from Your Own Case Studies

Retrieval-augmented generation works by retrieving relevant documents from a knowledge base and passing them to the model so the answer is grounded in your own data rather than the model's training data (Evidently AI). That grounding is the whole point: it reduces hallucination, supports citations back to a source, and lets the output be tailored to the individual (K2view).

For referral drafting, the "document" is your case study, and the metadata is what makes matching possible. Tag every study on four axes:

Keep the outcome figure attached to its source document. A reviewer who cannot trace a number in five seconds will either approve it blind or reject the whole draft, and both outcomes waste the workflow.

You also want a "do not use" flag on old studies with expired results or clients who have asked not to be named. Retrieval systems are literal: if a study sits in the index, it can surface. The practical fix is a boolean field that the retriever filters on before any similarity score is computed.

The mechanics are ordinary RAG. Ingest the studies, chunk them, embed the chunks, store the vectors with their metadata, and at query time embed the contact profile and pull the nearest matches. The standard workflow is ingest, retrieve on prompt, then generate using the prompt plus retrieved context (ReadyTensor).

Store owner, ask amount, and reward type on the study itself, not just in a separate campaign spreadsheet, so the draft and the offer cannot drift apart.

Two implementation details matter more than the embedding model choice.

First, filter before you rank. If the contact is a regional bank, exclude every non-banking study from the candidate set, then rank the remainder. Ranking first and filtering after produces near-misses ("a healthcare client similar to yours") that a reviewer has to rewrite anyway.

Second, build the query from the contact record, not from a free-text search box. A query assembled from industry, company size, and the last known business goal is more consistent, and consistency is what lets you measure whether the drafts are improving.

A worked example. A contact is a mid-market grocery chain that mentioned rising fulfillment costs. The query filters to retail and grocery studies, ranks by embedding similarity to "fulfillment cost reduction," and returns the top study: a grocery client that reduced error rates in order picking. The draft will cite that one study and nothing else.

If the top match scores below your threshold, the honest output is no draft: route the contact to a human who knows the account. A weak match is worse than no match, because it teaches the reviewer to distrust the queue.

The prompt has four jobs: define who is asking, supply the retrieved study verbatim, state the structural constraints, and forbid invention. Prompting guidance from legal practice generalizes well here: give the model the source material inside the prompt, specify the format, and instruct it to work only from what you supply (Clio). Structured prompt frameworks such as RACE (role, action, context, expectation) do the same job for content work (Champlain College).

The structural advice comes from referral asks in the wild. Career-advice writers converge on the same shape: remind the person who you are with one specific detail, name the exact thing you want, make a clear limited ask, and give an easy out (Applyre). The same source notes that a long message starting with an apology and ending with "let me know if there is anything you can do" puts the reader in an impossible position. Business-development advice adds the supporting facts: make it easy for them by including the details and a one-sentence reason you are relevant (Indeed).

Here is a prompt skeleton that encodes all of it.

Role: You write short referral asks for an account manager.

Contact:
- Name: {{contact.name}}
- Company: {{contact.company}} ({{contact.industry}}, {{contact.size}})
- Last conversation: {{contact.notes}}
- Known goal: {{contact.goal}}

Retrieved case study (use only this):
{{study.text}}

Rules:
- 2 to 3 sentences. No greeting, no sign-off.
- Cite exactly one fact from the case study.
- Name the introduction you want (a specific person type or team).
- Offer the double-sided reward in one clause.
- Add a single sentence that makes declining easy.
- Do not invent metrics, client names or outcomes.

Output JSON: {"draft": "...", "study_id": "...", "cited_fact": "..."}

Asking for the cited fact back as a separate field is the cheapest quality control you will add. The reviewer sees the claim and can check it against the study without re-reading the draft twice. If the model returns a cited fact you cannot find in the study text, the draft is auto-rejected.

One design choice worth making explicitly: whether to mention the reward. Double-sided programs, where both the referrer and the new customer get something, are the default recommendation for any business where a purchase happens, because the sharer becomes the person who got their friend a deal rather than someone collecting a payout (Referral Rock). Most referral programs run through one platform are double-sided (Referral Factory). But the reward described must match what the program actually pays (Yotpo), so pull reward text from the program configuration, never from the model.

The reviewer queue is the product. Put four checks on a single screen next to the draft:

Two of those checks generate data you should keep. Retrieval misses are the raw material for better tags; citation failures are the raw material for a tighter prompt. Without logging them, you are guessing at what to fix.

Reviewer load is the limit you will hit first. If you draft for a large contact list, you will create more review work than a small team can absorb. Cap the daily draft volume at what reviewers can clear in a fixed window, and rank candidates so the highest-value contacts are drafted first. Referral value is not uniform across segments (Schmitt et al.), so the queue order should reflect that.

There is a second reason to keep a person in the loop. Asking badly, or asking the wrong person at the wrong moment, damages a relationship that took months to build. The people who write about referral asks for a living are blunt about it: if you are not ready to articulate in two sentences why you are a genuine fit, you are not ready to ask anyone to vouch for you (Applyre). A reviewer is the one who decides that threshold has been met.

Track four numbers, and give each a baseline from before the workflow existed:

1. Reviewer approval rate without edits. This tells you whether retrieval and prompting are aligned.
2. Referral conversion rate per segment. This tells you whether the targeting rule is right.
3. Time from contact selected to message sent. This is the labor saving, and it is usually the easiest to prove.
4. Share of sent drafts that cite a study. If this falls, people are bypassing the queue.

The value case should be rebuilt per segment rather than borrowed from a headline figure. If a referred customer in one segment is worth meaningfully more than one in another, the referral effort, and the reviewer time, should follow the margin. The bank study's authors say exactly that: use a selective approach, because the differential varies across segments (Schmitt et al.).

Watch the failure mode that hides in plain sight: drafts that are technically accurate but read like everyone else's. If approval stays high but conversion does not move, the problem is not the retrieval, it is that the ask is too similar across contacts. That is a prompt and selection problem, not a model problem. Vary the opening detail (the last conversation) and the requested introduction, not the structure.

Everything above is buildable with an embedding model, a vector store, and a chat model, which is three integrations to maintain and three keys to rotate. Quanta Inference puts text, image, video, audio and embedding models behind one API key, OpenAI-compatible and prepaid, which is the pragmatic choice when the embedding call and the drafting call live in the same pipeline: https://quantaintelligence.ai/inference.

If you would rather hand the whole workflow to someone who has shipped it, describe the system you need and a specialist builds it with you: https://quantaintelligence.ai/