Partner Registration
Register new and existing donor partners with organisational, contact and programme context.
Original Product Artifact Original high-level PRD presented as a readable, privacy-safe portfolio view
Product artifact · Product requirements document
High-Level Product Requirements Document — Partner Management System
A readable presentation of the working PRD used to define partner registration, donor-cycle rules, concurrent programmes, extensions, student mapping, reporting, alerts and access control.
Download source transcript01
Product scope
The PRD divided the operating problem into four connected modules.
The modules moved from relationship registration to cycle management, operational data and proactive reporting. This prevented donor reporting from becoming one oversized form or a disconnected spreadsheet export.
Donor Cycle Creation & Management
Define cycles, dates, campuses, schools, cohorts, commitments, extensions and student associations.
Data Integration & Manual Entry
Bring registration, attendance and student information into the donor-cycle context through imports or integrations.
Reporting & Slack Messages
Surface progress, placement, attendance, deadlines and cycle-end actions proactively.
02
Business rules
The important work was defining what remained true when programme timelines overlapped.
The PRD made the durable partner relationship, individual cycle commitments, extensions and student-to-cycle association explicit rather than hiding them inside one programme status.
Partner and donor cycle are separate records
The partner represents the durable organisational relationship. Each donor cycle represents a specific funding commitment with its own dates, cohort, campuses, targets and status.
Multiple cycles can overlap
A partner can sponsor more than one active cycle, and cycles from different partners can run concurrently. Reporting cannot assume a single sequential programme timeline.
Planned end and actual completion are distinct
Cost and no-cost extensions preserve the original commitment while allowing the system to track extended dates and unresolved outcomes.
Students remain linked to funding context
Student registration and later movement must preserve the relationship between student, donor, cycle, campus and school so outcomes remain attributable.
03
Domain scope
Partner data and cycle data were deliberately separated.
The relationship record contains stable organisational context. The cycle record contains the dates, commitments, campuses, cohorts, targets and extension state for one funding engagement.
Durable relationship data
- Partner name
- Partner type
- Contact person
- Partner details
- Schools supported
- Campuses supported
- Cohort size committed
Commitment and programme data
- Donor name
- Cycle name
- Start date
- Planned end date
- Campus and school
- Cohort size
- Target placement outcomes
- Funding amount — restricted access
- Status
- Cost extension
- No-cost extension
- Extended end date
04
High-level workflows
The requirements carried each module into an executable operating sequence.
These flows are intentionally high-level: they establish actor intent, data transitions and outputs before functional specifications define field-level behaviour.
Partner registration
- Open Partner Registration
- Enter organisation and contact details
- Review and validate
- Create a unique partner profile
Donor cycle creation
- Create new cycle
- Select partner
- Generate cycle name
- Set dates, cohort and campuses
- Set targets and status
- Save cycle for student mapping
Data integration and entry
- Upload or receive student data
- Validate donor-cycle mapping
- Synchronise registration and attendance
- Correct controlled exceptions
Reporting and alerts
- Calculate progress by cycle
- Prepare placement and attendance views
- Track approaching end dates
- Send deadline and review alerts
05
Reporting, alerts and access
The PRD defined next actions, not only retrospective reports.
Cycle progress, end dates and reporting deadlines were intended to become proactive operating signals, with access shaped around Partnerships, campus operations, leadership and Finance.
- Progress update against target outcomes and active students.
- Cycle approaching its planned end date and requiring extension or closure review.
- Partner reporting deadline approaching with a data-readiness reminder.
- Partnership Team
- Portal user
- Campus Manager
- Portal user
- Leadership
- Portal administrator
- Finance Team
- Portal user with restricted financial fields
Publication boundaryThis web view omits partner names, contact details, funding amounts, student identities and internal targets. It preserves the product structure and working rules.