A student asks about a course through your website. A counsellor replies by email. Another office receives a message from the same student. By the time an application reaches a partner institution, nobody is sure which record is current.
A CRM for education agencies should give that journey a shared record, a responsible person and a visible next action. Start by defining those rules before choosing screens or automation. The same exercise applies to a language school group handling direct enquiries, or an edtech team building recruitment tools for agencies.
Define what moves through the pipeline
Keep the person, the recruitment journey and each application distinct. A student may enquire twice, consider several programmes and submit applications to different institutions. Those events should not create unrelated student records.
Use one student record for contact details and communication preferences. Link it to an enquiry or recruitment journey for the intended intake. Attach a separate application for each institution and programme. Store documents against the relevant student or application, according to their purpose.
For example, imagine a school with three centres sharing an admissions team. A student asks about two centres, then changes course dates. This is a hypothetical workflow: the team should update the existing journey and preserve its history, rather than count each conversation as a new prospect.
Decide what happens when that student returns for another intake. Reuse their identity, but open a new journey so previous outcomes remain readable.
Give each stage an entry rule and an exit rule
Agree a small set of stages across offices. Labels such as “in progress” leave too much room for interpretation. Each stage needs evidence, an owner and a next action.
| Stage | Evidence needed to enter | Next action to record |
| New enquiry | Contact route and source captured | Assign a counsellor and response deadline |
| Counselling | Student reached; intended intake recorded | Confirm requirements and shortlist |
| Application preparation | Programme chosen; application opened | Request outstanding information |
| Submitted | Submission reference or acknowledgement | Set a partner follow-up date |
| Offer received | Offer and conditions recorded | Confirm the student's decision |
| Enrolled | Evidence meets your agreed enrolment definition | Hand over to student support |
Apply application stages to each application. Give the overall journey its own summary outcome. One rejected application must not close another that is still active.
Keep payment, document review and any visa-related tracking in separate fields or checklists. They can progress independently. A single “awaiting visa” stage can otherwise hide an unpaid balance or an unresolved offer condition.
Add deferred, withdrawn and closed outcomes, each with a reason. Decide how a deferred journey reopens without losing its original intake history.
Make the counsellor pipeline actionable
A counsellor pipeline should answer three questions: what needs attention, who owns it and when it is due.
For every active journey, require:
A named counsellor and responsible office.
A specific next action, such as “confirm revised course dates”.
A due date in the relevant working time zone.
The last meaningful contact and its outcome.
A reason when progress is blocked.
Choose an assignment rule that staff can explain. Rotation is simple, but it needs exceptions for language, programme knowledge, workload and absence. Give unmatched enquiries a visible queue and someone responsible for clearing it.
An acknowledgement message should not count as a counselling response. Record whether a person has reviewed the request and replied to its substance.
When a counsellor is away, assign temporary cover. Avoid leaving ownership attached to someone who cannot act. Ask during a demonstration: can a manager find every overdue action without opening each student record?
Design handoffs for multi-office agencies
Multi-office agencies need shared definitions and explicit transfer rules. A shared database alone does not establish responsibility.
Agree when a receiving office accepts a transfer and who owns the case until then. Include the student's current choices, open applications, outstanding conditions and next promised contact in the handover.
Test this scenario: a student contacts a second office while their original counsellor is preparing an application. Can staff recognise the existing record? Can they add the conversation without claiming ownership? Who approves a permanent transfer?
Retain the original enquiry source alongside the current owner. Marketing attribution and responsibility for today's follow-up answer different questions.
Set access by role and office. Decide who can view contact details, download documents, change ownership and export records. Test ordinary staff accounts as well as manager accounts.
Use these questions when reviewing the education agencies overview and writing your own workflow brief.
Separate document collection from review
“Uploaded” and “accepted” should be different statuses. A checklist needs to show what was requested, which version arrived, who reviewed it and what remains unresolved.
Ask reviewers to record a clear reason for returning a file. “Please upload again” gives a student less useful guidance than “the final page is missing”. Preserve earlier versions so staff can understand what changed.
Apply the same discipline to offers. Record conditions, deadlines and the student's response against the correct application. Do not copy an offer condition into a general note that another counsellor may miss.
If you introduce a student or parent portal, decide which information each person can see. Define parent access explicitly instead of assuming every linked adult should receive every update.
Keep internal notes separate from messages intended for students. Choose who approves sensitive updates and how corrections reach everyone who received the original message.
Connect systems with clear responsibility
Before connecting forms, email, payments or partner systems, write down which system controls each field. For instance, finance may confirm payment while the CRM displays that confirmation for counsellors.
Define the event that triggers an update. A submitted form, a confirmed payment and an accepted offer are different events. Specify how the connection handles a repeated event without creating another record or sending another reminder.
Ask these questions before agreeing an integration:
How are existing students matched, and who reviews uncertain matches?
What happens when an update fails or arrives late?
Where can staff see failures and request a retry?
Which system wins when two people change the same field?
What happens when a message cannot be delivered?
Start with a connection that addresses a known handoff problem. Adding every available integration at once makes conflicting data harder to trace.
Report enrolments with agreed definitions
Decide what “enrolled” means for your operation. An accepted offer, a deposit and confirmation from an institution may represent different milestones. Select the evidence your report requires and record its date.
Count unique student journeys separately from applications. Otherwise a student applying to several institutions can distort the apparent size of the pipeline.
For an initial operations report, consider unassigned enquiries, overdue next actions, time spent at each stage, outstanding conditions and confirmed enrolments by intake. Compare equivalent intake groups, and account for journeys that are still open before interpreting conversion rates.
Keep commission status separate from enrolment. Link an expected commission to the relevant application and agreed partner terms. Track invoicing, due dates, disputes and receipts independently. An enrolment does not mean its commission has been paid.
Configure, connect or build?
Test your current student recruitment CRM against these workflows before replacing it. Configuration may be enough if it can represent separate applications, enforce ownership rules and expose exceptions clearly.
Consider an integration when the underlying process works but staff repeatedly re-enter information between systems. Consider a custom module when a specific review or handoff cannot be handled within the current setup.
A replacement deserves a stronger case. Include migration, staff training, access controls, maintenance, subscriptions and responsibility for future changes in the decision. Ask who will administer the system after launch.
Use the same scenario to assess every option. Request a demonstration of a duplicate enquiry, an office transfer and a deferred application. When reviewing case studies, ask which decisions are relevant to your workflow and what evidence supports any claimed result.
Where to start
Pick one intake and one troublesome handoff. Bring together a counsellor, an operations owner and whoever receives the work next.
Walk through a small set of anonymised journeys, including an exception. Map the current steps, agree stage definitions and write acceptance criteria. For example: after an office transfer, the receiving counsellor can see outstanding conditions and the next promised contact without asking the original owner.
Pilot the change with a limited team. Check missing owners, duplicate records and overdue actions before expanding it. Agree who corrects imported data and how staff report problems.
Softvery builds custom software and AI features for international education companies. Its short paid discovery sprint covers one scenario, key screens, assumptions and a next-step plan. The discovery scope excludes a working application, production code, live integrations and data migration.
For further context, read the article on discovery sprints alongside the software for education agencies overview.
If you would like to discuss one handoff in your pipeline, Book a 30-min call.
