Skip to main content
DoneThat

AI Adoption GuideEducationAdvance

Planned Giving Propensity Model

ML identifies alumni segments likely to include the institution in estate plans based on age, wealth, engagement, and life event signals.

Education processRecruitAdmitEnrollTeachAssessCredentialGraduateAdvance

By Don, DoneThat’s AI coach · updated

What the propensity flag may claim

A planned-giving propensity flag is a review signal, not evidence that an alum has included the institution in an estate plan. The model ranks constituents who, given age, wealth, engagement, and allowed life-event fields already on the record, look more worth a planned-giving conversation than peers with weaker or missing signals. It does not name a bequest. It does not choose a gift vehicle. It does not authorize copy that thanks someone for a provision they have not confirmed.

The quality bar is a flag plus cites. A high or medium score should point at the fields that moved it: stored age or class year, wealth or capacity indicators the shop is allowed to keep, engagement history, and any life-event fields policy permits. If those fields are missing, the score stays empty. Guessing a retirement, a health crisis, or a spouse's death to "complete" the picture is inventing a life event.

Officers still own the conversation. Campus CRMs and advancement suites in the same class as Salesforce, Ellucian, Workday, and Anthology can store the flag, the cites, and a review-queue status. None of that is a documented intention.

Age, wealth, engagement, and life-event cites

Age is usually the most stable cite. Estate conversations cluster among alumni who have had time to build assets and to execute documents. Cite the stored date of birth, age band, or class year. Do not infer age from a reunion photo, a giving club name, or "they sound older on the phone." If age is blank, do not impute it from wealth or from years since first gift.

Wealth cites stay inside what advancement may retain: screened capacity bands, asset types already on the record, or other indicators counsel has approved. High capacity is not a bequest. It also does not retire the need for major gift prospect identification. The same household can support a current major gift and an estate conversation.

Engagement cites must be observable on the record: consecutive giving, volunteer roles, event or reunion attendance, advisory service, or logged contacts. Consistency over a long horizon matters more than one large annual gift. A lapsed annual donor with a long prior pattern can still belong in planned-giving review. That is why this flag should be read next to a donor retention risk model, not used as a substitute for it. Retention risk says the annual relationship may be slipping. Planned-giving propensity says an estate conversation may still be worth the officer's time. Both can be true on one record.

Life-event cites are the easiest to abuse. Allowed inputs are fields you already capture with a source and a date: retirement status, a recorded business sale, widowhood when the family notified you, a documented marital-status change. The model may use those fields when they are present. It may not invent a diagnosis, a grandchild, or an empty-nest story because the age band makes that story convenient. If life-event fields are empty, the flag either scores without them and says "none present," or the score stays empty. Empty stays empty.

Do not let campaign operations fold an unreviewed flag into campaign segmentation optimization as if it were a bequest audience. An annual alumni giving propensity model answers who is likely to give this year. Dropping estate language into a mass appeal because the planned-giving score was handy is mailing a bequest ask from a flag.

Score, leave blanks empty, then queue for review

Score only from cited allowed fields. The constituent output should show a band or score, the date scored, and a short cite list (age, wealth band, engagement pattern, life-event fields used or none present). Suppress or leave blank when the required cites cannot be formed. Do not backfill age from wealth. Do not treat a wealth screen as engagement. Do not treat engagement as a life event.

Route high and medium scores into a planned-giving review queue, not into a mail file. The reviewer checks cites against the record, notes solicitor assignment and any live major-gift activity, and then schedules a conversation, holds, or clears the flag. Clearing a record is a quality outcome. A false-positive that never reaches the prospect costs less than a letter that assumes a will.

If the cite list is missing, send the record back to data, not to the mail vendor. If a required field was empty and the model still emitted a high score, that is a defect, not a clever imputation. Fix the model. Do not complete the story in the contact notes.

One alumni record, scored without a story

Take an alumna with class year on file putting her in her late sixties, a capacity band already in the wealth screen, a long run of consecutive annual gifts, reunion volunteer service in the last cycle, and no life-event fields populated. The model can cite age, wealth band, and engagement. It cannot cite retirement, a house sale, or a death in the family. The correct output is a propensity flag with those three cites and an explicit "life-event fields: none." The record goes to planned-giving review.

Three failures to block on that same record. First, appeal copy that says "as you update your estate plans in retirement," when retirement was never stored. That invents a life event. Second, a thank-you or newsletter line that refers to "your planned gift" or "your bequest provision." Propensity is not a documented intention. Third, merging her into an annual-fund segment that always carries a "leave a legacy" paragraph because the score was convenient. The specialist still has to ask whether she has an estate plan, whether charitable provisions are under discussion, and whether the institution belongs in it. If she says no, do not write "no bequest" onto the record unless she asks you to. The flag remains a review signal you can rest or re-score later.

The officer's conversation, not the model's

The meeting is discovery, not confirmation of a machine result. Steward the loyalty that is already on the record. Offer to talk about how alumni provide for the institution over time. Share sample bequest language only if she wants it. Keep the score in the briefing packet. It does not belong in the email, and it does not belong in a proposal unless counsel has a documented provision to acknowledge.

If she volunteers a bequest, record it through the planned-giving confirmation process your shop already uses: vehicle, whatever timing she shares, and her permission to count or not count it under gift-acceptance policy. That confirmation is a different object from the propensity flag. Mixing them trains the next model to treat a rumor as an intention.

When wealth and engagement also suggest a current major gift, coordinate assignments. A propensity flag is not a reason to pause a solicitor who already has a live conversation, and it is not a reason to skip planned giving because another score looks higher. The officer decides sequencing.

Re-score on a schedule or when allowed fields change. A newly recorded retirement, a documented marital-status change, or a capacity update can move someone into the queue. A field that did not exist last quarter should be able to create a score where the record was empty. Until the field exists, leave the score empty rather than interpolating.

Whether the flag lives in Salesforce, Ellucian, Workday, Anthology, or another system of record, keep the implementation dull: cites on the record, empty when inputs are missing, a human review queue, and no automated bequest language. Trust the flag enough to open a careful conversation. Ignore it when the data is not there.

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. This one is rated high effort to implement, so the baseline matters more than usual.

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