Fairs Reporting Hub.
The reporting hub behind a business that runs 60–80 international student-recruitment fairs a year, turning registrations into reports, breakdowns and marketing lists in minutes rather than days.
From days of manual SQL to minutes
Before it, developers ran SQL queries by hand and marketing turned the results into spreadsheets, so a report took days. The platform gives staff one shared reporting layer, and a report now takes minutes.
Per-fair reports
Registration and attendance summaries for every fair, used to sell future fairs to client institutions.
Demographic breakdowns
Age, education level, intended study destination, courses, languages, gender, referral source and campaign source.
Cross-fair comparisons
Daily statistics and side-by-side comparisons across fairs.
Marketing-list exports
Contact and interest data exported to CSV and XLSX, feeding marketing to attendees and the organisation’s CRM workflows.
On-site scanner data
Device and scanner reports, with badge-printing support, for fair-day operations staff.
Self-serve reports
Staff pull their own reports and exports, with no developer or spreadsheet in between.
Always live, never a second copy
Every report reads straight from the central fairs system, so it always shows the latest registrations and there is no duplicate data to drift or go stale. The same live reports serve staff, sales to client institutions and marketing to attendees.
Three decisions that shaped it
The first was made when we built it. The other two I made later, as Director, when the whole estate moved onto one central API.
One reporting layer
We built one shared reporting layer over the central fairs system, instead of a separate integration for each report, export and on-site tool. Every team reads the same live data.
The logic lives in the API
The estate-wide API migration I decided and directed moved the business logic behind these reports into the central API. The hub became a thin front end, so later changes are made once, in the API.
Moved early, nothing lost
I sequenced the hub among the first systems onto the new API, in 2024, and kept the old API running until nothing depended on it. The offshore team I managed carried out the move.
What I coded
I co-coded its first version and added new reporting over six years, alongside an in-house colleague and, later, an offshore team.
- Co-coded the first version of the hub that replaced hand-run SQL and spreadsheet reporting, starting from its initial scaffold.
- Built the filters and CSV/XLSX exports that turn registrations and contacts into marketing lists, wired to the central API.
- Added daily statistics and side-by-side fair comparisons, running alongside the original registration reports.
- Built the on-site app and scanner data pages, with badge-printing support for fair-day operations staff.
Tech stack
From internal reports to a product for universities
This hub turns fair data into reports for our own staff. As Director, I saw more in the same registration and badge-scan data, and proposed turning it into a product for universities, made reviewable as a working prototype.
Say hello.
Message sent.
Thanks for getting in touch.