The system of record a seven-country business runs on.
A proprietary admissions, partner and finance platform I took from ideation and HTML prototypes to production, then brought in-house. It serves both sides of the business: B2B, where 500+ partner agents submit and track their students’ applications and see their commission, and B2C, where students apply directly, with a student portal about to launch. Counsellors, compliance and finance work from the same record, and a new destination is configuration rather than a rebuild.
9Study destinations, UK and Europe, one shared core
500+Agent and partner organisations onboarding
300,000+Student records held
1 → 9Destinations added in six months
The problem
Where it startedTwo countries run on spreadsheets, then on Monday.com. It worked at that size, but every new destination brought its own application flow, visa regime and compliance rules, and the business was about to add seven.
Why it was hardTwo audiences on one record: 500+ partner agents on the B2B side and students applying directly on the B2C side. UK and EU immigration frameworks that differ stage by stage. A sister company sharing the platform. And an external development partner building it.
What was at stakeCommission reconstructed in Excel and email, and growth that would otherwise have meant hiring people to hold the process together rather than building a system that holds it.
My part
Developers wrote GSP’s code. I designed it, specified it and led the people who built it, and this is precise about which of those I did where. Where I designed and specified, developers built from HTML prototypes I made, so the screens on this page started as my prototypes.
DESIGNEDI conceived it and architected how it works.
SPECIFIEDI turned it into HTML prototypes and briefs that showed developers exactly what to build.
LEDI coordinated and governed the build, and signed off every release.
IMPLEMENTEDI configured or built it myself.
HIREDI recruited the people who now build it.
| AREA | MY PART | WHAT IT IS |
|---|---|---|
| Monday.com operating system | DESIGNEDIMPLEMENTED | Every module built from scratch; the blueprint GSP was designed from. |
| GSP overall | DESIGNEDLED | From ideation to the system of record across seven markets. |
| Multi-destination pipeline | DESIGNEDLED | UK and EU flows on one shared core. |
| Agent portal and onboarding | DESIGNEDLED | The B2B side, rolling out across 500+ partners. |
| Student portal | DESIGNEDLED | The B2C side, launching soon. |
| Commission engine | DESIGNEDSPECIFIEDLED | Claims from institutions, payouts to partners. |
| Dashboard and data health | DESIGNEDSPECIFIEDLED | Role-curated reporting across nine destinations. |
| Email automation | DESIGNEDSPECIFIEDLED | Admin-configured stage emails with a delivery log. |
| Flow Builder | LED | GSP’s own automation layer, in build. |
| Development team | LEDHIRED | Three software engineers, a QA engineer, a DevOps engineer and a designer. |
Commission
GSP module in buildMoney in from institutions. Money out to partners. One source of truth.
Commission is where an education business either knows its numbers or reconstructs them in Excel and email. I built it twice: first from scratch on Monday.com, alongside every other module the business ran on there, and now as a native GSP module that reads straight from the application, so a claim is always true to the state of the student it belongs to.
Phase 1 · Built from scratch on Monday.com
Enrolled boards, by intake
Claiming commission from universities and pathway providers, with a Finance View that set the column standard.
Agents Commission board
Paying agents and referral partners for the students they brought in.
Phase 2 · Native in GSP
Commission Claims
Institution claims, grouped by university or admission provider, with currency following the institution’s region and the invoicing company set per institution.
Agents and Partners
Agents, who see their claims in the GSP agent portal, and referral partners, who have no login but must still be paid and stay visible.
Flow A · Claiming from institutions
- 01 →Enters from CAS ReviewEnrolment is the default view. Drop Out with CAS never enters, since it can never be commissioned.
- 02 →Mirrors the recordStudent, course, intake and year stay in step with the Application and Institution modules.
- 03 →Calculates, stays editableAny value can be rewritten; every dependent figure recalculates.
- 04 →Invoices correctlyInvoicing company and currency follow the institution.
- 05 →Settles in placePart and full payments on the claim itself, exported for Finance in one download.
Flow B · Paying agents and referral partners
- 01 →Statement issuedWhat is paid and what is owed, per partner.
- 02 →Accept, dispute or rejectWith reasons, modelled on the agent contract flow.
- 03 →Reissued until settledA revised statement replaces the email thread.
- 04 →Half or full paymentKept simple, with no approval chain, since the flow runs both ways.
- 05 →Visible on both sidesAgents see Expected, Pending, Paid and Under Review in their portal.
One source of truth
Always referenceable, always true to the state of the application.
Built for both directions
Ready for a future institution interface so universities can see claim status too.
Finance sees what it needs
Including the CAS, linked from each claim.
GSP’s own language
List or grouped by institution, with filters that match the rest of the platform.
Student portal
Launching soonThe B2C front door, built on the same record staff and agents use.
Students see exactly what the CRM knows: every application across the UK and EU pipelines on its own stepper, the actions their team has asked of them, and updates from institutions kept separate from tasks. Designed from a live sweep of GSP so the portal never shows a stage or a status the platform does not hold.
Email automation
In buildFrom hard-coded rules to emails an admin can configure, and audit.
Every stage email used to live in code. Now an admin builds it inside GSP’s existing Add Template steps: what it says, the moment it fires, who receives it and from which sender. Before saving, the template states in one plain sentence what it will do and is tested against sample applications, and a delivery log records what was sent, what fell back, and what did not fire and why.
Adoption and outcome
StaffCounsellors, QA, admissions, visa, compliance and finance work the same record every day, with configuration in settings rather than code.
Partners500+ agent organisations onboarding through a six-stage, AQF-aligned flow, managing their own student pipelines.
StudentsA student portal for direct applicants, launching soon, showing only what the platform actually holds.
Checked, not assumedEvery change ships with rewritten guidance and a named owner, and I come back to check that the old workaround has not returned.
200 → 1,500+Annual enrolments, 2023 to 2026
1 → 9Study destinations live on GSP in six months
300,000+Student records held on one platform
In-houseDevelopment moved from an external partner to a team I hired
Every module
| REF | MODULE | SCOPE | MY PART | STATUS |
|---|---|---|---|---|
| 01 | Commission engine Institution claims and partner payouts on one record. | Commission Claims and Agents and Partners pages; statements; part payments; multi-currency. | DESIGNEDSPECIFIEDLED | IN BUILD |
| 02 | Multi-destination pipeline One engine running distinct UK and EU flows. | CAS route and Final Acceptance Review route; conditional stages that appear only when needed; agent-handled visas waive compliance substages. | DESIGNEDLED | LIVE |
| 03 | Agent portal and onboarding The B2B side: agents onboard, submit and track applications. | 500+ partner organisations; agents manage their own pipelines; segment filter keeps agent and Study Now leads apart. | DESIGNEDLED | ROLLING OUT |
| 04 | Student portal The B2C front door: students apply and track directly. | Both UK and EU pipelines; Course Finder, shortlist and quick apply; action prompts raised by staff; fees inside each application. | DESIGNEDLED | LAUNCHING SOON |
| 05 | Dashboard and data health Role-curated reporting across nine destinations. | Ready, Complete and Unassigned per officer; unattributed applications surfaced; deposits and enrolments as separate targets. | DESIGNEDSPECIFIEDLED | SPECIFIED |
| 06 | Permissions and stage settings Access set per employee, not per role group. | Permissions matrix across the pipeline; mandatory fields configured per stage; sensitive actions held by named people. | SPECIFIED | |
| 07 | Activity log One append-only store of every action. | Staff, agents, students and automation; field, previous and new value on one line; additive and feature-flagged. | SPECIFIED | |
| 08 | Tasks and notifications A board people actually use. | Today, Tomorrow and Later; assign, snooze and complete from the card; reminders and an 08:30 digest. | SPECIFIED | |
| 09 | Lead attribution and upload-and-match Campaign data out of spreadsheets. | Any subset of four attribution fields in one pass; rows matched and confirmed before commit; university sheets mapped to GSP courses. | IN BUILD | |
| 10 | Email automation and inbox Admin-configured stage emails. | Sender and recipients per template; log of sent and unfired emails; replies threaded onto the record. | DESIGNEDSPECIFIEDLED | IN BUILD |
| 11 | Help Center and messaging oversight Support content and compliance. | Videos, articles and FAQs by audience; WhatsApp captured to the record under UK GDPR. | SPECIFIED | |
| 12 | Flow Builder GSP’s own automation layer, built from scratch. | Triggers on stage and field changes; actions across email, tasks and records; Claude steps behind a confidence gate and a human review queue. | LED | IN BUILD |
How each module gets made
- Run it liveStudy the live instance and the people using it first.
- Agree in conversationSettle the enhancement set before any artefact.
- Prototype in HTMLClickable and realistic, iterated until the shape is obvious.
- Write the briefData points, queries and acceptance checks for the developers.
- Sign off and measureAccept the release, then check months later that it held.