Skip to main content
DoneThat

AI Adoption GuideEducationAdvance

Donor Retention Risk Model

ML identifies lapsed or at-risk annual fund donors and triggers a personalized win-back sequence through each donor's preferred channel.

Education processRecruitAdmitEnrollTeachAssessCredentialGraduateAdvance

By Don, DoneThat’s AI coach · updated

What a retention risk flag is allowed to say

A donor retention risk model should return a quality-gated flag, not a send. The usable output is a risk label plus citations to giving recency and engagement already on the record. If those cites are missing, the field stays empty. The model does not invent a lapse, does not invent a preferred channel, and does not own the outreach sequence. The annual-fund or donor-relations officer does.

That boundary is the whole point. Propensity work estimates who might give. Retention-risk work flags people who already gave, when the file shows cooling. Mixing those jobs produces silent over-solicitation or a false do-not-ask list.

The flag is evidence for a human decision: whether to start a win-back conversation, which recorded channel to use, and whether this person belongs in a reactivation track. It is not a suppression code. A high-risk annual-fund donor is often the person you most need to reach, with a shorter ask and a specific reason to reconnect, not the person you drop from the file.

Keep this model separate from alumni giving propensity model scoring. Propensity ranks likelihood to give. Retention risk ranks documented cooling among existing annual-fund donors. A high propensity score does not cancel a recency cite, and a risk flag does not mean the person is a major-gift or planned-giving prospect.

Score only from giving history you can cite

Score from the gift and engagement tables you would show a colleague sitting next to you. Recency of last gift, consecutive years of annual-fund participation, gift size relative to the donor's own history, and engagement the CRM actually logged: email opens or clicks if you store them, event attendance, volunteer shifts, reunion registration, phonathon outcomes. Each feature on the scorecard should map to a field and a date. If you cannot name the field, it does not enter the score.

Do not fill gaps. A constituent with one gift and no engagement log is not at risk of lapsing. There is not enough series to describe a pattern. The correct output is empty: no flag, no invented last-gift date, no synthetic channel. Thin history is a data-quality state, not a medium-risk state.

When history is thick enough, write the flag as a claim with cites. Example shape: last annual-fund gift outside the donor's usual cycle, two prior consecutive years of giving, no event attendance since the last gift, and no successful phonathon contact in the current fiscal year. The officer should be able to open those records from the flag without trusting a percentile that cannot be unpacked.

Systems of record vary. Advancement shops store this in Salesforce, Ellucian, Workday, or Anthology, sometimes split across a CRM and a separate marketing tool. Treat those platforms as a class. They hold gifts, contact preferences, and activity. They do not, by themselves, decide that a donor has lapsed. Your scoring job is to read the same tables staff already trust, not to import a packaged retention score whose inputs you cannot cite.

Watch the calendar. Fiscal-year cutovers, matching-gift delays, and payroll-deduction gifts that post late will look like lapses if you score on posting date alone. Cite both gift date and designation (annual fund versus restricted) so a capital-campaign pledge does not hide, or falsely create, an annual-fund gap.

Queue win-back drafts. Do not send them.

Once a flag is written with cites, the next system step is a draft, not a message in the donor's inbox. Generate a short win-back sequence in the recorded preferred channel: a call outline, an email draft, or a mail paragraph. Park it in the officer's queue with the cites attached. Nothing leaves until a person reviews, edits, or kills it.

Review is the control. The officer checks whether the recency cite is a true gap or a delayed post, whether the person is in a known life event, whether the ask amount matches the donor's own history, and whether the channel on the draft matches a preference the donor stated. Then they send, postpone, or clear the flag without outreach.

Illustrative path, not a measured case: an alumna who gave to the annual fund in three consecutive years, usually in November. The current cycle has no annual-fund gift. Her last logged engagement is an opened appeal last spring. Her recorded preference is email. The model writes an at-risk flag citing those facts and queues a two-touch draft: a brief email that names the gap without scolding, then a call outline if she does not reply. The officer sees a reunion-weekend volunteer shift that never synced into the engagement table, rewrites the email around thanks for that shift, and sends. If gift history were a single year and engagement were blank, the model would have left the flag empty instead of guessing a lapse.

Do not auto-send because the queue is long. A wrong recency cite in a live email is a relationship event, not a reporting error. Batch-sending miss-you copy to everyone over a risk threshold is how you manufacture complaints and unsubscribes that then pollute the next engagement score.

Do not treat the risk flag as a do-not-solicit. Legal suppression and donor-stated DNS codes are separate fields, set by the donor or by policy. A retention-risk flag is a prompt to contact with care. If you convert risk into exclusion, you hide the people annual-fund teams are hired to recover, and you starve campaign segmentation optimization of a reactivation segment that should be small, cited, and human-reviewed rather than blended into the general appeal.

Preferred channel is a recorded field

Personalization here means using the channel the donor already chose, or the last successful contact method stored as preference, not the channel that performed best in last month's appeal. If preference is blank, the draft should say so. Offer the officer a default from policy, for example last successful call or mail, and label it as a policy default. Do not write a preferred SMS path because a model thinks mobile is likelier.

Inventing a channel is a quiet failure mode. It looks like personalization and it is fabrication. It also breaks consent and preference rules your institution already maintains in the same CRM that holds the gift record.

When preference and last successful contact disagree, show both. Let the officer pick. The sequence stays owned by the officer: they can drop a touch, change the ask, or move the person to a steward-only track without clearing legal suppression.

Keep empty empty, and keep models in their lanes

If giving history is too short to describe recency, or engagement fields are null, output nothing. Empty is accurate. A medium score on a one-gift record is a made-up lapse. Staff will learn to ignore the model, or they will trust it and write a win-back that assumes a relationship the file does not show.

The same discipline applies at the boundary with other advancement models. A cooling annual-fund donor is not automatically a major gift prospect identification candidate. Capacity and relationship evidence live elsewhere. Planned-giving work is a different question. Do not route a retention-risk flag into a planned giving propensity model because the person is older or has given for several years. Each model should cite its own inputs. Shared constituent IDs are fine. Shared conclusions are not.

Operationally, give officers a way to mark not a lapse (late posting, pledge in another designation, known pause) so the next scoring run does not re-queue the same draft. That feedback is part of quality. The model remains a cited flag and a parked sequence. The officer remains the sender.

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