Skip to main content
DoneThat

AI Adoption GuideNonprofitOutreach

Personalized Solicitation Drafting

LLM generates individual donor solicitation letters from CRM giving history and relationship notes.

Nonprofit processPlanFundOutreachDeliverMeasureReportStewardRenew

By Don, DoneThat’s AI coach · updated

What this use case does

Personalized solicitation drafting uses a large language model to turn structured donor context into a first-draft appeal letter. The model reads giving history and relationship notes from the CRM, then produces a letter that names the relationship, references relevant gifts or interactions, and asks for a specific next gift. The gift officer or annual-fund writer remains the sender: they review tone, facts, and ask amount, edit as needed, and only then send.

This is drafting assistance, not autonomous outreach. The value is speed and consistency across many individual asks, without pretending the model knows the donor better than the people who manage the relationship.

Inputs the draft depends on

Two inputs are required. Giving history covers recent and lifetime gifts, gift dates, designations or funds when recorded, recurring-gift status, and any noted soft credits or household links the team treats as authoritative. Relationship notes cover steward contacts, visit summaries, volunteer roles, event attendance, stated interests, and any constraints the officer has already written down (preferred channel, do-not-solicit windows, memorial preferences, or language the donor has used about impact).

If either giving history or relationship notes is missing, the system should return empty output rather than inventing a letter. A blank result is safer than a generic appeal dressed up as personal. Teams can still use templates for mass segments; this use case is for records that already carry enough relationship signal to justify an individual draft.

Optional context can improve the draft when present: campaign theme and deadline, suggested ask range from capacity or affinity work, last acknowledgment language, and any open pledges. Optional fields must not substitute for the two required inputs.

How the drafting workflow runs

A typical run starts when an officer opens a prospect or when a queue marks records ready for personal appeals. The system assembles a prompt-safe packet from CRM fields: gift timeline, note excerpts within an agreed lookback, campaign brief, and any approved ask guidance. The model returns a single draft letter (or short variants if the team asks for subject-line plus body), grounded only in that packet.

The officer then edits. Edits usually cover ask amount, fund designation, specific program language, and anything that would sound wrong to someone who knows the household. After approval, the letter moves through the existing send path (mail merge, email platform, or hand delivery packet). Nothing in this use case replaces gift entry, acknowledgment, or compliance review for restricted gifts.

When notes are sparse but giving history exists, still withhold a personalized draft if the relationship-notes requirement is unmet. When history is rich but notes are empty, the same rule applies. Both signals are needed so the letter can connect past support to a current ask without guessing why the donor gives.

What a good draft looks like

A usable draft opens with a recognition of the relationship that matches the record, not a flattering invention. It references concrete gifts or contacts that appear in the inputs, states why the campaign matters in plain language tied to those interests, and makes one clear ask. It avoids claiming outcomes the organization has not documented, avoids medical or family details that were never recorded, and avoids comparing the donor to peers.

Tone should match channel and segment: annual-fund renewals stay shorter and warmer; major-gift soft asks stay more conversational and less templated. Length is secondary to accuracy. Officers should prefer a short, correct draft over a long letter that overreaches on impact stories.

Common failure modes are easy to spot in review. Hallucinated visit dates, wrong fund names, inflated lifetime totals, and invented children or spouses are grounds to reject the draft and check the source fields. If the model cannot cite a gift or note for a claim, that sentence should not ship.

Where this fits with risk and sequence work

Personalized letters sit downstream of portfolio hygiene. Lapse-risk scores can prioritize who gets a human-written ask soonest; capacity enrichment can bound the ask; sequence builders can place the letter as one step in a multi-touch plan. Drafting does not score risk or decide channel by itself. It consumes the context those systems and officers already trust.

Officers should treat model output as editable copy attached to a record, with provenance of which gift rows and note IDs were in scope. That audit trail helps when a donor replies with a correction or when a steward questions a phrase. It also makes empty-output cases explainable: the queue shows "insufficient history or notes" instead of a vague failure.

Guardrails for gift officers and writers

Keep a human in the loop on every send. Require dual presence of giving history and relationship notes before generation. Cap lookback so outdated notes do not dominate. Strip or redact sensitive free text the team does not want in model context. Ban fabricated statistics, peer comparisons, and unverified impact metrics in generated copy. Preserve the organization's approved legal language for gifts, matching challenges, and planned-giving mentions when those topics appear.

Success is measured in operational terms officers already use: time from "ready to ask" to "letter approved," share of drafts accepted with light edits, and reduction in purely generic merges for records that had usable notes. Quality review should sample for factual fidelity first, then voice. If fidelity slips, tighten inputs and empty-output rules before expanding volume.

Related use cases: Agentic Campaign Sequence Builder, Donor Lapse Risk Scoring, Giving Capacity Enrichment.

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