Map the family journey before choosing screens.
Start with the stages your school actually uses: inquiry, follow-up, application, document review, assessment or waiver, offer, acceptance, enrollment and student-record handoff. Name the owner, expected evidence and next action for each stage. This exposes duplicated entry, informal approvals and silent delays before software configuration begins.
Owner
Who is accountable for moving the record forward, and who covers an absence?
Evidence
What must be complete, verified and time-stamped before the next stage?
Decision
Which outcomes are allowed, who can approve them and when is a reason mandatory?
Next action
What does the family or staff member need to do, by when, and through which channel?
Make progress mean evidence, not a label.
| Stage | Minimum evidence | Control question |
|---|---|---|
| Inquiry | Source, programme, consent context and dated next action | Can duplicate families be reviewed without silently losing history? |
| Application | Required fields, declared information and submission receipt | Are institute and programme choices fixed to the intended application? |
| Document review | File identity, review state, reviewer and reason for rejection | Can staff distinguish missing, pending, accepted and rejected evidence? |
| Assessment or waiver | Outcome, reviewer authority and waiver reason where applicable | Can an offer be blocked until the required decision exists? |
| Offer and acceptance | Versioned terms, decision, expiry and acknowledgement | Do revisions preserve earlier evidence instead of overwriting it? |
| Enrollment | Final checks, unique student identity and handoff receipt | Is student creation atomic so partial enrollment cannot escape? |
Test the difficult cases before go-live.
Most workflow failures occur outside the happy path. Ask teams to rehearse a duplicate application, unreadable document, assessment waiver, expired offer, changed programme, withdrawn acceptance and enrollment rollback. Define which actions are reversible, which require approval and what evidence must remain after a correction.
- Keep rejection and correction reasons structured enough to review later.
- Separate “needs information” from a final rejection.
- Prevent staff from bypassing stage requirements through direct actions.
- Require approval and a reason for high-impact rollback or identity correction.
- Never expose one institute’s applicants, files or exports to another institute.
Protect the boundary between admissions and student operations.
Enrollment is not complete when an application is merely marked successful. Confirm that the student identity, guardian relationships, programme placement and required documents reach the authorized student-record workflow together. The handoff should prevent duplicate creation, retain its source application and produce evidence that staff can audit without reopening sensitive data broadly.
- Confirm the accepted offer still matches the intended programme and intake.
- Resolve duplicate student candidates before creating a second identity.
- Create the student record and enrollment link as one controlled action.
- Record the actor, time, source application and resulting student reference.
- Verify the next operational owner can see the record within their institute and role.
Use a short readiness scorecard.
- Every open record has a named owner and dated next action.
- Every stage has explicit entry, exit and exception criteria.
- Approvals are enforced by authority, not shared instructions.
- Corrections preserve earlier evidence and reasons.
- Institute boundaries apply to search, files, exports and background work.
- Enrollment creates one complete, traceable student handoff.
If any answer depends on a spreadsheet, private message or one person’s memory, capture that gap as an implementation requirement before agreeing a rollout date.