A student accepts an offer. The counsellor updates a spreadsheet. Finance waits for enrolment confirmation. A parent asks which documents are missing. Each person holds part of the answer.
Student recruitment software should connect those decisions through a shared record, with clear ownership of the next step. A contact database alone cannot tell you whether an application is ready or a commission claim is due.
This guide covers workflows to define before choosing or extending a system. Softvery builds custom software and AI features for international education companies. The questions below apply whether you configure existing software, connect tools or commission a custom module.
Separate the student from their applications
Start with the relationship between records. One student may apply to several partner institutions, programmes or intakes. Keep one student profile, then create a separate application for each choice. An offer from one institution must not change the status of another application.
Give each application an owner, an intake, a deadline, a current stage and a dated next action. Keep the history when ownership changes between counsellors or offices.
A useful starting sequence is enquiry, shortlisted, preparing, submitted, offer received, accepted and enrolled. Add withdrawn, declined and deferred routes. Define the evidence required for each transition. “Submitted” might require an institution reference and acknowledgement. “Enrolled” might require confirmation from the institution.
For example, in a hypothetical agency with three offices, two counsellors might receive the same student's enquiry. The system should flag the possible duplicate for review, preserve both conversations and assign responsibility before another application is opened.
When mapping education-agency workflows, ask who owns the student relationship and who owns each application. Those roles may differ.
Make document review a workflow
A folder of uploaded files does not explain what is missing, who checked it or which version was submitted. Define a document checklist for each programme or institution. Keep reusable student documents separate from application-specific forms.
Use distinct states such as required, uploaded, under review, replacement requested and accepted for submission. Avoid treating “uploaded” as “verified”. Completeness, readability and authenticity are different questions.
For each document, record:
The student and applications it belongs to.
The version, upload date and person who supplied it.
The reviewer, decision date and reason for requesting a replacement.
Any expiry date relevant to that application.
The version included in the submitted application.
For example, in a hypothetical application, a student replaces an unreadable transcript. The reviewer needs to see the replacement without losing the earlier review note. An application already submitted should retain its original submission record.
Decide which checks block submission and who can approve an exception. Put reminders against the missing item, with a responsible person and escalation date. A shared checklist supports review; it does not authenticate a qualification by itself.
Keep partner institutions and agreements current
An institution record needs more than a name and email address. Consider campuses, programmes, intakes, application contacts, submission methods and agreement dates. Give someone responsibility for reviewing changes.
Separate operational information from commercial terms. A counsellor may need a submission contact without needing access to every commission agreement. Finance may need the agreement version without needing the student's full document set.
Before importing programme data, agree definitions. Does a course price include registration or accommodation? Is duration recorded in weeks or terms? Who confirms that an intake remains open?
Ask these questions for each partner:
Where does authoritative programme and fee information come from?
Who confirms receipt when applications are submitted by email?
How are changed deadlines communicated to counsellors?
Which agreement applies when a student defers to another intake?
Keep an agreed snapshot where historical terms matter. Updating a partner's current information should not silently rewrite an existing quote or commission record.
Design agent commission tracking around evidence
First distinguish commission receivable from partner institutions and commission payable to recruiting agents or sub-agents. A school group may mainly track the latter. An agency may need both. Keep separate ledgers and link each entry to the relevant application or enrolment.
Define the calculation before building the report. Specify the eligible fee base, rate or fixed amount, agreement version, currency and exclusions. Then define the event that makes the commission claimable. An accepted offer, paid deposit, enrolment confirmation and completed study period are different events.
A practical status model could be expected, eligible to claim, invoiced, partly paid, paid, disputed and reversed. Record evidence for each change.
For example, suppose a hypothetical partner agreement makes commission claimable after confirmed enrolment. Accepting the offer creates an expected entry. Confirmation makes it eligible. Raising the invoice records the due date. A partial payment reduces the outstanding balance without closing the claim.
Test exceptions before agreeing the scope:
A student withdraws after an invoice is raised.
A deferral changes the applicable agreement.
A partner pays several invoices in one transfer.
A refund requires an adjustment to commission already received.
A sub-agent's payment becomes due before the institution pays.
Keep adjustments visible, with reasons and approval records. For currency conversion, agree which date and rate the business uses and retain that information. Show expected income separately from invoiced amounts and cash received. A tracker makes outstanding claims visible; payment still depends on the partner.
Give the student/parent portal a clear job
A student/parent portal should answer three questions: what is happening, what must I do next and whom should I contact? Start with those tasks before adding extra screens.
Show application-specific progress, outstanding documents, relevant deadlines and the responsible counsellor. Explain statuses in plain language. “Action needed: replace your transcript scan” is more useful than an unexplained internal code.
Treat student and parent accounts separately. Define how access is granted, limited and removed. Do not assume that a parent should see every document or message. Have the responsible person review access rules against the agency's policies and obligations.
Keep internal review notes, commercial agreements and commission records outside the student view. Decide which updates trigger notifications, which channel students use and how failed delivery reaches staff.
A portal also needs a human route. If a student cannot upload a file, the counsellor should be able to help while preserving the record of who supplied it. Measure completed tasks and unresolved requests to assess whether the portal helps.
Configure, connect or build?
Choose the approach after identifying the actual gap. These options involve different responsibilities.
| Approach | When to consider it | Trade-off to examine |
| Configure the current system | Its records, permissions and rules can support the workflow | Check whether exceptions remain understandable and maintainable |
| Connect existing tools | Applications work well, but information is re-entered elsewhere | Assign responsibility for failed transfers and conflicting updates |
| Build a custom module | A specific workflow cannot be represented adequately | Budget for maintenance, support, access controls and future changes |
Ask vendors to demonstrate your scenarios using invented records. Follow an application through submission, document replacement, deferral and commission adjustment. Include a permissions check: can one partner see another partner's students?
If connecting systems, choose where each field is maintained. Specify what happens when a transfer fails or the same event arrives twice. A manual export may suit a pilot if someone reconciles it; it becomes a poor dependency when nobody owns the handoff.
When reviewing case studies, ask which workflow was delivered and what evidence supports the outcome. Use a similar discipline when discussing software for education agencies: define the record, roles and exceptions before discussing screens.
Where to start
Pick one handoff that repeatedly creates uncertainty. It could be “documents ready to application submitted” or “enrolment confirmed to commission invoiced”. Name the process owner and the person who will accept the result.
Write a short brief with the starting event, required records, roles, completion evidence and exceptions. Walk through it with a counsellor, an operations lead and finance. Agree a pilot group, an export format and a way to correct mistakes.
Set acceptance checks around real tasks. Can staff identify what blocks submission? Can finance explain an outstanding commission balance from its source records? Record the current situation before deciding what improvement to measure.
Softvery offers a short paid discovery sprint covering one scenario, key screens, assumptions and a next-step plan. Its discovery scope excludes a working application, production code, live integrations and data migration. For further reading on scoping, see what a discovery sprint includes.
If you want to discuss one recruitment workflow, bring its current steps and an example of where work stalls. Book a 30-min call.
