Why licence quotes mislead
Two vendors can quote nearly identical licence numbers and differ by a factor of several in real annual cost. The licence is the most visible line and usually not the largest. In our evaluation work, the honest unit of comparison is total annual cost to operate, and it has four components: licence, integration, admin and ops load, and data-quality operations. The framework below gives each component a worksheet structure. We deliberately publish no price points here: vendors price differently, most quote only under NDA, and any number we printed would age badly. The shape of the cost, however, is stable.
Component 1: Licence — understand the pricing dimension first
Alumni platforms use three main pricing dimensions, and the same platform sometimes blends them:
| Dimension | You pay for | Risk profile | Best suited to |
|---|---|---|---|
| Alumni records in the platform | Total records imported (e.g. per-thousand tiers) | Cost scales with your entire history, including dormant alumni who never log in | Programs that want the full base searchable, including offline records |
| Active/maintained users | Members who register or log in within a period | Cheap early; grows exactly as the program succeeds, and the definition of "active" is negotiable at renewal in the vendor's favour | New programs with unknown adoption |
| Module/segment licences | Capability bundles (directory, events, mentoring, AI matching) | Low entry, but the module you actually need — often the AI-layer search, roadmap, or matching features — sits in the top tier | Buyers certain of their scope for the full contract term |
Two checks before modelling any of them: (1) get the tier thresholds and the overage mechanism in writing, and (2) model the three-year case, not the year-one case. A records-priced quote at your current import size ignores the fact that every leaver becomes a new record and the base only grows.
Component 2: The integration bill
Integration cost has three layers, and vendors quote only the first.
– Build: the professional-services engagement to connect HRIS, CRM, SSO, and marketing automation. Native connectors collapse this; services-built connections inflate it, and the quote should state which is which.
– Change: what you pay when an upstream system changes its API or you swap an adjacent system. Ask the vendor to state the change-rate card and, crucially, whose problem a connector break is under the support agreement.
– Drift: the recurring reconciliation work when two systems disagree about the same alum. This one is invisible in every quote and very real in every operations team we have spoken to.
A practical test: subtract the assumed integration cost from the "light" proposal and see what was assumed — often it is "your team does the CSV work," which is a cost, just not one the vendor books.
Component 3: Admin and ops load
The platform needs an internal owner, and the question is how many of them. Estimate in days per month across:
– Provisioning, permissions, and chapter/segment administration
– Content and engagement operations (newsletters, event setup, moderation)
– User support — password, profile, and "I can't log in" volume scales with base size
– Reporting: extracting the numbers leadership asks for, in the format leadership asks for them
Ask the vendor's reference accounts directly: how many FTEs run this, and what do they spend those hours on? Reference-account answers on ops load are the single most reliable number in this entire framework, because admins have no incentive to flatter the software they live in.
Component 4: Data-quality operations
This is the component nobody budgets and everybody pays. An alumni platform is only as good as the underlying record, and alumni records decay — people change roles, emails, names, countries. Budget for:
– Initial import and dedupe: merging levers of different vintages from HRIS, old CRM exports, and spreadsheets. At enterprise scale this is a project, not an afternoon.
– Ongoing refresh: employer verification on join, bounce handling, periodic re-permissioning of stale records, and enrichment of career-progress data. If you plan to use AI-layer features — natural-language search, career roadmaps, alumni-to-opportunity matching — the refresh burden is higher, not lower, because confident matching over stale data produces confident nonsense.
– Governance: retention policy execution, deletion-request handling, and audit. Under GDPR-class regimes this is not optional and has a real per-request labour cost.
The framework table
| Cost component | Vendor quote covers | You must model | Key question to ask |
|---|---|---|---|
| Licence | Yes | 3-year growth: records, actives, modules | "Show me the overage mechanism and tier steps." |
| Integration build | Partly | Which connectors are native vs services | "Which integrations are products, which are projects?" |
| Integration change/drift | Rarely | Upstream API changes, system swaps, reconciliation hours | "When X breaks, who fixes it and who pays?" |
| Admin/ops | No | Owner FTEs × days/month | "Ask your reference: how many people run this?" |
| Data-quality ops | No | Dedupe at import, refresh, governance, deletion handling | "What does the AI layer require our data to look like?" |
How to use it
Build one worksheet per vendor with all four components across three years, at your expected adoption and at 150% of it. The vendor that looks cheapest at year one frequently is not by year three — records-priced models overtake seat-priced ones, and the "free" services integration becomes an annual maintenance line. When two vendors land within roughly a fifth of each other on modelled cost, stop optimising price and start optimising delivery risk: data format, exit terms, and reference-account pattern are the better tiebreakers, because the cost of a failed program dwarfs any line in this framework.