AI Adoption GuideEducationAdvance
Major Gift Prospect Identification
ML integrates wealth screening, giving history, and engagement signals to rank and classify major gift prospects.
Education processRecruitAdmitEnrollTeachAssessCredentialGraduateAdvance
By Don, DoneThat’s AI coach · updated
What a gift officer should receive
A ranked major-gift prospect is a person or household with a review order and citations to wealth, giving, and engagement fields the shop already trusts. The rank is a queue for research and for the officer's next look, not a gift amount and not an assignment. If an approved wealth screen is missing, capacity-related fields stay empty. The gift officer still decides who enters a portfolio.
Prospect research exists so that argument does not have to be rebuilt from a CRM export before every visit. The record that appears in Salesforce, Ellucian, Workday, or Anthology should show who this is, why they sit at this rank, which source fields were used, and what is still unknown. A blank capacity slot is a complete answer when screening was never run or did not return a usable row.
This page covers identification only. Who is likely to give in a given cycle, often at annual-fund scale, belongs to an alumni giving propensity model. Folding that score into a major-gift rank puts visits on people who look responsive but have no documented capacity.
Fields you can cite, and fields that stay blank
Cite wealth only from the shop's approved screening source or from a research note that names that source, with an as-of date. Licensed ratings and the public-record flags that file actually contains belong here. Job title, neighborhood, or a rumor in a solicitor comment is not a wealth field. If the screen is older than the shop's refresh policy, exclude it from ranking or show the date so the officer can see the age. Do not backfill a rating because the rest of the row looks strong.
Giving history is first-party only: lifetime giving, largest gift, recency, consecutive years, designations, pledge versus cash, and solicitor of record if the CRM stores it. These fields live in the advancement system of record. A wealth rating is not a gift. A blank giving history is not evidence that the person has never been asked. That is a research question, not an inference the rank is allowed to make.
Engagement is whatever the shop already stores in a form another researcher can reopen: reunion or event attendance, volunteer and committee roles, board service, campaign volunteer flags, and structured digital activity if those fields are defined. Unverified comments stay notes until someone confirms them and writes them into a field the model may read.
When one of the three pillars is missing, the person can still sit on a worklist among peers with similar completeness. The rank then means review this incomplete record, not this person has major-gift capacity. Empty stays empty.
How to merge wealth screens with first-party records
Treat the merge as a join on constituent or household ID, not as a blended impression that someone feels like a major prospect. Start from the ID in the system of record. Attach the latest approved wealth record on that ID, including source name and as-of date. Attach giving aggregates and designation history. Attach the engagement flags research has already defined. Quarantine rows that cannot join. Do not fuzzy-match a wealth file onto a common name and call the wealth fields cited.
Wealth files usually arrive from a screening partner and land as related records next to CRM data. That CRM and engagement data often sit in Salesforce, Ellucian, Workday, or Anthology. Identification should not depend on which of those products is the front end. It should use the same join keys, dates, and field names a rating memo already uses.
Do not let the model invent capacity from occupation, inferred home equity, or a propensity score. If screening is missing, leave the wealth cells blank and keep the person eligible only for a completeness-aware review rank, never for a capacity label.
Two classmates appear on the same reunion RSVP list. One has a current approved wealth screen, a streak of consecutive annual gifts, and a campaign committee role on the constituent record. The other has the same RSVP and a similar giving streak, but no wealth screen and no research note. Both can appear on a research worklist. Only the first can carry a cited wealth field. The second stays listed as giving plus engagement, with capacity blank. Ranking them as the same class of prospect is how a thin screen becomes an assignment.
If the second person later receives a licensed screen, the wealth fields populate and the rank can be recomputed. Until then, do not copy a peer's rating, a class-year stand-in, or a model guess into the empty cells.
Rank, research review, then officer assignment
Ranking is a review order. Higher rank means look at this person before that person, given the fields that are present. Defensible ingredients include documented giving already in or approaching the shop's major-gift threshold, recency and consistency of giving, engagement that implies access (committee, volunteer, reunion), and an approved wealth record that is present and in date. Dollar cutoffs belong to gift-acceptance policy and campaign planning, not to this identification step.
Build the rank only from fields that survived the merge. If wealth is blank, do not impute a value to keep someone in a capacity sort. You can still sort incomplete rows among themselves by giving and engagement so research knows whom to screen next. That is a screening queue, not a major-gift rating.
Research reviews the ranked row before it is offered as an assignment. Confirm the cites are real field names with dates and sources, the wealth record is the approved file, and the person is not deceased, do-not-solicit, already assigned, or in a known conflict. Decide whether two IDs are one household. Look for a leaked annual-fund propensity score in the rank. If any of those checks fail, send the row back to research rather than to an officer.
Only after that review does assignment happen, and the officer makes it. Identification can recommend a pool and a sequence for looking at the pool. It cannot drop a name onto a caseload because the rank was high. If the officer declines, the row remains a ranked, cited prospect.
Mistakes that look like a finished list
Assigning from a thin screen is the usual shortcut. A licensed rating with almost no first-party giving and no engagement can still be cited as wealth. It is not a reason to add someone to a portfolio. The honest next step is a research request: confirm the screen, look for giving and engagement missed in the join, or leave the person unassigned.
Treating a rank as a capacity number is the second shortcut. A position in a file is not a working ask, and a percentile is not a gift range. If the shop needs a working ask, that comes from gift history, the rating method research already uses, and the officer's judgment. The identification rank does not mint a new capacity figure and must not overwrite an empty capacity field with a derived dollar amount.
Mixing this list with annual-fund propensity is the third. The alumni giving propensity model is built to find likely donors, often for the fund. High propensity plus modest giving and no wealth cite belongs in campaign segmentation optimization, not in a major-gift queue. Keep planned giving propensity model scores in the legacy pipeline. Keep grant and foundation prospect research in the institutional pipeline, so an officer is not handed a foundation contact as if it were an individual major-gift prospect.
Finished identification is a ranked worklist where every row can be audited, blanks remain blanks, research has signed off, and assignment is still a human decision. Refresh when screens refresh, when giving or engagement updates, and when research marks a record verified. Do not re-rank in a way that silently moves someone who is already assigned.
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