The principle
Every alumni-platform vendor's brochure in 2026 claims natural-language search, AI-assisted matching, enterprise-grade security, and a customer base of household names. Some of those claims are true everywhere they appear; some are true at one customer; some are true only at the vendor's demo tenant. An RFP cannot audit truth directly, but it can price dishonesty: questions that demand artefacts, references, and contractual commitments make vague answers visible. The template questions below are organised around what each is designed to force into the open.
Section A — AI features: proof, not demo
A1. List each AI feature by status: generally available to all customers; available to a named subset; in private beta; roadmap. Status phrasing matters. "Available" should mean a paying customer uses it in production today, and the vendor should be willing to name one under NDA. Anything else is lifecycle marketing.
A2. For natural-language directory search, describe your evaluation methodology and share a summary of the current eval set. This is the single hardest AI question to bluff. A vendor doing real query-oriented search maintains a versioned battery of queries with known-good answers and runs it on every model change, the way a database vendor runs benchmarks. Ask what they measure (top-k relevance across the test battery is the honest shape), how the eval set was constructed, and when it last caused them to hold a release. A vendor with no eval discipline cannot answer; a vendor improvising will describe a demo script.
A3. For alumni-to-opportunity matching or AI career roadmaps: on what data conditions do these features depend, and which of our data-quality risks would degrade them? Credible vendors answer this reflexively — verified employment history, deduplication tolerance, freshness windows. The vendor who claims their matching works on any data has sold you a rules engine with a chat interface.
A4. Describe a pilot we can run on a bounded slice of our own alumni base, including success criteria we define. The artefact here is the pilot itself: real queries, your data, your reviewers. Vendors confident in delivery accept bounded pilots; vendors confident only in demos describe pilots as unnecessary.
Section B — Security and data protection: artefacts, not adjectives
B1. Provide current independent assurance reports (penetration-test summary, SOC 2-class report, ISO-class certificate) with scope statements. Scope is the tell. A certificate covering "corporate IT" but not the platform you are buying is decoration. Ask what product components are in scope and the report period.
B2. Provide your subprocessor list, data-residency options, and deletion-workflow description, including how deletion propagates to backups, analytics stores, and any AI/embedding indexes. The last clause is the modern discriminator: a vendor running AI-native search over your alumni graph must be able to explain how erased individuals are removed from embedding indexes, or state plainly that they cannot yet. Either is informative.
B3. State contractually whether customer data is used to train models shared across customers, and the mechanism of any opt-out.
Section C — Reference accounts: the pattern, not the names
Named references are curated; patterns are not. Ask for:
C1. References segmentable by: industry comparable to ours, base size comparable to ours, implementations ≥24 months old, integrations comparable to our estate (same HRIS, same CRM), and customers using each AI feature we intend to adopt. A vendor with real depth can produce this matrix; a vendor with three happy customers cannot.
C2. One reference that chose you over the vendor we are most likely to select instead. Whoever that reference is, their reasons are the best competitive intelligence you will get for free.
C3. One former customer we may call. This one is frequently declined — record that. A vendor who has never lost an enterprise account either is very young or curates hard. Age is not a sin; curation without disclosure is.
C4. Any documented migrations of customers from other platforms onto yours in the past few years, and what drove them. Documented migration volume in your direction is the strongest third-party evidence of delivery. There is a visible pattern in this category of top professional-services firms consolidating onto a small number of platforms; make your vendors tell you their side of it.
Section D — Roadmap commitment: what survives signature
D1. Attach the current roadmap and mark which items are contractually committable. Expect few marks. That is fine; it calibrates everything else they said.
D2. For each AI feature we intend to buy, state what happens contractually if it is not delivered by a defined date — service credits, price step-down, or an out clause.
D3. Define end-of-life policy: minimum notice period, data-export formats guaranteed on exit ( including media, engagement history, and any AI-layer artefacts), and migration assistance at capped rates.
D4. State what happens to our contract on your change of control. This category is consolidating; industry research describes the market settling around a small number of dominant platform providers. The odds are real that any mid-list vendor is acquired, absorbed, or wound down during a multi-year contract, and the answer to D4 is your seat at that table.
Scoring the answers
We suggest a simple rubric: for each question, score _evidence produced_ (artefact, named reference, contract term) as 2; _specific verbal answer_ as 1; _reassurance language_ as 0. Reassurance language is cheap exactly in proportion to how expensive the underlying claim is to fake. The vendor that leads on evidence scores across sections B, C, and D is very rarely the wrong choice — and the vendor whose score concentrates in slide-quality answers to section A has told you, in their own words, where the brochure ends.