AI fundraising software RFP template: evaluate the workflow, not the pitch

Open the RFP with one or two workflows where delay already costs trust or staff capacity. Useful candidates include post-event follow-up, scholarship stewardship, annual-fund renewal, major-gift meeting prep, pledge-risk review, or lapsed-donor reactivation. Name the current trigger, owner, handoffs, proof requirement, donor-facing deadline, and known failure point.

Ask each bidder to respond against the same workflow. This prevents a category error in which one vendor demonstrates email drafting, another demonstrates prospect scoring, and the buying team tries to compare both with a single feature total. The useful comparison is whether each approach can turn the same CRM signal into prepared, governed human action.

State what is out of scope for the first phase. A narrow procurement brief is more credible than a request to automate the entire advancement office. It also gives references and pilot users a concrete operating claim to verify.

Workflow fit: ask how the system detects the trigger, assigns the next action, handles exceptions, and shows stalled work. CRM fit: ask which records are read, where decisions are written back, how duplicate or stale context is handled, and how the vendor avoids creating a shadow system of record.

Source and proof: require generated briefs or recommendations to distinguish known facts, missing information, and inferences. Human governance: require named approval gates, stopping behavior, escalation paths, and a record of who approved donor-facing action.

Donor-data controls: ask about access boundaries, retention, deletion, model-training use, subprocessors, audit logs, incident response, and the evidence available for each answer. Implementation: ask for the people, integrations, data preparation, training, support, and customer responsibilities required for the first workflow. Learning and measurement: ask how outcomes update the playbook and how the pilot will measure movement without relying on content volume.

Workflow response: ‘Using the donor workflow in this RFP, describe each step from trigger through owner assignment, source assembly, proof check, human approval, donor-facing action, and outcome capture. Identify which steps are standard configuration, custom work, partner-delivered work, or unsupported.’

Evidence response: ‘For every statement about CRM integration, security, privacy, accessibility, implementation effort, and support, provide the document, product view, contract term, or customer reference the evaluation team can inspect. Distinguish capabilities available today from roadmap items.’

Operating response: ‘Name the customer and vendor roles required during implementation and routine use. Provide the proposed first-workflow timeline, dependencies, training plan, support path, pilot measures, data export or deletion path, and conditions under which you would advise the customer not to automate the workflow.’

Give finalists three versions of the same donor moment. Green has sufficient context, a clear owner, approved proof, and a routine review path. Yellow is useful but incomplete: perhaps stewardship evidence is missing or the relationship owner is unclear. Red contains a restriction, sensitive note, unresolved promise, or approval requirement that should stop donor-facing automation.

Ask the vendor to show what the system does—not only describe it. Can a reviewer find the source record behind a recommendation? Does missing proof create a visible blocker? Can the system wait for a fundraiser, stewardship lead, finance partner, or manager? Does it preserve the reason a record was paused?

Graceful refusal is procurement evidence. A system that always produces a polished answer may create more review work and more donor risk than one that makes uncertainty, ownership, and stopping behavior obvious.

Reference questions should test the work behind the demo. How much data cleanup was required? Which workflow reached routine use first? Where did staff still reconstruct context manually? What review gate prevented a mistake? Which integration or policy assumption changed during implementation?

Ask who owns the system after launch and what happens when the first champion leaves. A procurement decision should account for administrator effort, fundraiser adoption, advancement-services capacity, support responsiveness, playbook maintenance, and the path for removing or exporting organizational memory.

Do not ask references only whether they like the product. Ask them to reconstruct one donor signal from trigger through action and learning. The specificity of that answer is more useful than a general satisfaction statement.

Define a first-workflow pilot before broad rollout. Record the baseline, required source context, named owners, human gates, expected preparation output, support cadence, and review date. Keep AI in the preparation layer until the team can inspect quality, proof, and escalation behavior.

Use leading indicators the team can verify: triggered records with owners, time from signal to prepared brief, missing-proof blockers surfaced, gates cleared, stale follow-ups reduced, and decisions captured into the playbook. Do not accept drafts generated or tasks created as proof of donor momentum by themselves.

Write the scale, redesign, and stop conditions in advance. Scale when the workflow moves reliably with inspectable sources and human judgment. Redesign when a named integration, ownership, or proof gap is fixable. Stop when the workflow depends on unsupported inference, unsafe data handling, or more manual reconstruction than the existing process.