Alumni Giving Propensity Model

An alumni giving propensity model ranks living alumni by how likely they are to make a gift in a defined window, using engagement history, giving records, and approved wealth signals. The output is a score plus the field cites that produced it. It is not a pledge, not a recommended ask amount, and not permission to invent a gift on a thin file.

If the record is thin, the score stays empty. Empty is the correct result when giving history is missing, engagement events cannot be attributed, or wealth fields were never approved for this use. Development still owns the ask: the model only orders outreach so officers spend time first on alumni whose files actually support a conversation.

Treat the score as a queue priority, not as a forecast you can quote to a trustee. Adjacent work such as major gift prospect identification answers a different question: who has the capacity and relationship depth for a principal or major gift conversation. Mixing those jobs produces a costly failure in this class of models: an officer asks from a propensity rank as if it were wealth screening.

Pull first-party giving and engagement before you attach any third-party wealth append. Giving records should include gift dates, designations, payment methods, campaign codes, pledge versus cash, and whether the gift was matching, tribute, or reunion-tied. Soft credits, householding, and joint gifts must be resolved the same way advancement services already resolves them for reports. Otherwise the model double-counts a couple or drops a spouse who never appears as the hard-credit donor.

Engagement history is everything already stored in the advancement CRM as an attributable interaction: event attendance, volunteer roles, class notes responses, mentoring, athletics affinity, career services use, and digital clicks only when those clicks are first-party events with a known constituent ID. Do not scrape social media into the score. If an engagement type is not in the system of record, it does not exist for scoring.

Approved wealth fields are a short, documented list: screening scores or estimated capacity bands your institution already licenses, self-reported occupation and employer when alumni provided them, and real-estate or company indicators only if counsel and advancement services have signed off on that append for modeling. Unapproved appends stay off the feature list even if a vendor makes them easy to load.

Treat Ellucian, Salesforce, Workday, and Anthology as one class of advancement CRM and campus systems of record, not as a ranked shortlist. A warehouse those platforms feed is equally valid. Features must be fields a gift officer can open on the constituent record. If the officer cannot see the cite, the model cannot use the field.

Define the prediction window in writing before you train or refresh: a cash or pledge gift of any amount in the next fiscal year, excluding planned-gift expectancies. That window is not interchangeable with planned giving propensity model scoring. Annual-fund and planned-gift likelihood are different behaviors and should not share a single rank.

Build the training set from closed fiscal years only. Exclude deceased, do-not-solicit, and legally restricted records from both training and scoring. Household at the unit you actually solicit. If you solicit individuals, score individuals. If you solicit households, score households. Mixing units is how a spouse with no giving history inherits a high score from a partner's gifts.

Score only when the required cites are present. A minimum viable file might require at least one attributable engagement or gift event plus identity resolution to a living alumnus. Below that threshold, leave the score blank and surface a reason code such as insufficient giving and engagement history. Do not impute a gift. Do not backfill a last-gift date. Do not treat a wealth band as a substitute for giving behavior.

Refresh on a cadence advancement operations can support, typically aligned to fiscal close or a campaign segment drop, not daily. After each refresh, export the score, the window, and the cite list (which giving, engagement, and wealth fields fired) onto the constituent record or a related scoring object. Officers should not have to open a data-science notebook to see why someone ranked high.

Illustrative path: a class of 2008 alumnus has reunion event attendance, a string of small annual gifts with a gap during a job change, and an approved occupation field of partner at a known firm. The model can return a mid-to-high annual-fund propensity with cites to those gifts, the reunion record, and the occupation field. A classmate with a clean ID, no gifts, no events, and no approved wealth fields gets no score. The empty result is the system working.

The gift officer, or the annual-fund manager for unassigned names, reviews the scored queue before any solicitation. Review means reading the cites, checking recent notes, and deciding whether the next contact is a thank-you, a volunteer ask, a segmented email, or nothing. The score does not become a pledge in a campaign report and does not auto-create an opportunity.

Asking from a thin file is the failure mode this review exists to stop. A high rank with two cites, both stale, is a research task, not an ask. If the officer cannot explain the score in a sentence using fields on the record, they should not use it in a call.

Treating propensity as a pledge is the second failure. Leadership sometimes wants expected annual-fund revenue from the model. Refuse that translation. Propensity is ordinal: it orders who to contact first. Conversion, average gift, and revenue still come from actual gifts and from campaign segmentation optimization work that assigns channels and offers after the score exists.

Use the score to time and prioritize, then let donor retention risk model flags sit beside it for current donors. A high-propensity lapsed donor and a high-risk consecutive donor are different conversations. Do not collapse them into one list sorted only by propensity.

Document exceptions. If an officer skips a high-score name because of a known life event, that skip should be a coded reason, not a silent ignore. If they upgrade a blank-score name because of a personal relationship, that is allowed: development owns the ask. The model does not veto human judgment. It also does not replace it.

Major-gift identification, planned-giving propensity, retention risk, and campaign segmentation all consume overlapping CRM fields. They must remain separate scores with separate owners and separate uses in the ask process.

Propensity for an annual or reunion gift estimates likelihood of a gift in the near term. Capacity and relationship depth for a major gift inform portfolio assignment. Planned giving estimates whether an estate or life-income conversation should open. If you merge those into one good-donor rank, officers will either under-ask major prospects or over-ask annual-fund names using wealth language the file does not support.

Advancement services owns field definitions and refresh jobs. Prospect research owns which wealth fields are approved. Annual giving or development operations owns the queue rules. Gift officers own contact and ask. Data science or a vendor implementation team owns the model card: window, features, exclusion rules, and the empty-if-thin policy. When those roles blur, the score leaks into pledge forecasting and into portfolio assignment it was never designed to drive.

Vendors in the Ellucian, Salesforce, Workday, and Anthology class can host constituent, gift, and engagement objects. None of them should be treated as a unique propensity product you must buy. Institution rules travel with the model regardless of where it is trained: empty when thin, cites required, officer review, no invented gifts.

The operational test is straightforward. A development lead should open an alumnus record, see a score or an explicit empty, see the engagement, giving, and wealth cites, and still decide the ask themselves. If the record looks complete because the score filled gaps the file never had, stop the refresh and restore empty.