Development Agency
Contact Sign in Get a project quote

Service

Alumni platform development

For development directors, alumni relations officers and alumni association committees at schools, colleges and universities who need a platform that knows who graduated when, lets alumni find each other on their own terms, runs reunions by cohort, matches mentors with students and supports giving, designed around the institution rather than a social network bent to fit.

Get a project quote See the software package

The problem

What goes wrong today

Where it usually starts

A university alumni office with sixty thousand records runs on the institution's main database export, a mailing platform, a reunion spreadsheet per year group and an inbox.

  • A graduate of 1998 writes to ask for the email address of a flatmate; the officer cannot pass it on without permission and has no way to ask the flatmate quickly, so the request dies.
  • The twenty-fifth reunion for the class of 2001 is organised on a spreadsheet by a volunteer who has her own copy of the contact list, which is now the most current list in existence and lives on her laptop.

Where it gets harder

A school with a smaller office has a different version of the same problem: former pupils register on a social media group that nobody from the school verifies, so a reunion invitation goes to people who never attended.

  • Students ask for careers mentors and are matched by the officer's memory of who works in which sector.
  • Giving is asked for once a year by letter, the response is recorded in the development database and never linked back to the alumni record, so the officer thanking a donor at the reunion does not know she has given for nine years.
  • Class notes arrive by email and are typed into the magazine.
  • Everyone involved cares; the tools make them look as if they do not.

Scope of the service

What the build covers

A custom alumni platform build normally covers:

  • An alumni record with graduation year Course, department, house or college and any cohort the institution uses
  • Verification of status against a graduate list held by the institution With a manual route for those who are not on it
  • A directory in Which each alumnus decides what is shown and whether they may be contacted, with a request-to-contact flow so the platform relays a first message without disclosing an address
  • Reunions and events by cohort with invitations by year group Ticketing, attendee lists visible to organisers and a volunteer organiser role scoped to their year
  • Mentoring with profiles for alumni mentors and students Matching by sector and preference, introductions, a limit on active matches and a record of outcomes
  • Giving campaigns with one-off and regular gifts A declaration captured as a dated record with the institution's wording, and a giving history on the alumni record visible to the development team
  • Class notes and news submitted By alumni and moderated before publication
  • A careers board where alumni post roles for alumni and students
  • Segment email by cohort Course, region or engagement

How discovery works

Discovery works through the alumni year with the alumni officer and the development team: how graduates are added when they leave, what verification evidence is acceptable, how reunions are run and by whom, how mentoring requests arrive, how giving is asked for and acknowledged, and what the magazine needs from class notes. Each becomes a named stage in the scope document: verify, profile, connect, reunite, mentor, give.

Deliberately out of scope

  • The student record system itself, the development team's major-gift pipeline where a separate system exists, the magazine's print production and the institution's accounting. Those stay in the tools that own them and are connected where it earns its place

When the scope grows

Scoping scenario

A university with sixty thousand alumni across twelve departments and three overseas chapters needs verification against a graduate feed, cohorts by year and department, chapter organisers who see only their region, mentoring at the scale of hundreds of matches a year with a student-facing side, and giving history synchronised with the development database. That is a different build from a school with three thousand former pupils and one reunion a year, and the scope document says so plainly.

Deliverables

What you receive

  • Discovery notes from a walk through the alumni year, the graduate list, the reunion spreadsheets, the mentoring requests and the giving process
  • A written scope document naming each stage from verification to giving, with what is out of scope
  • Design of the alumni profile and privacy choices, the directory and contact request, the reunion organiser view, the mentoring match screen and the giving form, checked on phones and desktop
  • The build, deployed to your hosting or ours
  • Migration of alumni records, cohorts, event history and giving history from the current database and spreadsheets, where relevant
  • Training for the alumni office, the development team and volunteer reunion organisers, with a short written guide
  • Handover material and full ownership of the source code and your data

Process

How a project runs

Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.

  1. Onboarding

    Access, contacts and a look at the graduate list, the alumni database export, the mailing platform, the reunion spreadsheets and the giving records.

    Project stage: Onboarding

  2. Planning

    Discovery with the alumni officer and development team; cohorts, verification evidence, privacy defaults, mentoring rules and giving records are agreed in the scope document with a milestone plan.

    Project stage: Planning

  3. Design

    Clickable designs of the profile and privacy settings, the directory and contact request, the reunion organiser view, the mentoring match and the giving form, reviewed with staff and a volunteer organiser.

    Project stage: Design

  4. Development

    Built in stages: alumni records, verification and the directory first, then events and reunions by cohort, then mentoring, then giving, class notes and the careers board.

    Project stage: Development

  5. Client review

    The office runs a test reunion for one year group and a mentoring round on migrated data and tells us where it does not match how the institution works.

    Project stage: Client review

  6. Revisions

    Verification rules, privacy defaults, organiser scope, matching criteria and giving records are adjusted from the review and re-checked against the scope document.

    Project stage: Revisions

  7. Ready for launch

    Records and history migrated, the graduate feed connected, invitations tested on addresses you control, privacy defaults verified, checklist signed off.

    Project stage: Ready for launch

  8. Delivered

    The institution runs its next reunion season and mentoring round on the platform; optional maintenance and hosting continue under their own agreement.

    Project stage: Delivered

