An education CRM should distinguish an admissions enquiry from an application, assign the next useful response and record the purpose and preferences relevant to further contact. Start with the enquiry-to-applicant handover, then test an incomplete application and a changed communication preference. This makes the next action clear without assuming every interested person has already applied or enrolled.
A prospective student may ask about a programme long before deciding to apply. The admissions team needs enough context to answer the question and explain the next step, while application records serve a later purpose. Write those stages in plain language before selecting fields or automated messages.
The original enquiry-and-application worksheet below uses fictional applicants and programmes. Narrow product examples come from Frappe Education’s Student Applicant guide and Frappe CRM’s task documentation, retrieved on 24 October 2026. Broader business systems and web development discussions remain separate.
When should an enquiry become an application?
Write the institution’s actual admissions stages and the evidence that distinguishes them. An enquiry can remain a question with a responsible responder. An application should have the information and submission event the institution requires. Keep the transition explicit so reporting does not turn every request for information into an applicant count.
Frappe Education creates a Student Applicant record when a student applies. Its Student Applicant guide provides a narrow example of a formal application record. Identify the programme and relevant application context in the proposed mapping rather than using the person’s name as the only reference.
Frappe Education can create the applicant through its Student Applicant Web Form. New applications have the default status Applied in the documented workflow. Record the actual entry route and resulting state in the acceptance sheet. The enquiry route can then be reviewed separately from that application-submission mechanism.
For the fictional exercise, use Programme North and Sample Person A. Begin with a question about the programme, then introduce an application with a missing piece of institution-defined information. Ask the admissions owner to identify which stage each case belongs to and what response is appropriate.
How should follow-up remain attached to the work?
Frappe CRM tasks can be linked to leads and deals. Its task guide supplies a separate product example for accountable follow-up. An institution considering such a mechanism should identify the relevant enquiry record and define how its relationship to an application would be implemented and assessed.
Frappe CRM tasks include a title and description for the action and context. Frappe CRM tasks include an assignee and due date. Write the next useful admissions action clearly enough that another authorised colleague can continue it. A task called follow up is less informative than a task explaining the question still awaiting an answer.
Frappe CRM tasks have Backlog, Todo, In Progress, Done and Cancelled states. Frappe CRM can filter tasks by assignee, priority, status or due date. Use these documented examples to frame a working-view test: can the responsible colleague find the fictional enquiry that still needs a response?
| Fictional admissions case | Proposed record | Next-action question |
|---|---|---|
| Programme enquiry | Person, programme and question | Who supplies the requested information? |
| Application submitted | Application reference and actual state | What review is now required? |
| Information incomplete | Specific missing requirement | Who contacts the applicant and what is needed? |
| Preference changes | Relevant communication purpose and choice | Which future contact should change? |
| Application accepted | Authorised decision and next stage | What establishes the handover to enrolment? |
| Follow-up unresolved | Task, responsible role and context | Can another colleague identify the open work? |
This is an original workflow sheet. Agree its stage meanings and required evidence with the institution before configuring it.
What should communication preferences describe?
Separate the purpose of each proposed communication. Replying to a requested admissions question, sending an application update and inviting someone to unrelated promotional content may need different operating decisions. Have the institution’s authorised owner define the applicable requirements and record the source of those requirements privately.
The proposed preference record should identify the person, relevant channel, purpose, stated choice and point when it was recorded. Ask who maintains it and how a change reaches the role or system preparing future communication. Keep the required decision visible when a person is still only an enquirer.
Use fictional examples to assess the process: Sample Person A wants an answer to the current question but changes their preference about later general updates. Ask the operator to explain which task remains and which proposed communication changes. This tests the institution’s stated rule without claiming a particular legal basis or an undocumented built-in consent feature.
How does the applicant handover reach the next stage?
Frappe Education permits an applicant to be approved or rejected. In its documented enrolment route, Enroll creates a student and opens Program Enrollment. These product-specific transitions provide a concrete example for distinguishing an admissions decision from the later record used for the student’s programme relationship.
Record the authorised decision owner and the references needed by the next administrative role. Ask how an incomplete or rejected application remains understandable to the team. The original requirement should state what work is expected next, rather than assume that moving a status automatically supplies every communication or review task.
Original enquiry-to-applicant handover exercise
Prepare Programme North and two fictional people in a separate test environment. One person has only asked a question; the other has submitted a sample application with a deliberately incomplete institution-defined requirement. Record the intended stage, responsible role and next action for each before entering the cases.
First, ask an admissions user to identify the enquiry and provide the next response task. Have another colleague continue from the record and explain the outstanding question. Retain the information they actually used so the review can assess the usefulness of the handover.
Next, inspect the submitted application and its relationship to the programme. Record the actual state and missing information, then ask the reviewer to identify the authorised decision route. Keep enquiry and application references separately visible where the proposed implementation links them.
Then introduce the changed communication preference and inspect the effect on the proposed next actions. Finally, demonstrate an accepted sample application through the relevant test enrolment route and record the resulting identifiers. Keep any unproven mapping or preference behaviour as a specific requirement with an owner.
Use the completed sheet to agree the admissions stages, accountable follow-up and communication-purpose decisions. To discuss the particular institution workflow and evidence still needed, get started with the fictional cases and authorised admissions requirements.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.