Integrations

Commonly integrated

Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.

  • Student record systems supplying the graduate list for verification
  • Development and fundraising databases for giving history and major-gift pipelines
  • Card payment and recurring collection providers for gifts and event tickets
  • Email providers for cohort invitations, newsletters and mentoring notifications
  • Single sign-on with the institution identity provider for staff and recent graduates
  • Video meeting platforms for online reunions and mentoring sessions
  • Professional networking platforms for profile import where alumni choose it

How we would approach it

Worked example

Concept demo

A university with sixty thousand alumni, three overseas chapters and a mentoring programme

The situation

A university alumni office held sixty thousand records exported from the student system, ran reunions from year-group spreadsheets kept by volunteers, matched student mentoring requests by memory and recorded gifts in a development database that the alumni team could not see. Overseas chapters kept their own lists.

Why it is a custom build

This needs a custom build because verification, cohorts and the development connection are specific to the institution's systems, which a generic community or networking product cannot be configured to read.

The scope we would propose

  • A nightly graduate feed that verifies new registrants automatically with a manual route for the rest
  • Cohorts by year and department driving invitations and reunion pages
  • Chapter organisers scoped to their region with their own events
  • A directory where each alumnus chooses visibility and whether contact requests are relayed
  • A mentoring module with sector-based matching, a cap on active mentees per mentor and an outcome record each term
  • A two-way connection to the development database so giving history is on the alumni record and gifts made on the platform flow back

Concept demo: a scoping scenario written to show how we would approach the work. It is not a delivered client project.

Pricing

What affects the price

Every proposal is priced on scope. These are the factors that move it most for this kind of build.

  • Number of alumni and the cohort structure: years, courses, departments, houses, chapters
  • Verification against a graduate feed and the manual route for those not on it
  • Directory privacy model and contact request relay
  • Reunions and events by cohort with volunteer organiser roles
  • Mentoring programme scale, matching criteria and student-facing side
  • Giving campaigns, declaration records and connection to a development database
  • Class notes, careers board and moderation workload
  • Hosting choice: your own hosting or ours

Start from a package

Alumni network package

Verified alumni by year group and course, a directory with contact permission, reunions by cohort, mentoring matches, class notes, a careers board and giving for schools, universities and alumni associations.

Custom build
View the package

FAQ

Frequently asked questions

When is the package enough and when do we need a custom build?

The alumni network package covers verification against an uploaded graduate list, cohorts, a directory with privacy choices, reunions, mentoring, class notes, a careers board and giving with configuration. A custom build is the honest answer for a live feed from the student record system, a two-way connection to a development database, overseas chapters with their own finances or mentoring at the scale of a whole faculty. Discovery tells you which before anything is quoted.

How are alumni verified?

Against the graduate list the institution supplies, by name, year and course or a student number where you hold it. Registrants who match are verified automatically; the rest go to the alumni officer with whatever evidence you ask for. Unverified accounts see nothing beyond the public pages.

Can alumni find each other without us handing out contact details?

Yes. Each alumnus chooses what the directory shows and whether contact requests are allowed. A request is relayed by the platform with the sender's message; the recipient decides whether to reply, and no address is disclosed until they do.

Can giving on the platform connect to our development database?

Where the database offers an interface, yes: gifts made on the platform are pushed to it and giving history is shown on the alumni record to the development team only. What the database permits is checked during discovery and stated in the scope document as an integration opportunity. The declaration is captured as a record; the reclaim remains the institution's process.

Who owns the system afterwards?

The institution does. Source code and data are handed over at delivery; hosting and maintenance are optional and separately agreed, and the platform can move to another provider.

Get a project quote for alumni software

Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.

Get a project quote Discuss a partnership
Get a project quote

Cookies on this site. Strictly necessary cookies keep the site working. Allow first-party analytics so we can see which pages lead to enquiries. No advertising, no third-party trackers, no personal data; you can change this at any time on the cookies page.

Manage preferences